SRV_Channel: add k_soft_armed_out.

[phamelin]

For multicopters, the servo output will simply monitors the armed state.

[Hwurzburg]

as far as I can tell this servo function ,despite its comment, does nothing in plane also...if we are adding it to multicopters, perhaps we should make it functional in Plane also at the same time...

[khancyr]

I haven't check if it is possible yet, but I may be better to have this in AP_vehicle instead. That way we code it once for all vehicles types !

[IamPete1]

Plane has AP_ICEngine, I would be temped to include that in copter rather than the other way round (I have no idea how involved that would be)

[peterbarker]

Plane has AP_ICEngine, I would be temped to include that in copter rather than the other way round (I have no idea how involved that would be)

There is already a port of ICEngine to Copter; CanberraUAV used it during the OBC in 2016 on a Heli.

[peterbarker]

Armed state is not the same as engine outputs enabled.

The ability to turn your motors (be dangerous) is not the same as your armed state.

What do you actually want to come out on that pin? The armed state, or "I'm dangerous, run away!"?

[phamelin]

@peterbarker What I really meant is the armed state. I reused the EngineRunEnable parameter value because it was very close to what I needed for copters. I could had a new value (e.g. k_armed_out) if it's better.

Where should it implemented to monitor the armed state globally for all platforms? It could be implemented in AP_Arming, but it looks like the armed state for copter is managed in the motors library:

    // these functions should not be used by Copter which holds the armed state in the motors library
    Required arming_required();
    virtual bool arm(AP_Arming::Method method, bool do_arming_checks=true);
    virtual bool disarm(AP_Arming::Method method);
    bool is_armed();

[phamelin]

@peterbarker What I really meant is the armed state. I reused the EngineRunEnable parameter value because it was very close to what I needed for copters. I could had a new value (e.g. k_armed_out) if it's better.

Where should it implemented to monitor the armed state globally for all platforms? It could be implemented in AP_Arming, but it looks like the armed state for copter is managed in the motors library:

    // these functions should not be used by Copter which holds the armed state in the motors library
    Required arming_required();
    virtual bool arm(AP_Arming::Method method, bool do_arming_checks=true);
    virtual bool disarm(AP_Arming::Method method);
    bool is_armed();

Replying to myself... After looking further into the code it looks like AP_Arming is subclassed for Copters but still use the AP_Arming::arm method, contrary to what the comment seems to indicate.. So implementing it in AP_Arming should do it. Am I wrong?

[IamPete1]

That sounds like a good approach to me, do you actually want a PWM? We could also do a logical using relay. I wonder if this is for some sore of parachute system? Maybe we could augment AP_Parachute.

I have played with a Castle Creations ESC that you could setup a separate interlock PWM for, in that case we just did a direct RC pass-through.

[phamelin]

That sounds like a good approach to me, do you actually want a PWM? We could also do a logical using relay. I wonder if this is for some sore of parachute system? Maybe we could augment AP_Parachute.

I have played with a Castle Creations ESC that you could setup a separate interlock PWM for, in that case we just did a direct RC pass-through.

I would prefer a logical output but I can deal with a PWM output. I am using a drone to deploy a tool once landed and we have to make sure that the tool is retracted before takeoff. I have a separate board to control the tool mechanism which takes that signal as an input.

[IamPete1]

As this is not absolutely safety critical feature, this is a perfect use for scripting, there bindings are already there for checking arming and setting relay state. It would only be a dozen line of lua.

My vote would be to ditch the separate board doing the tool mechanism and do that in lua too ;)

[phamelin]

@IamPete1 Since the desired feature is 'almost' already there and might be useful for many user, I would still vote for an additional servo function. I would also love to use the existing Pixhawk instead of a separate control board However, the control board does many other things and the Pixhawk wouldn't appropriate for this in terms of CPU usage and available I/O.

[IamPete1]

I did the lua code, https://gist.github.com/IamPete1/e0fcb7ce3814b6da067bc2018e9472f7

It does both servo and relay output.

You might be suprised by what you can do in scripting, CPU usage is a none issue on a H7 board. IO is lacking but it is not a insurmountable issue.

[peterbarker]

On Tue, 30 Jun 2020, Philippe wrote: @peterbarker What I really meant is the armed state. I reused the EngineRunEnable parameter value because it was very close to what I needed for copters. I could had a new value (e.g. k_armed_out) if it's better.

I think that would be preferable.

Where should it implemented to monitor the armed state globally for all platforms? It could be implemented in AP_Arming, but it looks like the armed state for copter is managed in the motors library:

Uh yeah. That's your next problem - what "armed" means. We have about 5 different places we store our armed state.... I suggest initially using hal.util->get_soft_armed() and see if that does what you want.

[Hwurzburg]

is it a good idea to have a switch with different behavior between vehicles? The current switch was supposed to be an ICE kill switch for planes and helis....turns out its only for helis, right?, but even then , having it as an arm state in Copter is different than what it is in Heli....this seems strange to me

[phamelin]

I updated the pull request according to the comments. However, there's one thing I'm not fully satisfied about is how to initialize the default output value for the new servo function k_soft_armed_out. For now, the default value is assigned in SRV_Channel::aux_servo_function_setup(void) but I think it may not be the proper place. Any idea?

[rmackay9]

@phamelin, how about relying on the lua scripting method?

[phamelin]

@rmackay9 The system targeted by this functionality should be manufactured in several units and delivered to commercial customers (read: non-developers). In addition, this is used for a security function in the system. With this in mind, I am reluctant to use a Lua script for this purpose. We really want the system configuration to be as simple as possible, that is to say 1) download the official ArduCopter firmware and 2) download the manufacturer parameters. Also, the fact that the script is on the SD card adds an additional point of failure, e.g. a SD card replacement may cause the script not to be ran and a failure of the system.

[Hwurzburg]

if they would have to download manufacturer's parameters anyway, wouldn't it be better to provide them one customized firmware download from your site with the apj containing the parameters also?....that way its assured to be exactly what you expect them to use and you can manage such that future firmware releases, that MAY not have your verified and tested behaviours, are guarded against....I believe that is what some custom systems manufacturers do...

[phamelin]

@Hwurzburg I didn't know that we can package custom parameters in the apj file. Thanks for the info! Just putting it there for future reference: https://ardupilot.org/dev/docs/apjtools-intro.html . We will probably end up using a custom firmware, but it would still be nice to have this functionality built in, to minimize patch maintenance.

[IamPete1]

@phamelin you can also package lua scripts into apj files using the same tool, then it is no longer reliant on the SD card. I'm not sure if this is documented anywhere however.

[Hwurzburg]

@IamPete1 a couple of short bullets for the procedure and I will flesh out and add to the wiki in the dev section

[peterbarker]

@phamelin did you want to pursue this PR?

[phamelin]

@peterbarker I would like to, but from what I understand, I am instead being suggested to use a script for this. Personally, I prefer not to use a script for this and instead use the SRV_Channel as proposed in this patch. If you're still willing to merge this patch I can rebase it.

[rmackay9]

We could discuss it on a dev call but in general this is a request to use a PWM output as a way to pass a single piece of state to an external system. armed/disarmed is certainly an important bit of state but is it important enough? AP vehicles have lots of other state as well that could arguably also be passed out using PWM but we couldn't possibly support them all.

I wonder if this requirement comes from a desire to add support for multiple autopilots.. if "yes" then it might be better to investigate the full solution instead of just this one request.

[phamelin]

@rmackay9 I perfectly understand your point about the other states that could be available and it might not be a good idea to make them available on RC outputs. Indeed, for most states the MAVLink communication should be used. However, I think the armed state is important enough to make it in the RC outputs. In our case, it triggers a safety input on a third-party board which control an actuator, which isn't compatible with MAVLink. The position of the actuator is controlled with another RC output taken directly from the RC receiver. In other words, it ensures that the actuator moves to its safe position before taking off. Taking off with the actuator in an unsafe position would lead to a crash.

[magicrub]

I'm ok with a hard coded change like this (aka not in scripting) as long as it's genetic for all vehicles.

[tridge]

Also, the fact that the script is on the SD card adds an additional point of failure, e.g. a SD card replacement may cause the script not to be ran and a failure of the system.

lua scripts can be built into ROMFS, so they are embedded in flash, just like C++ code

[tridge]

i see a few problems with this:

• I suspect most companions would want a GPIO, not a PWM
• soft armed doesn't take account of safety state
• lua scripts can be embedded in ROMFS, so can be safe and a lot more flexible

[phamelin]

@tridge I was suggested by @peterbarker to use the hal.util->get_soft_armed() at first. As I understand, obtaining the "armed" state is not trivial. Do you have any suggestion to replace the soft armed?