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

Compare with Current View Page History

« Previous Version 60 Next »

INDEX

THE GENERAL PROBLEM

The goal of the project is to set up an experiment that proves the effectiveness of an algorithm for collision avoidance at intersections. Three cars run on a test-bed following three different paths that all intersect in a single point. Cars are controlled by an on-board computer. Cars positions are measured by six cameras on the ceiling. Cars speed can be measured by an encoder mounted on the rear axis.

The algorithm requires the prediction of the time at which a car enters and exits the intersection. For this reason disturbances and the input signal are assumed to be monotonic with respect to the position along the path. The main tasks of this work are to:

  • determine and limit the disturbances that make the prediction too much uncertain;
  • identify a model of the system that is suitable for the long term prediction that the algorithm requires.

SUMMARY OF THE CURRENT STATUS

CURRENT PROGRESS

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.
  • 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 section #2D SPEED TESTING.
  • 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.

Model

  • Determined effect of battery status on cars speed.
  • Determined effect of the capacitor used to filter the power on cars speed.
  • First analysis on the effect of motor and steer input on speed.

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

DISTURBANCES ANALYSIS

LINEAR MODEL
Djumps

CPS

CAMERA MEASUREMENT ERROR CORRECTION

Problem
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 30cm. This negatively affects the ability of the car to accurately follow a path which is a crucial aspect in limiting disturbances.

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.

Solution
I decided to apply a linear correction to the computed global coordinates error along both direction. 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.

Moreover, 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.

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

2D SPEED TESTING

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

These are likely to be moved on the main page at some point.

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