Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • determine and limit the disturbances which make the prediction uncertain to a degree that make the experiment unfeasible;
  • identify a model of the system that is suitable for the long term prediction that the algorithm requires.

SUMMARY OF

...

CHANGES

...

SOFTWARE

...

  • Implemented a simulator in C for Linux. This is integrated with the code used on cars (ca2). It simulates the cars dynamics and the behavior of the Camera Positioning Systems (CPS). Besides being very useful to verify the system model, it makes easy to test changes to code and the controller before applying those changes to cars.
  • Implemented a script to visually debug cars behavior. It works both with the simulator and test-bed experiments data.
  • ca2: grouped utility functions in a separate folder that is shared with the simulator. This makes the code more modular.
  • ca2: partially implemented a Kalman filter in the attempt to remove part of the measurement noise of cameras. The model must be refined for it to prove its real effectiveness.
  • ca2: implemented a new target detection algorithm that allow the car to work with the path with lots of points.
  • ca2: steer controller has been reworked, the monodimensional speed has been substituted by the one read from the encoder, the PD has been calibrated and a compensator has been added.
  • ca2: modified paths to add compensator directives (See #COMPENSATOR DIRECTIVES).
  • ca2: implemented a new filter for the heading measure to cancel the effect of leaps (See #HEADING FILTERING).
  • ca2: set the limit of steer input to (-100,100) since the curvature radius saturates above it.
  • CPS: fixed a bug that affected the initial target dectection for cars that were not tracked by computer 0.
  • CPS: now compute and send also the 2D speed of the cars. This is likely to be needed for the predictor in the future. See also section #CPS MEASURED 2D SPEED.
  • CPS: implemented linear error correction for the computation of camera position. This visibly improves the path following of cars. See section #CAMERA MEASUREMENT ERROR CORRECTION.

Note about CPS usage. Since CPS now compute and send the 2D speed to cars, AndreaCPS is not compatible to previous ca2 versions. Viceversa my ca2 is not compatible with previous version of CPS. This is because the communication protocol between CPS and ca2 is now a little bit different. In general I would suggest using AndreaCPS instead of KevinCPS or LeoCPS. This because of the bug that involved the initial target detection. I did not check CPS versions that are previous to KevinCPS but it is likely that those versions do not have this bug since computer 1 and 2 do not send their information to computer 0 before sending them to cars.

CURRENT LAB PROBLEMS

  • Cameras should be screwed to the metal support. Now every time they move, the whole calibration procedure must be done again. An extrinsic calibration (at least) should probably be performed again after this job.
  • The two chargers close to the whiteboard seem to have some wiring problem. Sometimes the led is green while cars are connected (i.e. they're done charging) but it turns red when you move the wires.
  • Sometimes the connection between computers and cars is lost. There are 2 main cause.
    1. There are 2 critical functions in the CPS code in main.cpp that occasionally takes up to 300-400ms in computer 0. This does not happen (or happens extremely rarely) with computers 1 and 2. I think the fault may simply be the computer's hardware because computer 0 is the slowest among the three. The two critical functions are flycaptureGrabImage2() and cvWaitKey(). The CPS currently prints a warning when one of this two functions takes more than 0.1s (the car's clock). I changed the CPS so that computer 1 now sends the data to cars so that the connection is always active, still this kind of delay makes cars tracked by computer 0 to receive out-of-date information.
    2. Sometimes car 2 becomes unreachable to ping tests while moving. This causes the time between two clock cycles to reach even 1-2 seconds. I have never found the same problem with car 1 and 3. Most of the times this happens, there is no timeout of the recvfrom() function that receives the data from computers. This suggests that the problem resides in the on-board computer more than in the connection. The reason could have both hardware (the motherboard of car 2 is an older and slower model with respect to car 1 and 3) and software origins

The progress of the project until now has been influenced by various technical problems that were probably quite dated. I am keeping a list of all the problems I encountered while becoming familiar with the laboratory equipment. I plan to expand the bullet points of this list later to make them more exhaustive. I will then add and integrate them to the main lab document. Hopefully this will make the settling-in period of new researchers in this lab shorter.

Besides having to deal with broken pieces of equipment, I had to solve few problems concerning the speed of cars that were visibly slower than others and vehicles whose performances deteriorated much faster than others in time. This was necessary to avoid having to identificate 3 different models (one for each car).

...

MEDIUM TERM GOALS

...

Lateral dynamics

Longitudinal dynamics

...

SOFTWARE CHANGES FROM PREVIOUS WORK

...

  • Implemented a simulator in C for Linux. This is integrated with the code used on cars (ca2). It simulates the cars dynamics and the behavior of the Camera Positioning Systems (CPS). Besides being very useful to verify the system model, it makes easy to test changes to code and the controller before applying those changes to cars.
  • Implemented a script to visually debug cars behavior. It works both with the simulator and test-bed experiments data.
  • ca2: grouped utility functions in a separate folder that is shared with the simulator. This makes the code more modular.
  • ca2: partially implemented a Kalman filter in the attempt to remove part of the measurement noise of cameras. The model must be refined for it to prove its real effectiveness.
  • ca2: implemented a new target detection algorithm that allow the car to work with the path with lots of points.
  • ca2: steer controller has been reworked, the monodimensional speed has been substituted by the one read from the encoder, the PD has been calibrated and a compensator has been added.
  • ca2: modified paths to add compensator directives (See #COMPENSATOR DIRECTIVES).
  • ca2: implemented a new filter for the heading measure to cancel the effect of leaps (See #HEADING FILTERING).
  • ca2: set the limit of steer input to (-100,100) since the curvature radius saturates above it.
  • CPS: fixed a bug that affected the initial target dectection for cars that were not tracked by computer 0.
  • CPS: now compute and send also the 2D speed of the cars. This is likely to be needed for the predictor in the future. See also section #CPS MEASURED 2D SPEED.
  • CPS: implemented linear error correction for the computation of camera position. This visibly improves the path following of cars. See section #CAMERA MEASUREMENT ERROR CORRECTION.

Note about CPS usage. Since CPS now compute and send the 2D speed to cars, AndreaCPS is not compatible to previous ca2 versions. Viceversa my ca2 is not compatible with previous version of CPS. This is because the communication protocol between CPS and ca2 is now a little bit different. In general I would suggest using AndreaCPS instead of KevinCPS or LeoCPS. This because of the bug that involved the initial target detection. I did not check CPS versions that are previous to KevinCPS but it is likely that those versions do not have this bug since computer 1 and 2 do not send their information to computer 0 before sending them to cars.

...

CURRENT LAB PROBLEMS

...

  • Cameras should be screwd to the metal support. Now everytime they move, the calibration must be done again. An extrinsic calibration (at least) should probably be performed again after this job.
  • Sometimes the two chargers close to the whiteboard display the green light when cars are connected (i.e. they're done charging) but when I move the wires the light turns red.

...

NEXT STEPS

...

Steer control

  • Steer controller designing and testing.

Predictor design

  • Model identification of motor_input -> speed.
  • Model identification of path-dependent disturbances (steer, slope and projection) on speed.
  • Quantification of non-predictable path-dependent disturbances.
  • Predictor implementation and testing.

Experiment

  • Debugging of the collision avoidance algorithm with the new predictor on the simulator.
  • Setting-up and testing of the experiment with only autonomous vehicles.
  • Setting-up and testing of the final experiment with also human-driven vehicles
    1. .

DISTURBANCES ANALYSIS

In this section a quantitative analysis of the disturbances in the system is attempted. In order to deal in an easier way with the assumption of monotonicity and with the coupling between the steer and the motor input, the model is linearized and the lateral and the longitudinal components are separated. The coupling effect is seen as a disturbance. In the following the coordinate system will be relative to the path as represented in Figure coord_sys.jpg. In other words, y represents the position along the path while x the lateral distance from the path.

...