[Command] Control vehicle engine. This is interpreted by the vehicles engine controller to change the target engine state. It is intended for vehicles with internal combustion engines
Param (:Label)
Description
Values
Units
1: Start Engine
0: Stop engine, 1:Start Engine
min: 0 max: 1 increment: 1
I would like a third engine state - “Ignition On” where the ignition would be on, but not trigger the starter - the current implementation seems to favour situation where the ignition is turned on and the vehicle started, or the ignition is turned off (stop).
I acknowledge this is not the place to discuss the actual modification, but wanted to provide the context for understanding the process.
To do that change you should submit a github pull request to the mavlink/mavlink repository, followed by a pull request on Ardupilot implementing that functionality.
Is it literally just changing the param index=“1” line in common.xml, or is there more to it?
<entry value="223" name="MAV_CMD_DO_ENGINE_CONTROL" hasLocation="false" isDestination="false">
<description>Control vehicle engine. This is interpreted by the vehicles engine controller to change the target engine state. It is intended for vehicles with internal combustion engines</description>
<param index="1" label="Start Engine" minValue="0" maxValue="1" increment="1">0: Stop engine, 1:Start Engine</param>
How is autopilot compliance / support for the MAVLINK standard manged? Is it up to implementers of autopilots what features they support, so I can just add a new option?
Yes, the implementors can change stuff, but if it does not get merged in the official standard, then you can not say that you are mavlink complient, and you might get merge conflicts in the future!
So, please do as I described, it will be better for everybody involved.
Sorry, I was referring to the people who write autopilots as the “implementers”. If I do get this pushed into MAVLink, and there’s now a new option, does that mean ALL autopilot implementers need to accommodate it? Is your autopilot no longer “mavlink compliant” if it doesn’t (in this case) handle “start engine = 2” as “turn on ignition”?
I’ve only looked at Ardupilot, but it would need a change because it treats <=0 as “stop” and >0 as “start”, so a GCS that sent start engine =2 expecting ignition only would get an engine start instead!
How would you manage a risk like that for other autopilots? Is that undesirable coding in Ardupilot where it should actually look for a specific value, rather than just < or > 0?
Well, I am the person responsible for bringing stuff from the upstream Mavlink repo into the ardupilot repository (others do this as well). Those changes would only be integrated into ArduPilot if there is a PR adding those features to the code. We are aware that we do not 100% follow the Mavlink standard. We only follow the parts we like about it
