Needing help integrating engine management telemetry into Ardupilot, Mavlink, and the GCS

We have developed a hybrid electric quadplane that has a fairly elaborate engine and battery management system.

The system is separate from the autopilot computer because we did not want our customers to be forced to use a particular autopilot so the only communication absolutely required is throttle pwm from the autopilot computer to our ECU (engine management computer).

Basically you can treat our gas/electric system like an electric motor and everything else takes care of it’s self.

That being said we are primarily using Ardupilot and it is nice to have telemetry back from the ECU so you know engine RPM, Voltage, Amperage, Battery Level, Temp, and Fuel Level.

With the help of a friend I wrote a basic Ardupilot driver that receives serial from our ECU via the Telem 4 port, decodes it using an sscanf function, then does a bit of math, sets variables, hijacks some already existing mavlink messages and sends it back to the GSC.

This has been working for us for a while but because of the way I did things the ECU telemetry is not logged on the plane, nor is the Voltage, Amperage, or Battery and at this point we do not have Temp or Fuel Level.

It wasn’t to hard to get the information into Ardupilot via serial and sscanf but I didn’t understand enough about global variables to properly move the information around inside Ardupilot to where it would be logged and I was only able to effectively overwrite already existing Mavlink messages not create new ones…

It seams there are enough people wanting to run engine management systems in parallel to the autopilot that adding a sort of “general IC info” to Ardupilot that would be received via serial from standalone systems has a place.

Can anyone help?

-Shane

1 Like

@peterbarker would be my suggestion.
Sounds super useful!

I’ve raised a feature request here: https://github.com/ArduPilot/ardupilot/issues/11175
Obviously contracting someone in is probably the quickest way to get this worked on, but documenting explicit requirements in GitHub will be a good first step, and make it easier if an interested Dev has some spare time to start on it.