PX4 mixing for multicopters

[Andrew Tridgell]

Hi Holger,

We had a bit of a discussion on the dev call yesterday about strategies
for PX4 mixing in the copter code, and in particular the need for mixing
to support UAVCAN ESCs.

I know you've been working on this for a while, so I've just had a look
through your px4mix branch:

https://github.com/hsteinhaus/ardupilot/commits/px4mix

and I thought it would be worth discussing the approach taken, and
comparing it to the approach I've just done for plane support for
creating mixers.

For the benefit of other people on the list, I thought I should first
describe the approach taken in your px4mix branch.

In your branch you create a new copter frame type 'px4mix', and a new
AP_Motors class to go along with it:

https://github.com/hsteinhaus/ardupilot/blob/f1d6a83630cd409253646d6710aa5e83b431b6e3/libraries/AP_Motors/AP_MotorsPX4.cpp

The code then loads a mixer file based on a frame type, using mixer
files from the PX4/ROMFS/mixers directory (such as FMU_quad_x.mix). The
AP_MotorsPX4 class also does the ORB publication of the output values
which provides the input to the mixer.

I can see how this approach works, but it had the disadvantage that it
bypasses the current stability/limits code used by ArduPilot for
existing users. That means we won't get exactly the same flight
behaviour when using UAVCAN ESCs as we would get when using PWM based
ESCs. I think it would be nice to be able to keep as much of the
stability code inside ArduPilot as possible (Randy, Jon and
Leonard may be able to provide some useful input as well).

Have you considered instead taking this approach:

- generate a mixer file in the AP_MotorsMatrix class, using the simple
scaler based mixing elements. This file could be in
/fs/microsd/APM/MIXER.MIX, same as plane now uses. See this code for
the way plane generates a mixer:

https://github.com/diydrones/ardupilot/blob/master/ArduPlane/px4_mixer.pde#L26

I think the motors matrix mixer creation would be a lot simpler than
that

- always publish actuator values in AP_HAL_Linux/RCOutput.cpp even if
not using UAVCAN. These will be ignored on copters that don't use
UAVCAN, as the px4io code will use the raw PWM values. The UAVCAN
code will use the actuator values.

- the actuator values would be based on the RC3_MIN/RC3_MAX range
(adjusted for RCMAP), plus the PWM values already passed into
hal.rcout->write()

I think the advantages are:

- this approach should work for planes and rovers using UAVCAN ESCs as
well, as it isn't copter specific

- it keeps using the current stability code in AP_Motors, so it should
fly extremely similarly to the current ArduCopter code

What do you think?

Cheers, Tridge

[Holger Steinhaus]

Hi Andrew,

great that there seems to be some new impulse to bring forward this topic!

 

I know you've been working on this for a while, so I've just had a look
through your px4mix branch:

  https://github.com/hsteinhaus/ardupilot/commits/px4mix

and I thought it would be worth discussing the approach taken, and
comparing it to the approach I've just done for plane support for
creating mixers.

 

I can see how this approach works, but it had the disadvantage that it

bypasses the current stability/limits code used by ArduPilot for
existing users. That means we won't get exactly the same flight
behaviour when using UAVCAN ESCs as we would get when using PWM based
ESCs.  

This is generally true and one of the motivations to keep that new mixing code far away from the code productively used. In fact this is one of the motivations why I chose to implement an independent frame type. 

For applying limiting and other stability code, I actually see two approaches, how to handle that: The most obvious would be to contribute the code to the PX4 multirotor mixer (which is not trivial due to licensing and code structure). But I think there is a less-invasive alternative: The current PX4 mixer code is able to notify saturated motor outputs (the actual code can and will be improved!). The AP_MotorsPX4 class uses this information to fill the AP_Motors_limit struct fields currently, like AP_MotorsMatrix does. In a next step, the control signal (T/R/P/Y) itself could be modified when reaching a certain limit, in the same way AP_MotorsMatrix does currently. I think using this approach we could avoid ever hitting the limiting of the PX4 mixer for significant periods of time and so keep the actual limiting within APM completely. BTW, this approach would provide a great chance to separate the stabilitiy/limit code from motor control and motor control from mixing. IMHO this would be a major big step towards a better software architecture of this currently highly complex piece of code grown during a long time of evolution. 

Here are some pointers into to the current limit notification code:

PX4 side:  https://github.com/PX4/Firmware/blob/master/src/modules/systemlib/mixer/mixer_multirotor.cpp#L320

APM side: https://github.com/hsteinhaus/ardupilot/blob/px4mix/libraries/AP_Motors/AP_MotorsPX4.cpp#L228

 

Have you considered instead taking this approach:

 - generate a mixer file in the AP_MotorsMatrix class, using the simple
   scaler based mixing elements. This file could be in
   /fs/microsd/APM/MIXER.MIX, same as plane now uses. See this code for
   the way plane generates a mixer:

Generating the mixer file dynamically during startup is a very interesting approach - I think this is even a good approach when sticking to the multirotor mixer.  

 

 - always publish actuator values in AP_HAL_Linux/RCOutput.cpp even if
   not using UAVCAN. These will be ignored on copters that don't use
   UAVCAN, as the px4io code will use the raw PWM values. The UAVCAN
   code will use the actuator values.

Currently, the UAVCAN stack is not listening to the actuator output topic. It has been designed to work on control outputs. That means it expects roll/pitch/yaw/throttle input, not individual motors. Of course it would be possible to change that in an APM-specific "fork" of this code, but it wouldn't be trivial and would mean that we break the initial architectural design of that code. 

 

 - it keeps using the current stability code in AP_Motors, so it should
   fly extremely similarly to the current ArduCopter code

This is my ultimate goal for the px4mix branch as well. To be able to check and to compare, the px4mix code is NOT specific to UAVCAN at all - it also supports writing to the PX4IO PWM output device. The current state of the work is that there is still some bug around - I am currently unable to handle high-frequency signals correctly. I do not think this is a general problem of the chosen approach, as roundtrip time measurements show that they decades better than required. Possibly it is related to the UAVCAN stack becoming CPU-intensive  as soon as output_control topics are published.

BTW: I think a very first step towards UAVCAN would be to enable the UAVCAN stack in APM by including the module into the build and executing the driver during startup as proposed in https://github.com/diydrones/ardupilot/pull/1323. This step is completely agnostic of the way of mixing (even if the discussion of the PR moves to the mixing topic). I did not experience any side effects as long as no control topics are published from APM.

Regards,

  Holger

[Randy Mackay]

Tridge,
     Thanks very much for reviewing this.  I think we're super keen to use the uavcan ESCs so that we can improve feedback from the ESCs/motors and identify and reduce mechanical failures.

     I'm actually much more interested in getting feedback from the motors via CAN than actually providing the outputs to the ESCs via CAN in case that makes any difference.  I'm happy for the outputs to go via CAN if necessary, I'm just saying that it's not a requirement.

The problem with bypassing the arducopter stability patch is that it's responsible for setting some flags to indicate whether the the motors have hit any of their limits.  This is important for landing and also reducing I terms build-up in altitude hold and navigation controllers.

-Randy

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Holger Steinhaus]

Hi Randy,

     I'm actually much more interested in getting feedback from the motors via CAN than actually providing the outputs to the ESCs via CAN in case that makes any difference.  

I am not sure if this approach will work. if UAVCAN in enabled, the stack may send "disarmed, duty cycle 0" commands to the  ESCs. Maybe it doesn't if no mixer has been loaded. Will check that out and contact your with the result.

 

The problem with bypassing the arducopter stability patch is that it's responsible for setting some flags to indicate whether the the motors have hit any of their limits.  This is important for landing and also reducing I terms build-up in altitude hold and navigation controllers.

This part is already contained in my pull request from August ( https://github.com/diydrones/ardupilot/pull/1322 ). The part with the limit notification is linked in 2nd post of this topic (my post).

 Holger

[Holger Steinhaus]

     I'm actually much more interested in getting feedback from the motors via CAN than actually providing the outputs to the ESCs via CAN in case that makes any difference.  

I am not sure if this approach will work. if UAVCAN in enabled, the stack may send "disarmed, duty cycle 0" commands to the  ESCs. Maybe it doesn't if no mixer has been loaded. Will check that out and contact your with the result.

A short follow-up regarding the ESC feedback even if slightly off-topic here: I have restructured my existing feedback logging code a bit and removed any dependecies to and from UAVCAN and PX4 mixing. You can find the PR here: https://github.com/diydrones/ardupilot/pull/1594

This patch should not interfere with normal PWM operation (but obviously without logging anything due to the lack of feedback information).

Holger