Bidirectional Control For Motors

[henrykotze]

This PR implements actuator testing for bidirectional motors with the focus on gaining feedback on its implementation. This PR has only been tested with UAVCAN motors with the following PX4 PR: PX4/PX4-Autopilot#21656.

The following features are included:

• Once a motor is indicated as bidirectional, the slider to that motor would adjust to the middle, to allow testing in both directions.
• Using the "All Motors" Slider will only send commands to motors which are configured as standard motors (not bidirectional)

There might be better ways to implement this feature:

• At the JSON level -> This will result in changes of how PX4 generates its mixer parameters, and I would expect much more changes would be needed in QGC. Each motor would needs its own "ActuatorType" to reference its min,max, and default value. I think the way how I implemented is the least invasive, since it keeps the generator parameters the same, and just accounts for this specific motor behavior. (Do we expect more specific behaviour from motors?)
• We can use the 'reversible' parameter which exist in the parameters, but again I think this would result in more changes required in QGC and perhaps even a specific setup process to test the motors.

@bkueng

bidirectional_control.mp4

[bkueng]

Thanks, but this requires a bit more work. The metadata should fully define what you need.

Then for the slider it would be nice if there was a dead-zone in the center, that snaps and sends the default value (stops motors) if set. Similar as for the lower part for standard motors.

[bkueng]

The idea is that if reversible is set (https://github.com/mavlink/mavlink/blob/master/component_metadata/actuators.schema.json#L37), then the range [-max, -min] should be used for the reversible part. So you don't have to hardcode values.

[bkueng]

We cannot use hardcoded parameter values here, as it makes it PX4-specific, and it will break easily.

Rather we need to set the reversible function on the PX4 side for the parameter, and then make use of it here. -> https://github.com/mavlink/mavlink/blob/master/component_metadata/actuators.schema.json#L63

[DonLakeFlyer]

Any updates on this?

[henrykotze]

Not too much currently, will see if I can get something useful over the weekend.

[henrykotze]

So far I have implemented the snapping for the bidirectional motor, however I a bit lost to how the metadata gets through from PX4 to QGC. So any reference to a doc or even a existing example would be great help!

[bkueng]

It's through the COMPONENT METADATA protocol. On PX4 you find the file under build/<target>/etc/extras/actuators.json.xz. It is assembled from this file: https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/control_allocator/module.yaml. Let me know if you want me to talk you through it.

[hamishwillee]

@bkueng Do we need to add a section on actuator metadata in docs - i.e. at least here? https://docs.px4.io/main/en/advanced/px4_metadata.html#px4-metadata-translation-publishing-params-events

[bkueng]

@bkueng Do we need to add a section on actuator metadata in docs - i.e. at least here?

Yes I think that would be good. I can create a draft.

[henrykotze]

Hi Beat
Thanks, I understand the use of the metadata, and I really love how abstracted it has become! The implementation is awesome!

So the current issue I am having is that the parameter CA_R_REV determines whether the slider for testing the actuator is set to 0 to 1 or -1 to 1. To not use the CA_R_REV parameter directly, the metadata scheme needs to provide a keyword or info to allow us to fetch the parameter. (this is what I am assuming)

If we keep the metadata as is, the CA_R_REV parameter will live within the ActuatorType object, but this class doesn't provide info about the semantic of the parameter (function), so I will either need to search for the label of the parameter (in this case: "Bidirectional") which ends up being the same as just searching for the parameter. (Which we dont want to do)

What I think I should do is:
Add the semantic term: function: "reversible" under the CA_R_REV "per-item-parameter" in the mixer group and then also extend the Parameter struct which is used within the ActuatorType class to contain enums for the semantics. This ends up being very similiar to the MixerParameter struct

I actually have implemented the above, but just in a different branch. I will see if I can merge those changes into this branch and push.

The other option is allow the parameter to live within the MixerParameter struct, thus just adding the "Reversible" term to the Function enum class (thus changing where CA_R_REV is defined within the yaml file), allowing us to extend the Function class, but then we need to alot of more searching

I hope this makes more sense, and even more when I push the changes.

[henrykotze]

output2.mp4

Here is a quick video of the snapping for the bidirectional motors.
Running a different version of PX4 as the one linked above, since you will see the actuator outputs (min/max) are completely different from the current PX4, however this is the changes to the control_allocator yaml:

[bkueng]

Cool, nice work! I'll need to go through the details, but I think you're on the right track.

Add the semantic term: function: "reversible" under the CA_R_REV "per-item-parameter" in the mixer group and then also extend the Parameter struct which is used within the ActuatorType class to contain enums for the semantics. This ends up being very similiar to the MixerParameter struct

That makes sense.