I’m developing a drone-in-a-box for personal use on my uncle’s farm. It will monitor the farm daily and find problems, but I mostly enjoy the development process.
My drone contains an RPI as a companion computer. I use the RPI primarily for mission planning and image processing (with Realsense).
I am hoping to have the drone fly autonomously, so I want my companion computer to be able to perform a pre-flight check to ensure the drone won’t have a problem during flight. In particular, I’m concerned about motor and sensor failures but I’m not sure it will be possible to detect those problems on the ground. Might perform a motor-test or a short takeoff and landing and analyze the logs before starting the scan.
I’m currently trying to design the tests and wonder if you have any suggestions? Which of the available telemetry and log messages will be interesting to monitor?
Arducopter has pre-arm checks that will check all of the basic features like GPS, Compass, IMUs, and other stuff but can’t check the motors and ESCs if there is a mechanical failure. Make sure to turn those on, also you can check all of the messages it sends to see if there is any problem during arming or before taking off
I’m also somewhat interested in one aspect of what you mentioned, which is an onboard automatic log analysis. If you haven’t seen it already, pymavlink has a DFReader class that can parse the logs produced by ArduPilot: https://github.com/ArduPilot/pymavlink
My particular application isn’t running on the companion computer (at least… not right now ), but I’ve found that parser to be very capable and easy to use.
(In order to get the logs off the card, you may have to mess with the logging backend parameters. I believe there’s a way to point dataflash logs over MAVLink [i.e. into your Pi], but don’t know the details of it.)
I appreciate your responses. @Yaros1 The built in pre-arm test sounds like a good starting point i’ll also make sure there are no error messages. @mishaturnbull actually i’m already familiar with pymavlink DFReader and implemented the logs download over mavlink. Glad to see your interest in onboard log inspection. Have you thought about what kind of messages to check?
The approach I’m taking is a very modular plugin-based direction, trying to make it easy for people to write their own plugins or just use the out-of-box default plugins. So far, all I’ve really done with it is a parameter extractor and message delete tool, but am planning on plugins for data comparions (i.e. find the max deviation between ATT.Roll and ATT.DesRoll). Mission Planner has a builtin log analyzer feature that I’d love to have a clone of eventually; I believe it checks things like power, motor balances, vibration levels, etc. My project is here but you should be aware it is still in the very early stages of development.
More on-topic for you though (sorry about hijacking your thread ), you may also need to look into disabling the RC check/controls… I’ve found if you power on the autopilot before your RC transmitter it will generate errors about RC failsafe (and rightly so). It sounds like you’re also planning on using mission plans of some sort, and if they’re the sort you upload to ArduCopter it can look for certain criteria in those plans before arm as well (ARMING_MIS_ITEMS or something?).
Also, if you go down the log processing route checking logs before takeoff, don’t forget to turn on LOG_DISARM. I lost a good amount of test data that way once.
), but I’ve found that parser to be very capable and easy to use.
), you may also need to look into disabling the RC check/controls… I’ve found if you power on the autopilot before your RC transmitter it will generate errors about RC failsafe (and rightly so). It sounds like you’re also planning on using mission plans of some sort, and if they’re the sort you upload to ArduCopter it can look for certain criteria in those plans before arm as well (ARMING_MIS_ITEMS or something?).