Replies to This Discussion

3D RoboticsPermalink Reply by Alan Sanchez on February 29, 2012 at 2:48pm

Hi Emiliano, we have seen this problem in the past. The cause is the dataflash card not initializing correctly. To verify this is the problem, take it out and try to power your apm 2 again. You should be able to go through the tests in the CLI successfully. If this was indeed the case, there is an easy fix. Put the dataflash back in, and power the board up while looking at the terminal screen. It will reformat the card (this will take A WHILE). Leave it plugged in for a good 5-10 min. After that you should see a "ready to fly" message. You only have to do this once. Hope this helps

• ▶ Reply

Permalink Reply by Emiliano Fortunati on March 1, 2012 at 2:43am

Thanks Alan for your suggestions, I'm sure that my problem is in that direction.

 

As I wrote to Colin first, after a lot of ERASE and RESET I've a normal boot. 

The very strange situation is that if I load the 2.28 from Arduino I've a 99% of normals boot, if I load the 2.28 from MP to have a normal boot I've to do a lot of ERASE and RESET (CLI).

ALLWAYS I've a regular boot if I press the reset switch on the board after the first BLUE LED FIX.

• ▶ Reply

Permalink Reply by Colin Bouriquet on March 1, 2012 at 3:34pm

Thanks guys. We'll try it out tomorrow afternoon on the field.

One thing i've noticed, the dataflash card is loose in it's slot... it disconnects sometimes. Tonight i'm gonna tray Alan's suggestion and run a test tomorrow.

I'll also install a fresh version of AP 2.28 through Arduino.

We've taped the dataflash card to make sure it's not sliding out anymore.

I'll inform you of the results.

• ▶ Reply

Permalink Reply by Colin Bouriquet on March 2, 2012 at 7:04pm

So... very unpleasant day to the field today... we've encountered some of the problems we had before... even bricked the XBees once (this haven't been happening in a while, still painful having to unmount everything to unbrick them)...

BUT... we managed to get it working powering first the board with USB. If we boot from battery APM2 locks half the time or less... we then get this weird GPS problem i've explained before : sats counting, sometimes up to 8, never finding a fix, then dropping back to 2 or 3 and counting again... never finding the fix.

We plug the board back on USB : instant fix. Then battery boot, no fix...

Again we've tried erasing, resetting, uploading with mission planner, arduino, even compiling from GIT with arduino... It NEVER works.

With THIS procedure, it has worked 4 times on the last 4 tries (we were running out of batteries) :

— Plug the board to USB and wait it to boot (Xbees unplugged)

— Connect to mission planner, it resets the APM2 and it boots again (let it calibrate well until it shows ready to fly)

— Connect the battery (maybe the board will reboot again, if it does let it go through the procedure once again)

— Disconnect mission planner and unplug USB

— Connect the GCS Xbee on the computer (if the plane's Xbee is already connected don't, it will either mess up windows with the serial ballpoint mouse bug, or brick the Xbee)

— Connect the plane's Xbee

— Connect the mission planner (with Xbees)

Then again this procedure is VERY painful, but for us it appears it's the only way to go... The GPS was first incriminated but using this procedure shows no problem at all. It must be Arduplane related...

I've found a reference there : http://code.google.com/p/ardupilot-mega/wiki/Troubleshooting

(I'm using a MediaTek GPS, and although the module's blue lock LED goes solid, APM is not showing a lock)

However it seems to be related to APM1... but still, same problem with APM2...

• ▶ Reply

DeveloperPermalink Reply by Randy on March 2, 2012 at 7:37pm

@Colin,

     With the experimenting you've done I suspect you're fairly close to finding the solution.  It really must be voltage related.  I'd guess that if you measure the voltage of your APM (check the voltage across the bottom and middle pins of the right-angle-headers going out to the ESCs) you will find that there's a significant difference when you have the USB plugged in vs the battery.  My guess is that it's lower with the USB.

     I suspect the issue is that with the battery, the voltage that the APM uses is high (like nearly 6V) but the GPS is running at 3.3v...and so the APM may be having a problem sending or receiving messages because it may interpret even the high 3.3v output of the GPS as a zero instead of a 1.  So I'd say you could fix this by either somehow getting the voltage when using a battery lower (maybe your BEC is set at 6V instead of 5V?) or put a level converter on the GPS's tx line (i.e the line that carries the message from the GPS to the APM).

• ▶ Reply

Permalink Reply by Colin Bouriquet on March 2, 2012 at 7:48pm

Hi Randy. Thanks for your answer. The ESC outputs 5v (on several measurements we had between 4.98 and 5.02). We've also tried with another 2 different ESCs, same problem appears. I'll check the voltages on the board like you mentioned.

About the GPS... it's an APM so everything is soldered so we can't really access the Tx line.

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page