I’m currently working with a Pi 4 and the Blue Robotics Navigator board, pulling sensor data back to a control program using MAVLink. So far all has been going well, I’ve been able to get accelerometer and depth sensor readings from MAVLink, and I was recently able to pull temperature sensor readings in from the SCALED_PRESSURE3 message.
I’m a bit stuck though getting readings from the 2 ADC connectors on the Navigator board because from what I can tell, there doesn’t seem to be support for the ADC, either in the MAVLink messages, or in the ArduSub firmware.
Is this correct? Is there any plan to introduce support for the ADC, and if so what is the timeline? Currently it’s hard to see how these ADC ports are usable without software support.
If I was to try and implement support myself, am I correct in understanding that the best way would be to create a patched version of ArduSub, and then add in a new MAVLink message? I’m assuming that creating a standalone program that tried to talk I2C to the ADC chip using the PI GPIO pins would be a bit of a non starter because it would interfere with ArduSub trying to talk I2C to the other chips on the same pins at the same time?
Any suggestions or advice on how to proceed here would be much appreciated.
Apologies for the delay on this - it took some time to get confirmation on the current state of things.
Somewhat, but not entirely. There is an AP_ADC MAVLink message in the ArduPilotMega message set, and it’s even technically supported by ArduPilot firmwares. The caveat is that it’s currently compiled out for most flight controller types (including the Navigator) unless they’re compiled in a debug mode, which in practice means it doesn’t actually get sent.
I spoke with the software team and we agreed that it seems like a valuable feature to have, especially since it’s been asked about before. That said, it’s not an immediate priority for us (since it’s new functionality that’s not strictly required for effective operation and standard use of a vehicle), so I can’t provide a timeline for it.
For what it’s worth there’s an open issue about it that you’re welcome to comment on and/or provide contributions towards if you’d like to help/encourage the feature to get implemented.
As a side note, it may be possible to get access to the ADC readings in the interim via a workaround, whereby you configure an additional battery monitor and set it up with an offset of 0v and a multiplier of 1.
There’s some possibility this could work, but it’s likely preferable to do something else instead, especially since there are other known approaches (as discussed above) that are less likely to cause conflicts.
