Originally Posted by happul3

Thank you for the suggestion, I tried many (6) different surfaces, but no change whatsoever. Why is the "camera busy" problem happens only on start-up and only when mod program is running?

Is there any other troubleshooting I can do? Could you please explain which part of the code is responsible for slow blinking? Is it dr_loop()? Why is it so slow (1 blink per 2 sec; 0.5Hz)?

If your mod was built by macdrones you are not running the original code, so I can't help you since I don't have it. Do you know the revision of the mod your setup is built from?

Here is a hint, in the original code the 'slow' blinking (once every 3 seconds) happens when the 'sketch' has sent the configuration string to the companion program and times out waiting for C_ACK. This means, that either the companion program on the drone has died or does not get enough time to execute. Since the drone is turning the motor LEDs red, something is going on.

today something was gone bad.
after a good first fly, I changed battery, and... RC does not operate.
it looks like arduino did not started to load software to ar.drone.

ar.drone works well by original wifi connection.
when battery connected, arduino orange led blinks triple, a few seconds until ar.drone starts up. when ar.drone leds become green, the arduino orange led blinks around 1HZ and nothing is goining more.
when I turn the power of TX, this led starts to blink doubled.

in desperation I did:
reset ar.drone by hardware button
reset arduino board
reload original sketch 0.19
check arduino by PC terminal: looks well (as previously)
check ar.drone by wifi: look well and operates
check ar.drone by RC: nothing
arduino orange led blinks 1Hz, when TX on it starts to blink doubled.
when TX off this led still blinks doubled.



please, any idea?

Originally Posted by happul3

Thank you for the suggestion, I tried many (6) different surfaces, but no change whatsoever. Why is the "camera busy" problem happens only on start-up and only when mod program is running?

Is there any other troubleshooting I can do? Could you please explain which part of the code is responsible for slow blinking? Is it dr_loop()? Why is it so slow (1 blink per 2 sec; 0.5Hz)?

The solution you described - wait until Arduino slow blinks before turning on the Tx, when it speeds up and moves on - using the Rev 0.18 sketch was exactly what I did to get past the 'it just sits there' problem I described a few pages back. Now I do that every time, I get it to work about 9/10 instead of 3/4.

As different surfaces for the bottom camera didn't seem to fix it - left it where it was and it would work using technique above more often than not - I thought it might be a timing issue specific to my Drone/ Nano/ Rx/ Phase of the moon.

Originally Posted by Brandigan

Just got my FlySky CT6B, has anyone got a Mirumod compatible config file for it that they could PM me?

Anyone else needs one of these, PM me. You can either use one shoulder switch for Land/Fly and the other for FM1/FM2 or one channel on a dial to go through LAND/FM1/FM2 and leave the other channel free for something else.

Originally Posted by miru

If your mod was built by macdrones you are not running the original code, so I can't help you since I don't have it. Do you know the revision of the mod your setup is built from?

Here is a hint, in the original code the 'slow' blinking (once every 3 seconds) happens when the 'sketch' has sent the configuration string to the companion program and times out waiting for C_ACK. This means, that either the companion program on the drone has died or does not get enough time to execute. Since the drone is turning the motor LEDs red, something is going on.

I suspected that the issue is with companion program, just could not find which loop will result in slow blinking. Now I don't need to look since the author provided this important clue about slow blinking - thank you very much!

So the problem is with arm code rather than arduino's and arduino's slow blinking is just an indicator, correct?Then the question is what can go wrong within the busybox? Is there any way to see what's going on inside, are there any persistent logs? Or perhaps the better question is how to revert to truly factory condition (I did reset/unpair, firmware reload already)? Or am I just deluding myself and the most appropriate course of action is to replace the motherboard?

Originally Posted by happul3

I suspected that the issue is with companion program, just could not find which loop will result in slow blinking. Now I don't need to look since the author provided this important clue about slow blinking - thank you very much!

So the problem is with arm code rather than arduino's and arduino's slow blinking is just an indicator, correct?Then the question is what can go wrong within the busybox? Is there any way to see what's going on inside, are there any persistent logs? Or perhaps the better question is how to revert to truly factory condition (I did reset/unpair, firmware reload already)? Or am I just deluding myself and the most appropriate course of action is to replace the motherboard?

You can 'telnet' into the drone and try to find out what is going on.

Originally Posted by miru

You can 'telnet' into the drone and try to find out what is going on.

Unfortunately, when drone is in the "all-red motor leds/slow blinking arduino" state, it does not accept wifi connections. Hence my question of any logs that survive reboot (persistent)...

today is not a good day. not at all.
after my problems last days, with mod kit stopped to response, what I fixed finally yesterday evening.
now:

my ar.drone's left-back motor fired up suddenly.

it did not started to rotate. it looked like it tried but without succes.
propeller turned around manually without significal problems of course.
it has not locked the system "error", I could try again and again without resetting a drone. and after 4 or 5 probe the motor fired up!

as I can google it, I'm not the first one. with this particular motor.
no lucky.

look closely, some chips on motor's board fired. maybe motor is fine,
but what's consolation, it cannot work without chips.

i have no idea what's happend and why. and even what to check before I will connect the new spare part (for what I have to wait days, days)

Originally Posted by JAN.GER

today is not a good day. not at all.
after my problems last days, with mod kit stopped to response, what I fixed finally yesterday evening.
now:

my ar.drone's left-back motor fired up suddenly.

it did not started to rotate. it looked like it tried but without succes.
propeller turned around manually without significal problems of course.
it has not locked the system "error", I could try again and again without resetting a drone. and after 4 or 5 probe the motor fired up!

as I can google it, I'm not the first one. with this particular motor.
no lucky.

look closely, some chips on motor's board fired. maybe motor is fine,
but what's consolation, it cannot work without chips.

i have no idea what's happend and why. and even what to check before I will connect the new spare part (for what I have to wait days, days)

Welcome to the club! I had the same problem (not with fire) and I had my drone swapped with a new one (it had only 2 months!).

There are a lot forums covering this problem, if your drone is under warranty you will have it at least repaired for free, so check with your local Parrot people.

Otherwise, if you ESC board wasn't totally fried, you can try to fix it by yourself, changing the MOSFET which usually get burnt:

http://www.rcgroups.com/forums/showp...01&postcount=1

Hope it helps!
G.

Originally Posted by happul3

Unfortunately, when drone is in the "all-red motor leds/slow blinking arduino" state, it does not accept wifi connections. Hence my question of any logs that survive reboot (persistent)...

The rev 0.18 mod is not producing any. But the fact that you get the Arduino to wait for an ACK for the configuration means, that it must have been able to upload the companion program, unzip it and start it, otherwise chances it would be in that spot are fairly slim (something else on the drone would have to send a CTRL-B to /dev/ttyPA0).

Originally Posted by miru

The rev 0.18 mod is not producing any. But the fact that you get the Arduino to wait for an ACK for the configuration means, that it must have been able to upload the companion program, unzip it and start it, otherwise chances it would be in that spot are fairly slim (something else on the drone would have to send a CTRL-B to /dev/ttyPA0).

Yes, I do see that arduino led goes dim (transfer), then full bright (unzipping), and gets magic character back. Then something bad happens, crash of some sort, hanging the busybox. My question is what do you suppose can cause it? You have mentioned that the bottom camera can cause problems with your code's starting up. Would you mind elaborating on that point? It must have something to do with timing of busybox threads? Do you suppose gyros/accels can also cause similar effects if they provide "noisy" output, consuming too much of CPU time? If so, it may be nav board rather than the motherboard that needs to be replaced, right?

Originally Posted by happul3

Yes, I do see that arduino led goes dim (transfer), then full bright (unzipping), and gets magic character back. Then something bad happens, crash of some sort, hanging the busybox. My question is what do you suppose can cause it? You have mentioned that the bottom camera can cause problems with your code's starting up. Would you mind elaborating on that point? It must have something to do with timing of busybox threads? Do you suppose gyros/accels can also cause similar effects if they provide "noisy" output, consuming too much of CPU time? If so, it may be nav board rather than the motherboard that needs to be replaced, right?

There is no direct interaction between the bottom camera and the companion program, they just share the same processor. The busybox is a command interpreter (aka shell) that has most of the standard UNIX commands built-in to save code space on the target system. I don't think it has anything to do with the problem.
I would tap into the TX line from the drone (at the Arduino) with a FTDI board (just GND and RXI, 38400 baud once the mod is up, 115200 before that) and observe if there are any clues...

Originally Posted by miru

There is no direct interaction between the bottom camera and the companion program, they just share the same processor. The busybox is a command interpreter (aka shell) that has most of the standard UNIX commands built-in to save code space on the target system. I don't think it has anything to do with the problem.
I would tap into the TX line from the drone (at the Arduino) with a FTDI board (just GND and RXI, 38400 baud once the mod is up, 115200 before that) and observe if there are any clues...

I am sorry for the incorrect terminolgy; By busybox I meant the whole linux system kernel and whichever processes are running. I also did not mean to imply that the companion program itself interacts with camera, but, based your previous suggestions, camera can somehow cause problems with operation of your code. Be that as it may, the putative crash that I observe must happen somewhere in that linux system, right? Remember, the drone does not accept wifi connections in that state, which means that the respective thread is not running. The companion program shouldn't be able to cause that because of preemptive multitasking (I assume that). Do you agree that lack of wifi connectivity suggests that the problem is not with arduino and not with the companion program? If so, what could I possibly get from tapping into TX line?

Originally Posted by happul3

I am sorry for the incorrect terminolgy; By busybox I meant the whole linux system kernel and whichever processes are running. I also did not mean to imply that the companion program itself interacts with camera, but, based your previous suggestions, camera can somehow cause problems with operation of your code. Be that as it may, the putative crash that I observe must happen somewhere in that linux system, right? Remember, the drone does not accept wifi connections in that state, which means that the respective thread is not running. The companion program shouldn't be able to cause that because of preemptive multitasking (I assume that). Do you agree that lack of wifi connectivity suggests that the problem is not with arduino and not with the companion program? If so, what could I possibly get from tapping into TX line?

'program.elf' with it's omnious threads is quite chatty on that port when things don't go the way it thinks they should...

Originally Posted by miru

'program.elf' with it's omnious threads is quite chatty on that port when things don't go the way it thinks they should...

I am confused: How could program.elf still do anything useful if drone does not accept wifi connections? I confirmed that manually killing program.elf does not prevent normal wifi communication. Therefore, not having wifi connectivity seems to indicate that that the whole linux system has crashed, not just the program.elf.

I did few experiments with telnet. Evidently, killing program.elf then restarting it by hand with "/bin/program.elf > log &" provides a lots of information - I just do not know how to interpret it. Interestingly, when I kill/start program.elf then turn radio on the drone can be controlled by radio normally; it takes off and land just fine. The log file created by dumping stdout of program.elf is quite large and contains lots of diagnostic information - some bits and pieces included below.
Surprisingly, some of that info changes in subsequent runs of program.elf even though drone remains powered. For example, on first try I got

340.477972 Master 6 1072 BLC call for motor 2
341.470168 Master 6 1072 BLC motor 2 flash & start FAILED
341.530048 Master 6 1072 BLC call for motor 3
341.642320 Master 6 1072 BLC motor 3 soft version 1.16, hard version 3.0, su
pplier 1.1, lot number 06/10, FVT1 01/06/10
341.700051 Master 6 1072 BLC call for motor 4
341.812324 Master 6 1072 BLC motor 4 soft version 1.16, hard version 3.0, su
pplier 1.1, lot number 06/10, FVT1 01/06/10
341.840043 Master 6 1072 BLC motor 2 dead
341.840371 Master 6 1072 BLC reflash required, perform off/on cycle

And on three subsequent tries, motor 2 passed fine, same as other motors.
It is alarming to see that there is an intermittent failure on motor 2, but that can't be the reason I am having problems described in my previous messages.

Other alarming thing in that log (and it is reproducible run-to-run) is that there are hundreds of repeating messages like following. Is it just temporary, until program.elf initializes? Or does it indicate some problem with specifically my drone? Could some kind soul please check what their program.elf say when started?


1017.831237 Master 6 1080 ********* Previous runs gave emergency ******
***
1017.831290 Master 6 1080 Pic software version not ok !!!
1017.831317 Master 6 1080 mykonos_state = 0x80000000
1017.831363 Master 6 1080 vbat = 0
1017.831388 Master 6 1080 ctrl_state = 0x00000001
1017.831415 Master 6 1080 -----------------------------------
1017.831438 Master 6 1080 Motors have not been initialized correctly !!!
1017.831461 Master 6 1080 mykonos_state = 0xc7801000
1017.831483 Master 6 1080 vbat = 0
1017.831506 Master 6 1080 ctrl_state = 0x00000001
1017.831529 Master 6 1080 -----------------------------------
1017.831551 Master 6 1080 Emergency signal sent by user !!!
1017.831574 Master 6 1080 mykonos_state = 0xcf810054
1017.831596 Master 6 1080 vbat = 11107
1017.831618 Master 6 1080 ctrl_state = 0x00000000
1017.832159 Master 6 1080 -----------------------------------
1017.832201 Master 6 1080 Angles out of range !!!
1017.832228 Master 6 1080 mykonos_state = 0x8f888014
1017.832250 Master 6 1080 vbat = 10561
1017.832274 Master 6 1080 ctrl_state = 0x00000000
1017.832299 Master 6 1080 -----------------------------------
1017.832321 Master 6 1080 Angles out of range !!!
1017.832344 Master 6 1080 mykonos_state = 0x8f880014
1017.832366 Master 6 1080 vbat = 11817
1017.832389 Master 6 1080 ctrl_state = 0x00000000
1017.832413 Master 6 1080 -----------------------------------
1017.832435 Master 6 1080 Angles out of range !!!
1017.832457 Master 6 1080 mykonos_state = 0xcf880810
1017.832479 Master 6 1080 vbat = 12509
1017.832501 Master 6 1080 ctrl_state = 0x00000000
1017.832525 Master 6 1080 -----------------------------------
1017.832546 Master 6 1080 Angles out of range !!!
1017.832568 Master 6 1080 mykonos_state = 0x8f880414
1017.832590 Master 6 1080 vbat = 12291
1017.832613 Master 6 1080 ctrl_state = 0x00000000
1017.832636 Master 6 1080 -----------------------------------
1017.832657 Master 6 1080 Emergency signal sent by user !!!
1017.832679 Master 6 1080 mykonos_state = 0x8fcb0414
1017.832701 Master 6 1080 vbat = 12266
1017.832724 Master 6 1080 ctrl_state = 0x00000000
1017.832747 Master 6 1080 -----------------------------------