So our plane crashed while flight testing the APM 1.0. The aircraft simply stopped responding to pilot control as if the entire board shut off. We were not using any autopilot modes but was in manual. We recovered the autopilot as it was completely intact while being protected by a wooden enclosure.

We set up a test bed with the receiver connected to the APM 1.0 and servos from both the APM rail and the receiver. The receiver and the APM board are powered independently on a power supply, and we just had an operator sit there for an hour moving the radio joysticks around. Out hours of testing, there was one occurrence where the servos connected to the APM stopped moving, while the servos connected to the receiver directly continued to move. Therefore, the pilot radio and the receiver works. In this instance we checked the Mission Planner that was running and the Radio Input bars and HUD were both showing PWMs changes coming from the Xbee connection. So the APM is reading the PWM from the receiver, but not relaying them to the servos....

So why is the PWM not going to the servos from the APM board?! Do you guys recommend any specific type of diagnostic to find the source of this problem?

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • Hi,


    I ran into similar problems using the APM1 for my quad.
    Testflights showing irregular speeds for motor 1 and 2 (sudden stops, spinning up)

    After a bench test yesterday output 1  & 2 just stopped working period.

    I took the schematic and found out that the connections from the 2560 to the mux (PL4 and PL5) were bad.
    There are two via's under the µP that are no longer conducting.
    I will now try to hard wire them.

    To be continued...

  • Ok, there are a few things that are different about APM 1.0 vs APM 2.0 that make your troubleshooting an intermittent issue like this harder. The APM 1.0 uses a multiplexer IC and thus that is one possible point of failure. This chip is on the red board near the outputs.

    To debug the mega 2560 you must use JTAG as outlined here.

    http://code.google.com/p/ardupilot-mega/wiki/JTAG

     

    Just my opinion but if the APM continued to ouput the data via the telemetry port, then the assumption is the code was running at the time, and that points squarely at the multiplexer chip.

    APM 2.0 uses direct outputs of the mega 2560 and thus is easier to troubleshoot and has one less failure point.

    Schematics of course use Eagle CAD

    http://code.google.com/p/ardupilot-mega/wiki/Hardware

    I know it's a lot, but you need all that to troubleshoot.

    Also, I feel this thread is related:

    http://diydrones.com/group/apmusergroup/forum/topics/channel-one-an...

     

This reply was deleted.

Activity