GP is saying the sensors get into a bad state if the drone is powered on but not flying for a while. "normal operation" is powering on the drone and taking off almost immediately, then landing after 15-20 minutes. it's not inconceivable that most testing would follow this "happy path". the battery life of an idling drone might exceed the length of most test cases.
This is where a drone platform with an OS driver / control software would be great.
I bet the sensors and the control systems all have memory overflows or number range issues in the software that isn't being dealt with because it's a closed system. Add to that few if any customers are asking to use their drone as a static tripod.
I'm planning on doing some experiments with that after we're done spring surveying.
To start: I'm not sure what you mean by OS driver/control software. The two main (non-proprietary) flight controller platforms are PX4 and ArduPilot, which both basically act OS-like. Depending on which platform you're building for, they can use things like ChibiOS under the hood as well.
It's not memory overflows. These can fly for long periods of time, but sitting on the ground for a couple of minutes can be enough to require a reboot. What it is, best I can tell from the limited debugging I've done so far, is accumulated sensor bias. When the aircraft is in the air, you've got some sensors providing short-term data (accelerometers, gyros, magnetometers) and some sensors providing long-term data (GPS, optical stabilization if fitted); the short-term sensors are noisy, and an Extended Kalman Filter does sensor fusion to provide estimates that are the combined values from the fast sensors and the slow sensors. When a GPS update comes in, the EKF corrects for the biases in the sensors.
When you're sitting on the ground in a stationary position, you're only measuring noise. The accelerometers are saying you're accelerating a little bit this way and a little bit that way; the gyros are saying you've spun a bit; the GPS says you've moved around some. The GPS signal is nominally mean-zero motion, but the rest of the sensors give both bias and noise. The EKF tries to filter out the noise and correct for the bias, but because the GPS is also wobbling around, it seems that it doesn't do the bias estimation correctly. For example, this sample, the accelerometers say that you've accelerated south, but the GPS sample has moved 0.5m north. Also, GPS doesn't help correct everything unless the aircraft is in motion; if there's magnetometer drift and gyro bias in the same, the aircraft has no way of knowing that it hasn't rotated (when you're airborne, you can use the GPS signal to know which direction you're moving, even if the magnetometer says you're pointed off by a few degrees).
This is a really interesting problem; I feel like there's a range of solutions. First thought would be to take some sort of sensor checkpoint if you have full motor cutoff. Also wondering what the options are for soft-reboots that don't drop telemetry connections to your control hardware.
Yeah, I'm hoping we can get around it with just a telemetry command (we've got two-way telemetry radios) to reset the EKF state.
Full motor cutoff/checkpointing is a fun one. One thing I've found that seems to seems to exasperate the issue is picking it up when it's on the ground, adjusting a camera or something, and putting it back down on the ground. That's an almost guaranteed way to get a "high accelerometer bias" or "compass skew" error.
That's exactly it. Additionally, it seems like you can wait a while before takeoff and it's OK. Maybe some of the filtering mechanisms don't get activated until then? I'm really looking forward to digging deeper into what's going on here, as soon as we're done with our spring field activities.
