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

Compare with Current View Page History

« Previous Version 50 Next »

INDEX

THE GENERAL PROBLEM

SUMMARY OF THE CURRENT STATUS

PROGRESS

Software

  • 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.

Note about CPS usage. This makes Andrea CPS not compatible to previous ca2 versions and my ca2 not compatible with previous version of CPS. Kevin and Leo CPS have bug (didn't check previous versions but likely to not have it).

Model

Others

  • expanded troubleshooting section.
CURRENT PROBLEMS
  • 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.
NEXT STEPS

CPS

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.

2D SPEED

CAR MODEL

EFFECT OF PWM AND STEER INPUT ON THE SPEED DYNAMICS

I made car1 run on circles for 50 seconds with fixed PWM and steer input for a total of 16 runs. Every run was performed starting from the same battery voltage of 16.7V. 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/circle_7-27-2013". All the images below are obtained by filtering the encoder signal with a moving average window to discard the large part of the noise. The oscillation of the speed is largely due to the fact that the test-bed is not perfectly flat but inclined in some areas.

Figure pwm.png shows the speed of the car obtained by keep the steer constant and varying the PWM. The relationship between PWM and velocity is quite linear. For some reason, when the steer input is high, the speed observed with PWM 140 is slightly lower than I would expect. On the other hand, the steer effect seems to be a little bit more complicated (see steer.png). Velocities observed for steer 92 and 120 are always very close. This may be due to the fact that curvature radius for the two steer input are very similar (the curvature radius is not linear with respect to the steer signal). Still the speed is not linear w.r.t. the curvature radius because the discrepancy between the speed for steer 36 and 64 (which I measured to have respectively a curvature radius of roughly 200cm and 100cm) tends to be reduced by decreasing the PWM.

  • 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.
EFFECT OF THE BATTERY AND THE POWER FILTER CAPACITOR 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 car speed is not affected.
  • Experiment 6: the car is run for 200 seconds, then it is left on for other 200 seconds without running and then run for other 200 seconds. See experiment 6.png. The car speed has the same peak as the previous run.

The behavior dynamic of the car speed is likely caused by the capacitor that filter the power source. When the car is not running the circuit is in steady state condition. When it runs the equilibrium moves and the capacitor slowly discharges.

DOCUMENTATION EXPANSION

TROUBLESHOOTING
  • CPS: one must pay attention whether there is some overlapping area between two adjacent cameras.
  • motherboard: substitute power supply unit (PSU) when there no signal from motherboard (connect to the screen to test it).
  • car: ca2 "Host-Stem Link: DOWN" message: try to reset baudrate console and set it back. Otherwise hardware reset. Suggestions about how to perform the hardware reset procedure (attach resistor to serial cables). Differentiate between reset brainstem (tea and reflex files are not touched) and configuring a brand new card.
  • car: car is slower than others. Check that h-bridge connections to power and motor are solid. Check that all wheels spin fine and eventually clean and grease the faulty bearing.
  • car: encoder no signal, check serial cable connected in the proper way (link to h-bridge and encoder datasheet).
  • car: motor doesn't run. Check h-bridge connection to power and to motor or reset brainstem.
TO DOCUMENT
  • 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.
  • There's no differential on the rear axis.
  • No labels