Connects, but remote control does not work

[mattist]

Hi, I had a heavy landing and broke the central cross, and bought a new one. I have carefully followed all the youtube instructions both for replacing the central cross and the engines/gear/rotor blades. When testing it, everything connects as it should. all the 4 red lamps is on, wifi works and connects, status light is green. I get the streaming video on my Iphone, but the problem is that nothing happens when I try to take of. No action at all, no engines starts. What could possibly be the problem? I have several times pressed the reset button, and battery is 100 %.

[droneparts_de]

Thanks for your detailled description. Gives us a good picture...
First of all: the green mainboard LED indicates that your mainboard is not damaged. If you have 4 red Motor LEDs the drone will never start. Shows the arrow of the central cross in the direction of the main cam?
Please review the small PINs of the brown(?) plug on the mainboard. Is one broken or damaged? Often this is the cause...

[szuu]

what a coincidence!
today i broke my drone with similar symptoms (i.e. all red, flying not possible, no emergency message, but it looks like everthing works).
and now i know the reason: damaged calibration data in the navigation module. they forgot to put an error message for this (rare?) situation so from the outside the only indication is "all reds".
i don't know if this can happen in the real life (in my case it was a hack that went wrong) but here is how you can check:
- easy way: get an application that displays some navigation data (e.g. Flight Record). does the altitude/compass/artificial horizon indicators work?
- text mode way: telnet your drone and see the /data/config.ini. if the numbers in the [control] section look weird, then your calibration data is damaged. by weird i mean all zeros or very big numbers. the correct data for my navigation board is:

Code: Select all

[control]
accs_offset                    = { -2.1735115e+03 1.8073560e+03 2.1002366e+03 }
accs_gains                     = {  9.8032218e-01 2.7658001e-02 3.5442106e-02  -7.3236146e-04 -9.7881901e-01 5.4326389e-02  2.2266259e-02 -7.1581058e-02 -9.8339200e-01 }
gyros_offset                   = { 1.6626820e+03 1.6640601e+03 1.6283220e+03 }
gyros_gains                    = { 6.7586568e-03 -7.2052348e-03 -3.5841882e-03 }
gyros110_offset                = { 1.6738380e+03 1.6811500e+03 }
gyros110_gains                 = { 1.4873539e-03 -1.5869513e-03 }
gyro_offset_thr_x              = 4.0000000e+00
gyro_offset_thr_y              = 4.0000000e+00
gyro_offset_thr_z              = 5.0000000e-01
pwm_ref_gyros                  = 470

and the damaged version:

Code: Select all

[control]
accs_offset                    = { 9.1897153e-41 2.5884560e-34 4.4019267e-35 }
accs_gains                     = {  4.1570244e-35 4.8533487e-35 1.3729922e-35  4.7207856e-35 1.0908015e
+16 0.0000000e+00  5.2660796e-42 0.0000000e+00 4.0407618e-39 }
gyros_offset                   = { 6.1389026e-34 9.0915437e-32 4.7400645e-35 }
gyros_gains                    = { 3.2730438e-35 9.4613893e-39 9.3833748e-41 }
gyros110_offset                = { 4.7321087e-37 3.2325153e-41 }
gyros110_gains                 = { 4.2894312e-30 0.0000000e+00 }
gyro_offset_thr_x              = 0.0000000e+00
gyro_offset_thr_y              = 2.7556815e-40
gyro_offset_thr_z              = 2.5884560e-34
pwm_ref_gyros                  = 3052

parrot says that every navigation module has its unique calibration, stored in the chip during the manufacturing process. this means that even if someone diagnoses the problem but does not have a backup of the correct configuration (i have!), the repair could be impossible or more difficult.
for now, i don't know how to save the corrected data (saving the config file is not enough as the drone reloads it from the navigation board each time), but it is certainly possible, as all the data is stored in the PIC chip, which is programmable. the parrot SDK even discloses the command for this job, but without any information about how to use it:

Code: Select all

ARDroneLib/Soft/Common/ardrone_common_config.h
ADC_CMD_SEND_CALIBRE            = 13, /**command to ADC to send the calibration

[szuu]

...and now i know how to fix it
the original calibration data can be found in /firmware/ADC/save_calibration_mv
(but if you replaced the navigation board or the mainboard then the data won't match your current navigation board!)
the actual data starts from 4th byte, so let's use cut to extract bytes starting with 5

Code: Select all

cut -b 5- save_calibration_mv >extracted.bin

(note: the drone cut implementation does not seem to work on bytes. i used my "big" linux commandline here)

then, send the calibration to navboard:

Code: Select all

killall program.elf
gpio 132 -d ho 0
gpio 132 -d ho 1
stty -F /dev/ttyPA2 460800 -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke
(echo -ne "\x0d"; cat  extract.bin) >/dev/ttyPA2 

reboot
and it works!
interestingly, the data returned by the navboard command 14 is not exactly the same bytes as before (only the first part matches - maybe this is not completely correct way to send the calibration data?) but the config.ini [control] section looks like in my old backup.

AR Drone Navigation Board article was invaluable help in repairing my navboard - thanks!

[Candu]

Very interesting and educational.

(but if you replaced the navigation board or the mainboard then the data won't match your current navigation board!)

Does that mean that the calculation data is unique to each individual Nav board only? or is it unique to a combination of Nav board and Main board?

Wonder if the calculation data ever get outdated and recalculation would be needed as the Nav board gets old or gets mis-aligned from hard landings/crashes. If so, our ardrones may need a "tune up" once in a while...

[szuu]

Does that mean that the calculation data is unique to each individual Nav board only? or is it unique to a combination of Nav board and Main board?

the calibration data are parameters of the sensors on the given nav board, the main boards do not exhibit such variation, they are all the same
but it turns out the parrot software automatically creates a calibration data backup (on the main board of course). i learned about it in a bad moment - after discovering that my current backup file contains the broken calibration (from before the repair)
i don't know when it has happened... yesterday i only viewed the data in the file as hex and noticed a regular pattern (probably a bunch of round floating point numbers), today i wanted to backup the file to my computer and see the real numbers but it's too late - it has been overwritten. so i lost the unique chance to see the virgin calibration data of the board that has never seen a navboard before (as this is the brand new board, purchased as a spare part (hello droneparts_de!))

Wonder if the calculation data ever get outdated and recalculation would be needed as the Nav board gets old or gets mis-aligned from hard landings/crashes. If so, our ardrones may need a "tune up" once in a while...

yes, you might be right! all these sensors are all micro-mechanical devices and it is inevitable they eventually get old. the question is, if this can have real influence on the performance. or maybe they will simply break long before a significant calibration change would be required.

[Candu]

it turns out the parrot software automatically creates a calibration data backup (on the main board of course)

Here's how I understand it, based on your description: Every Nav board is calibrated at the factory and its sensor parameters from the calibration process are stored in a "calibration file" on the Nav board. After replacing an old Nav board with the new one, this "calibration file" from the new Nav board is backed up in the Main board (automatically ?), over writing the old calibration file.

During boot, the calibration parameters are copied from the Nav board to memory. If for what ever reason the calibration file on the Nav board is damaged, then the backup file from the Main board will be used to restore the damaged file on the Nav board. Am I on the right track? Is file recovery automatic? If not what and where is the utility to use? Or would this be done only at the repair depot?

[szuu]

correct, but...

If for what ever reason the calibration file on the Nav board is damaged, then the backup file from the Main board will be used to restore the damaged file on the Nav board

...in my case the calibration data was damaged and the drone did nothing to correct it maybe it thought the data is correct - or the backup restoration is not automatic and meant for the technical support.

it is all weird, because i had my new main board for several days and shortly after the "incident" it still containedthe pristine calibration backup - from the factory, not from my navboard (i used the old backup from my old mainboard for the repair).

however... if anyone of you replaced a mainboard or a navigation board recently, we could check if the mainboard backup contains your current navboard calibration or the old calibration (by comparing /data/config.ini and /firmware/ADC/save_calibration_mv)