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?
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.
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.
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.
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: https://github.com/ArduPilot/ardupilot/issues/11175
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: http://www.hybridproject.com/
@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.
Sure,
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.