Hi, Ardupilot 2.6 (still with thermopiles) did a pretty good job in handling our solar drone (seriously, http://diydrones.com/forum/topics/lusa-low-cost-unmanned-solar?id=705844%3ATopic%3A445243&page=2#comments), now we bought APM2.0 to improve the results thanks to the ultra-precise IMU and other things such as the built in compass that can help controlling such a weird-handling plane like that.
But we also noticed that ardupilot code&hardware has grown so much in complexity, and this is kinda scaring us, since it will be in charge of a $1000+ 2000hrs of labor plane...
All what it will be required to do is to keep the plane loitering with excellent precision, nothing else for the moment, our main concerns are:
- Are there some timers or counter that may overflow or something causing errors after a long period of continuative use? It will probably be around 4 hrs?
-Are there known issues for APM2.0 operating in a pretty hot enviroment? (around 50 / 60 celsius)
-Are there known issues with partially-configured autopilots? (we will not explore, at least for a while, the ardupilot`s advanced functions)
-Are there any known failsafe failures? I keep the radio in my hand for the whole flight, ready to swith to manual mode if somethings goes wrong, but is the failsafe chip really bombproof or if the APM starts rebooting or something I`m screwed?
-What other things should we take great care of to ensure the APM will work realiabily?
Thanks! :-)
Replies
The only way to determine answers to Ludovico's questions is with data. Reports from users (even me) are not data but anecdotal information. (this is why the developers ask for logs after an event)
We need to take 10 or so APM2 units, ready to fly, and see what kind of extremes they can handle.
The road to this knowledge will be paved with dead APM2 units but if the experiments are set up well and the data collected well, everyone will benefit from the data; developers, engineers, 3DR especially.
Without data, all we have are stories, debates, mysteries and arguments. This is generally called 'ignorance'.
So Jordi, how about 3DR teaming up with some of the schools there in the Golden State and doing NDT or other reliability testing on the APM2? I see several excellent papers and projects on this subject.
We might even settle some differences of opinion. (OK, I am a dreamer at times)
I looked up attopilot and yes that seems to me a notch up from ardupilot as regard reliability BUT it costs more than 10 times more, which is waaay too much for my budget, so I still stick with Ardupilot because I love its incredible price to functions ratio and the fact that its open source.
I think I`ll make, using some simple cheap and small cmos logic ports, an external bypass thing in order to be able to cut out ardupilot from the control line and gain manual control of the solar drone that, by the way, I never send out of range of sight.
I`ll keep you updated with my progress and eventually make the bypass board design open source :-)
Back on subject:
"But we also noticed that ardupilot code&hardware has grown so much in complexity, and this is kinda scaring us, since it will be in charge of a $1000+ 2000hrs of labor plane... "
Let's set the context 1st. The s/w is part of an open source project and mainly hobbyists are using/developing it.
If your project is commercial, has legal implications, of high dollar value, or mission critical, look at your project from a career engineer's point of view--it's not a 'buy a couple of parts from 3DR, slap it together, download some software and go'. The APM is not really built for that [yet]. Thus, one thing that needs to be addressed in your effort before analyzing any bug list (h/w or s/w):
Develop TEST PLANS and TEST, TEST, TEST..... If the error is non-repeatable, you are shooting in the dark to solve it as well as possibly giving the dev-team a red herring to chase. For cutting edge tech, white and black-box testing are safeguards and will save you coin (and keep you safe).
My company is using the APM much like your scenario--and have taken a very conservative approach in testing and s/w mods. So far so good--though we have some random errors that only functional testing should be addressed 1st before ranting to the dev team.
The APM is much like the early Linux days--would you use Slackware Linux 2.0 to power your TV, car, or even a power plant? Folks did back then, where project code reviews as well as testing were important--hence why we had so many forks and custom kernels. Heck, I'm sitting run next to a robot that interacts with the public running a custom 2.2 kernel--and testing made it happen. The dev team can only test so much against limited use cases.
You really need to read some of the recent failsafe threads. There are a few issues and behaviors you should understand before flying.