You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 30 Next »

INDEX
CURRENT LAB PROBLEMS
  • The motherboard of both car1 and car2 seems blown...I tried to connect it to the screen and there was no signal. I will try to substitute the power connector.
  • The left rear wheel of car3 doesn't spin when the motor runs.
  • Both cars 1 and 3 (I couldn't check car 2) have biased steer. When the steer input signal is 0 they turn left (in car1 this problem is very evident).
  • 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.
CHANGES TO THE SOFTWARE FROM PREVIOUS SUMMER
  • ca2: grouped utility functions in a separate folder that is shared with the simulator.
  • CPS: fixed a bug that affected the initial target dectection for cars that were not tracked by computer 0.
  • CPS: implemented linear error correction for the computation of camera position.
  • CPS: now compute and send also the 2D speed of the cars. This makes Andrea CPS not compatible to previous ca2 versions and my ca2 not compatible with previous version of CPS.
EFFECT OF THE BATTERY ON THE SPEED DYNAMICS

I made an investigation on the effect that the battery has on the car speed. Data has been acquired by running car1 on a circle with constant steer and engine input. The steer has always been set to -64. The starting position of the car has always been about (3000, 3600) in global coordinates (this if you want to make considerations connected to the test-bed slope). The voltage of the battery was measured both before turning on the car (while off) and just before run ca2 (while on). The full data gathered and the detailed description of how the experiments were performed can be found in my folder on Dropbox in "../backup/data/battery_7-30-2013".

  • Experiment 1: the initial voltage was kept constant while varying the pwm signal. The car is run twice in a row for 250 seconds from a starting voltage of 16.8V (turned off). See figure experiment1.png. The speed always reaches a peak and then decrease to a steady state value. The second run starts more or less from the steady state value. The PWM does not seem to affect neither the time constant nor the steady state value that is more or less always 200 mm/s below the peak.
  • Experiment 2: the pwm was kept constant while varying the initial voltage. The car is run only once. See figure experiment2.png. From starting voltage 16.9V to 16.5V the speed has basically the same trend. The steady state value and the constant time becomes lower below 16.4V.
  • Experiment 3: the car is run 3 times in a row to check if the third time the speed dynamics changes again. See experiment 3.png. The third time the car has the same behavior of the previous run.
  • Experiment 5: the car is left turned on for 25 minutes before running to check if the capacitor gets discharged even if the car is not running. See experiment 5.png. The capacitor mantains its original level.

TODO: I wanted to perform another experiment to check if the capacitor gets charged again to its original level after the car runs but car1 broke just before I could perform the experiment.

CAMERA MEASUREMENT ERROR CORRECTION

The position of the car on the test-bed computed by the CPS is affected by a considerable error. I made some manual measurement of this error by finding the real position with the measuring tape and checking the computed position on the CPS and I found it to be be up to 25cm. Moreover, when the tracking of a car pass from a camera to another, the global coordinates "leap" because the position error in the transition point is different for the two cameras. From the experiments on the path fig8, this leap can be up to 35cm.

I made some investigation on the trend of this error. The results are shown in error_trend.png. In the figure, "x_loc" indicate the x coordinate in pixels in the local coordinate system of the camera (i.e. the horizontal one), while "x_glob" is the x coordinate in cm in the global coordinate system. Remember that the axises of the local and the global coordinate systems are inverted. Data where gathered for two cameras.

I decided to consider the error linear along both direction and try to apply a correction to the computed global coordinates. The correction is thus applied in the form err = a*x_loc*y_loc + b*x_loc + c*y_loc + d. The parameters a, b, c, d are computed by the CPS on start by loading a file where the real global coordinates of four points must be saved. This is the procedure that must be followed to configure this file. This procedure must be repeated for each camera. It is calibration-independent, meaning that you do not have to repeat it if you have to perform a new instrinsic/extrinsic calibration, but if the camera is moved, the procedure must be done again.

  1. Set the variable RECORD_OBJECT_DATA = 1 in the file CPS.h in the computer responsible for the camera that you want to configure and compile it. For information about compiling the CPS, check the original lab documentation.
  2. Run CPS.exe. The RECORD_OBJECT_DATA mode was designed to take pictures of the cars symbols so it will ask you the car number and the section number, just put a negative number. The only thing you must insert correctly is the camera number that you want to configure.
  3. Determine the four points to record. Considering the error trend, the four points should be chosen to form the broadest rectangle of interest, that is the rectangle with the biggest area contained in the camera view where the car can be tracked. To clarify, an example of how to choose the points is found in point_selection.png. Walls, obstacles and the end of the sections limit the rectangle. The console gives you information about the pixel coordinates of the top left corner of the small squared boxes, in the figure it is located close to (x2, y2). You can move that box with keys "a", "s", "d" and "w". Write down the pixel coordinates of those four points.
  4. Now measure the global position of those four points with a measure tape and record them. You should now have written down 4 pixel coordinates (x1, y1, x2, y2) and 8 global coordinates, 2 for each point of the rectangle. Pay attention when writing down the global coordinates. Since the x and y axises of the local and the global coordinate system are inverted, it is easy to make confusion.
  5. Open the folder "Desktop/camera_programs/Andrea CPS/calib_data". There 5 files called "error_camx.txt", where "x" is the number of the camera. Open the one that refers to the camera you are configuring. The format of the file is very easy to understand and consistent with this explanation. Write there the pixel coordinates of x1, y1, x2, y2 and the global coordinates of those points.
  6. Now you can set RECORD_OBJECT_DATA to 0 and you are good to go.

The error correction gave a visible improvement to the steer control performance. The car stays much closer to the given path. The error in camera 5 and 2 is constantly below 10cm and rarely above 5cm. Moreover the measured position "leaps" are reduced. I was not able to measure a leap above 15cm.

TODO: a filter Kalman has been implemented on the car in hopes of removing the remaining part of the noise. The model still needs to be refined though in order to test its true usefulness.

NOTES
  • The testbed is not completely flat, there are slight slopes. A car that runs on a circle with constants steer and pwm shows low frequency oscillations on its speed (measured with the encoder) because of this.
THINGS I WOULD HAVE LIKED TO BE DOCUMENTED
  • The car number is on the heatsink on the motherboard hidden under the adhesive paper ring.
  • Car circuit model.
  • CPS code currently doesn't compute the vehicle heading by checking the line on the cars' symbols. It just checks the previous and the current position to do it.
  • How to use Moto.exe.
  • One must pay attention whether there is some overlapping area between two adjacent cameras.
  • No labels