INDEX
CURRENT LAB PROBLEMS
- The motherboard of car2 seems fried. I've tried to connect it to a screen and there was no signal.
- 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.
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 30cm. 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.
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.
- 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.
- 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.
- Determine the four points to record. The four points must 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.
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.
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.
- Battery status greatly affects the engine performances.
- There was a bug in the CPS code that affected the initial target dectection for cars that were not tracked by computer 0. It's fixed now but old CPS should not be used (at least Kevin's and Leo's).