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?
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.
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
I know it's a lot, but you need all that to troubleshoot.
Also, I feel this thread is related:
Thanks, Kevin and sorry to hear those instructions are broken and you messed some equipment in the process, I was just trying to point them in a direction to at least start from.
Again, sorry if I pointed anyone to something wrong.
IMO, we should just close the comments on the Wiki pages and direct people to make important comments in the issues list, or on the board. Nobody is looking at the comments on the wiki pages, so unfortunately, it's where good ideas go to die.
Interesting, so how should I proceed to verify if the APM1.0's multiplexer IC is functioning properly and isolate this intermittent issue?
Well, as Kevin said, the red board is where the problem is. Either replace the IC, or replace the board. Being that it's $65 vs the $150 of the oilpan shield (blue board), how much is reliabity worth to you?
Further, APM 2.0 is less complicated in the regard and now better supported in the code (all the sensors such as optical flow work with the latest code release). It might not be the worst idea to just bite the bullet and upgrade the whole thing. So yes, this is a $65 dollar VS $200 decision, but may net you better performance and reliability.
We already have an APM 2.0, but are still hesitant to use it due to all the bug reports that appeared after release. I am just waiting for the gestation period and for us to do more ground testing on the 2.0.
We will definitely purchase the $65 Atmega board, but it is troubling we haven't been able to solidly identify that root cause of the failure. Especially, when this is an intermittent problem.
If it is the multiplexer that is not functioning properly, is this a common problem? What are the risk margins for this that specific multiplexer? I really would like a DIY Drones employee chime in on this and at least make me feel more confident with their product. We have a lot of visibility and will receive a lot of heat on this project from certain organizations. I don't want to abandon the Diy Drones APM boards, but if I can't say for sure 100% that the next board won't crash the UAV due to a silly multiplexer IC problem then we're all toast.
This looks like a very heated thread.
Unfortunately, upon recovering APM 1.0 board I found that it didn't log any files on board for some reason. So I can't verify what the last commands were of the crash -determine if it still used the last RX outputted commands.
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...
so, got the wires in place and he is airborn :-)
just did a maiden flight back in the garden and went very well.
stable and smooth flight.
tomorrow I will give it a shot with some other flight modes.
esc: hobbyking 20 SS (hw) flashed with SimonK firmware
motor: keda 2210
frame: quad x
Thanks for the update. Do you think this is a problem with the multiplexer or just the physical connection between the 2560 and the PL4...PL5..etc mux
In my case it was a physical connection between the mux and the 2560 µP.
There were 2 bad vias between the top and bottom of the pcb.