Glenn,
I think the issue is that the vehicle has a sonar enabled but it’s not working properly. You can see the sonar alt in the CTUN message.
-Randy
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Glenn,
With a sonar attached, alt-hold tries to attain a “desired” sonar altitude. With a broken sonar, as you move the throttle stick up and down, the “desired” sonar altitude will also move up and down but inevitably it will be above or below the [bad] altitude being reported by the sonar. This will make the copter keep climbing or descending chasing a sonar altitude that it can never reach.
We don’t have any sanity checking on the sonar altitudes so we don’t have any indication of whether it’s sending us valid data or not. It’s not completely trivial to add because we’re just reading a voltage and in this case the voltage is a reasonable voltage. The only way to know it’s bad is by noticing that it’s not changing.
The best way to improve the sonar reliability is probably to:
1. Add the sanity checking that the values aren’t spikey but are moving
2. Move towards an I2c sonar (or the pulsed light range finder) which has a better interface which we can use to determine if the sonar is working.
As you say range finders will be moving towards i2C so probably not worth spending time on extra sanity checks for the ADC versions.
I for one am getting very excited about the pulsed light range finder. I've backed and am looking forward to its arrival. Hopefully I can help out with testing / dev work.
In the mean time I shall try get my sonar working. Is the sonar code defined by default? What ADC pin is defined as default? I guess I need to search through the code to get familiar.
Thanks,
Glenn