Servers by jDrones

IC Engine Status [CLOSED]

(Shane Roberts) #1

Topic: IC Engine Status

Proposal type: Hardware [ ] , Software [*] , Other [ ] : _________________

Description: It’s unsafe to fly ICE powered UAV’s without engine monitoring (RPM, fuel level, cylinder temp, ect).

Would like the add these messages to Mavlink and logging but leave sensor source open ended.

This way the monitoring could be done by the autopilot or come from an external source via serial and a relatively simple pass through driver.

Planned amount $$ (300):

Estimated time for completion: 1 week

1 Like
(Francisco Ferreira) #2

Hi Shane,

So your idea is to add new MAVLink messages to the protocol, plus adding support for sending those from ArduPilot, plus logging that information? I just want it to be clear on what this includes.

Also, you have posted something similar in the Jobs category so it’s not completely clear to me whether you would be doing this or if you are looking for someone; it’s also not clear why you were looking to hire someone and are now asking for ArduPilot to pay for this. Can you clarify?

Best regards,

ArduPilot Funding Committee

(Shane Roberts) #3

In the case of the proposal I was suggestion there be general IC Mavlink messages added with support for logging so anyone could easily get IC related telemetry recorded and back to the ground.

I do not have the knowledge to do this on my own but it does seem like something the community would benefit from as a whole.

As far as the job posting…

I was looking for someone that could help do it.


(Chris Olson) #4

I fly only combustion engines in helicopters, both piston and turbine. I monitor CHT (EGT on turbines), engine block temp (gearcase temp on turbines), ERPM (N2 on turbines), RRPM. Fuel level is not worth monitoring - fuel gauges in aircraft are notoriously unreliable and fuel burns by the clock in aircraft engines.

I will submit that it is much better to do engine monitoring and logging on the RC than it is with MavLink (using an RC system like OpenTx). The ground station is not always present on all flights - the RC always is. And the RC provides real-time data, where there is built-in latency with MavLink. The required sensors are readily available for RC telemetry. They are not readily available to get sensor inputs into ArduPilot.

(Shane Roberts) #5


I can see how this would not be required for your use case but we are operating BVLOS fixed wing aircraft with around a 500 kilometer range so there are multiple comms systems involved in maintaining a connection to the autopilot.

Having all the engine telemetry coming through Mavlink is important for us to keep up with what is going on and generally the latency is not an issue.

As far as “Fuel level is not worth monitoring” We fly for around 6 hours, carry quite a bit of fuel, and have a very reliable system for monitoring its level.

This might not be the case for everyone right now but as this technology develops I suspect reading fuel level will become more common because the rate of fuel burn can very significantly depending on weather conditions.

Also in delivery type situations you might not always be able to count on people properly zeroing the fuel meter or you may not be starting with a full tank so having an absolute reference is really quite important.


(Chris Olson) #6

We have an rpm library in ArduPilot that was only used for logging and rpm display in MP via MavLink.

For somebody who wanted to tackle it, a similar thing could be done with other types of sensors I suppose.

(James Pattison) #7

G’day Shane,
the funding team has discussed this, and whilst we agree it is important, at this stage we have decided to add it as a Feature Request in GitHub, rather than put Partners Program funds towards it - fundamentally because to do so would quickly set an unsustainable precident.
I have raised the Request here:
Please feel free to comment on it, and add specifics such as the specific data formats and protocols. The more information we have, the easier it is to scope/plan/design.
We’re actively discussing amongst the Dev Team, as this is an area that is getting an increasing amount of interest.
Nice aircraft by the way. For those who aren’t familiar with Shane’s efforts:

Is it ok if I close this proposal?

(Shane Roberts) #8

Thank you James!

I appreciate the time and thought.

I’ll move this to discussion to the Git hub.

Should be good to close the proposal.


(Matthew ) #9

Could you please elaborate on this unsustainable precedent, is it the fact that a non-partner is asking for support from ardupilot partner program fund? Is there any mechanism that allows non-partners to donate money towards a specific goal/request within the community other than just donating? I think this has been discussed else where about some sort of code bounty or such. Not trying to get off topic, just slightly confused as to this precedent you speak of especially when

(Max Blanc) #10

@Shane_R Hello Shane, you have mentioned that you operate around a 500 km range. If possible can you suggest me some transceiver receiver and antenna setup including which brands to use. Any help is much appreciated.

(Shane Roberts) #11

We use RFD 900’s for the ground station telemetry link.

After that we switch to LTE comms using UAV Cast.

We also have an iridium messaging system in the event no LTE is available but it is quite delayed.


(James Pattison) #12

it’s not just not being a partner: we haven’t spent Project/Partner funds on paying a developer to implement any features yet. We’re not fundamentally opposed to doing that, but with an annual total budget of only around $60k to support all the IT infrastructure, CI, developer conference, part time Bugmaster, and a few other fixed costs, we’re not in a position to start just yet. The discretionary spending is tight.