Since nothing I've so far seems to help, I then restored the sketch to the last working version - ie, pin9 active high and non-flashing. This seems to solved the problem. It has worked consistently for the last 5 power cycles.

Wondering if the issue has something to do with the flashing pin9 or is it just simply a bad sketch load the last time.

That was a premature concludion. When I tried it again with the ardrone on my work bench, it happened again. Nothing I was able to do to resolve it. Then I took it to my "computer room" so I can restore it to mirumod version .008. Just before I fired up my laptop, I gave version .009 another chance, I plug in the battery and it worked! again and again without a single startup failure. Now that was interesting...

I back step and return to my work bench, put the ardrone on the exact spot and plug in the battery. Yes, it failed to startup again! It was the first time I felt good about a failure!! Could it be the all metal work bench?? To confirm, I put a small cardboard box under the ardrone to raise it off the metal desk and try again. It started up OK. I repeat this quite a number times with and without the small box under the ardrone. Result were very consistent. I can repeat the results at well. Now it is obvious the metal bench is causing interference to the ardrone.

It is also interesting to note that the RC transmitter, was about 8 feet away on another table.

Wondering which component - the arduino, the RC rx, ardrone itself that prevents a proper start up. May be miru can tell by observing the arduino's flashing sequence.

I also did other controlled test with the tx 12 inches away from the ardrone in all directions and experienced no problems with the ardrone start up sequence. One test that did cause a failure is when I have the tx hanging from my neck and start the ardrone right next to the tx in front of me - a typical field battery changing scenario. Wondering if others can try this and report.

Here's a couple of picture of my test.

This position is where the ardrone fails to complete a start up:



Raise the ardrone 3 inches off the top of the bench, it works.



With the RC tx 12 inches away from the ardrone in all 4 directions would not cause any startup problems.



From the about tests, I am very confident to conclude that it is not a software issue. miru, you can sleep better now.

Originally Posted by nickname

That also solved my problem. Firmware 1.7.4 works, and I can confirm that 1.4.6 definitaly NOT works with dsr008 and dsr009.

Do you remember what did not work, or where it got stuck?

Originally Posted by Candu1

From the about tests, I am very confident to conclude that it is not a software issue. miru, you can sleep better now.

Thank you Candu1! I was already scratching my head.

What flashing sequence do you get when it is on the bench (no cardboard)?

I did change the startup in rev 0.10. Now the Arduino program looks at 4 things in the same loop: 1) is the radio ok 2) is FMODE LAND 3) have 10 seconds gone by so I can assume the drone has booted and 4) did the drone program.elf finally quit dumping messages to /dev/ttyPA0. The 'offending' condition is signaled with 1, 2, 3, or 4 blinks. If all 4 conditions are met, then it will quit the loop, get a shell started, change baudrate if neccessary and do the thing. Previous versions checked 1, 2 and 3 in one loop and 4 in the next.

Originally Posted by miru

Thank you Candu1! I was already scratching my head.

What flashing sequence do you get when it is on the bench (no cardboard)?

I did change the startup in rev 0.10. Now the Arduino program looks at 4 things in the same loop: 1) is the radio ok 2) is FMODE LAND 3) have 10 seconds gone by so I can assume the drone has booted and 4) did the drone program.elf finally quit dumping messages to /dev/ttyPA0. The 'offending' condition is signaled with 1, 2, 3, or 4 blinks. If all 4 conditions are met, then it will quit the loop, get a shell started, change baudrate if neccessary and do the thing. Previous versions checked 1, 2 and 3 in one loop and 4 in the next.

Another short test just to confirm that it is the interaction between the metal desk and the ardrone/Rx/arduino, and nothing to do with the RF signal. I simply swap position between the tx and the ardrone - ie, put the tx on the metal desk at the exact spot where the ardone was and put the ardrone at the table where the tx was. As predicted, it started up OK. I also confirmed that the rx LED was on solid to indicate that it is binded and receives signals from the tx, so it's not a matter of the metal desk blocking RF signal from the tx reaching the rx.

OK, the arduino flashes from power up to the end looks exactly the same as a normal startup. ie, Double flash at the beginning, one triple flash, and then 39 or 40 1/2 second slower flashes, then, solid green for a second. At this point, for a normal start up sequence it would flash the ardrone LEDs to double green/red and then turns the LEDs to solid green. But in the failed case, the four ardrone LEDs would switched from solid green to solid red and rest in red. The single LED underneath the ardrone would then turn from solid green to solid red. At this point, any wifi connection is dropped. The arduino LED then turns off for a second then it either comes back with 2 flashes a second continuous flash or comes back with a solid green. No control is available from the Tx with a failed start up.

During the faild startup sequence, I also tested wifi connection to the ardrone wiht my iTouch. I was able to connect while the ardrone's LEDs were solid green. As soon as the ardone LEDs turned red, I would lose wifi connection on the iTouch. I was also using telnet to explore /data subdirectory to see if there were anything obvious in there left over from a previous boot that either mirumod or ardrone would check to prevent a normal start up. Did not find anything obvious...

I was speculating at one point that your onboard program would check for something after control was passed over to it and if it doesn't see some predefined conditions, it would then turn off ardrone's wifi.

Originally Posted by Candu1

I was speculating at one point that your onboard program would check for something after control was passed over to it and if it doesn't see some predefined conditions, it would then turn off ardrone's wifi.

It does not turn wifi off, it manipulates the iptables to route navdata through itself and to block iDev AT*REF and AT*PCMD. There is a comment in the shellscripts on the drone that states one does not want to use iptables too many times... it might crash the OS. This is really weird, because the mechanism works fine on all the Linux boxes I run no matter how often I change it. Maybe they messed with it?

Originally Posted by DTOMPKINS

@FrankT I had the same problem. It was corrected with the latest firmware upgrade 1.7.4. I had been originally running 1.4.6.

Thank you! will try that.

//Frank


Update: it works with the new firmware!

I have had similar problems. It seemed to me the problem was the down facing camera. When it would not start, I would put my finger over the down facing camera and reapply power. Once it is connected I would unblock the down facing camera. I first noticed the problem when going from inside the house to the outside. I concluded it had something to do with the brighter light outside.

Originally Posted by rrobbins6111

I have had similar problems. It seemed to me the problem was the down facing camera. When it would not start, I would put my finger over the down facing camera and reapply power. I first noticed the problem when going from inside the house to the outside. I concluded it had something to do with the brighter light outside.

Well...does that limit your flying to night or dark rooms?

You need a vacation!

Originally Posted by rjrobbin

Well...does that limit your flying to night or dark rooms?

You need a vacation!

Don't you have some work to do ?

Many reasons for malfunctions of the Parrot drone

Dear Parrot Miru Mod friends

If your drone with Miru Mod does not fly perfectly or if you have start-up problems, you might apply this simple checklist:

1. Disconnect everything from your drone which has to do with the Miru Mod.

2. Tray to fly the drone with your i-Device. Flight and NAVdata ok? If not, find out what is not working. I had this problem once with a broken front camera: only by monitoring the start-up procedure on the HyperTerminal I could understand the main problem.

If everything is ok:

4. Load the Miru Mod Software (in my case: 009) on the Arduino (Please: drone connector NOT plugged-in!)

5. Make sure that the Spektrum RC-Receiver (Antenna) is not to close to the drone main board. Give a space of about 3 inches!

6. Download Miru Mod Tutorial Part 1 and follow every step:
http://ufo-doctor.ch/descriptions/Pa...art%201_V8.pdf

Perhaps this advice will help! I wish you good luck!

Kind regards
UFO Doctor

Originally Posted by miru

It does not turn wifi off, it manipulates the iptables to route navdata through itself and to block iDev AT*REF and AT*PCMD. There is a comment in the shellscripts on the drone that states one does not want to use iptables too many times... it might crash the OS. This is really weird, because the mechanism works fine on all the Linux boxes I run no matter how often I change it. Maybe they messed with it?

miru, for your peace of mind, I finally discovered my problem. Drained a 2350mAh battery doing trail and error to finally determined the real cause of the problem. It's not your mod. I disconnected your mod and confirmed it with my iTouch. Ardrone reports a connection error message when it failed a start up on top of the metal desk.

It was very interesting since I test the startup with the ardrone:
- on the roof of my car (metal) - start up OK.
- on the floor - start up OK
- on other desks/tables - start up OK.
- wasn't able to find another location to fail startup.

Back to my shop, put the ardrone on top of my metal desk - failed!
- put the carboard back under the ardrone - startup OK.
- put a smaller box to raise the ardone by 1/2 inch - startup OK



- remove smaller box - failed!

- raise the RC receiver and arduino up off the ardrone by 2 inches - failed



- put a very small box under the ardrone (look hard to see it) - Start up OK



After this test, the LED in my head (not the traditional light bulb any more) came on bright! and you probably have guessed what the problem is by it now.

This is what is causing the problem:



It's a non slip type of material you can pickup for a dollar at the Dollar store. It's normally used to line your draws to prevent contents from rolling around but I use it on my work bench so small parts such as screws, nuts, circlips!, etc. would stay in place.

I confirmed this by repeating the test with and without this mat on another desk and on top of my car. No buts. It is the problem.

See this video clip with the mat

Ar Drone test start up problem - Failed to start up (0 min 14 sec)

and this without the mat

AR Drone start up test - No problem (0 min 19 sec)

Now, miru, I too can sleep better...

Originally Posted by mistersatellite

I have made a movie of the startup.

My big question is i have pick a 5.6 K resistor because in the drawing it say 1 - 10K, but in order topics it say 4.7K

http://youtu.be/_piTs2jBWE4

I tried a lot of different of resistors but it is not working.

I measured on the AR Drone between pin 7 GND en pin 6 TXO that was 6 Ohm
Between pin 7 GND and pin 4 RXI was it 5 Ohm.

My question is of this is right.

I think i blown op de communications line with the Drone.
Flying with iDevice i not problem that is working wel.
Is some once can tell me of i am right.

Hi,

does anyone know, where to buy the small connector 855-M22-7140442 in Germany without paying 20,- € for packaging to mouser.com?

Hello Olaf,
Look here to Conrad

http://www.conrad.de/ce/de/product/7...archDetail=005

Greetings from Germany Matthias

Originally Posted by Candu1

miru, for your peace of mind, I finally discovered my problem. Drained a 2350mAh battery doing trail and error to finally determined the real cause of the problem. It's not your mod. I disconnected your mod and confirmed it with my iTouch. Ardrone reports a connection error message when it failed a start up on top of the metal desk.

It was very interesting since I test the startup with the ardrone:
- on the roof of my car (metal) - start up OK.
- on the floor - start up OK
- on other desks/tables - start up OK.
- wasn't able to find another location to fail startup.

Back to my shop, put the ardrone on top of my metal desk - failed!
- put the carboard back under the ardrone - startup OK.
- put a smaller box to raise the ardone by 1/2 inch - startup OK



- remove smaller box - failed!

- raise the RC receiver and arduino up off the ardrone by 2 inches - failed



- put a very small box under the ardrone (look hard to see it) - Start up OK



After this test, the LED in my head (not the traditional light bulb any more) came on bright! and you probably have guessed what the problem is by it now.

This is what is causing the problem:



It's a non slip type of material you can pickup for a dollar at the Dollar store. It's normally used to line your draws to prevent contents from rolling around but I use it on my work bench so small parts such as screws, nuts, circlips!, etc. would stay in place.

I confirmed this by repeating the test with and without this mat on another desk and on top of my car. No buts. It is the problem.

See this video clip with the mat

http://www.youtube.com/watch?v=MG5sEkTu5WQ

and this without the mat

http://www.youtube.com/watch?v=b7qhR_fGi7E

Now, miru, I too can sleep better...

Puhhh Candu1,
sometimes the drone is the best way to go into psychatrie, lol, but you found it!
My drone doesn't like to hover, the drone climbs 10cm was turning very quick right and flies to the right. After changing mainboard, test no result, changing navboard, no result, it was at least Motor 2 which confused the drone totally. Now it flies again.
Greetings from Germany Matthias