...
- 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.
- 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.
- 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 never found the same problem with car 1 and 3. Most of the times this happens, there is no timeout of the recvfrom() function which receives the data from computers. This suggests that the problem resides in the on-board computer more than in the connection. The reason could be originated by both hardware (the motherboard of car 2 is an older and slower model with respect to car 1 and 3) and software (out-of-date operating system or some background program that takes too much resources).
- Car 2 cannot handle high engine voltages for a long time. After about 2 minutes at constant PWM 200 the car's speed dropped exponentially. This does not happen with cars 1 and 3. Substituting the h-bridge and the battery did not help. Anyway, a motor controller that is not very stressful does not cause troubles.
- The encoder of car 1 often does not give signal at the beginning when the car starts running. It starts working only after about 10 seconds.
TROUBLESHOOTING
- motherboard: substitute power supply unit (PSU) when there no signal from motherboard (connect to the screen to test it).
- Router It happened to me once that the computers kept connecting and disconnecting to the local network making impossible to estabilsh a connection between them and with the cars. When this happened, removing the internet cable from the router (the one that is plugged to the wall) fixed the problem.
- Motherboard You can test if a car's motherboard is working by connecting it to the screen and turning the car on. If it doesn't, usually the cause is the power supply unit (PSU). Try substituting that piece.
- 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 Engine When a car is particularly slow, check that h-bridge connections to power and motor are solid.
- car: encoder Encoder no signal, check that the serial cable is connected in the proper way (link to you can find the h-bridge datasheet http://www.acroname.com/robotics/parts/S11-3A-EMF-HBRIDGE_datasheet.pdf and encoder datasheet in the electronic components catalog on the shelf).
- car: motor Motor doesn't run. Check that the h-bridge connection to power and to motor or reset connections are solid. If they are, try resetting the brainstem.
- car: steer Steer is biased. Cannot be corrected completely mechanically. Set offset The steer cannot be set straight only mechanically. You must set the offset parameter in RoboCar_Lib.tea.
DISTURBANCES ANALYSIS
...