Using the PX4 mixer infrastructure with ArduPilot

[Holger Steinhaus]

Traditionally ArduCopter relies on a hard-coded mixer architecture, that requires building one binary per possible vehicle layout, at least for copters. For planes/rovers, there seem to be some specialized and hardcoded mixer functions included in the attitude code, e.g. for V-tails or elevons. 

On PX4 platforms, there is a generic mechanism for mixing, scaling and limiting of arbitrary channels, that is configurable during run time by loading a simple text file (not used at the moment with ArduPilot). The mechanisms provided are quite powerful, generally it seems possible to implement the complete RC setup of a complex vehicle here. Just take a fresh transmitter out of the box with all channels set to -+100% and control a vehicle with lots of mixers, gimbals, retracts, flaps, etc. If we would have a simple way to read an ArduPilot parameter from a NuttX shell script, it would be even possible to switch e.g. from a quad to an octo-x8 layout depending on a parameter's value, at boot time without any re-flashing. 

What does the community think about this approach? I did some experiments, it would be quite easy to add a new px4 build target that activates this mixer. At least with ArduCopter it would be a matter of a few dozen lines of code to replace the AP_Motors mixing with the PX4 mixer (it's basically working here already). For ArduPlane/Rover, there is still some research to be done as it AFAIK lacks a central instance that handles all mixing as AP_Motor does for ArduCopter.

A few words about my motivation on this topic:

My current plan is to integrate an ESC that is not driven by PWM signals, but by UAVCAN. Obviously, our AP_Motors library is not prepared to support anything but plain PWM outputs. Additionally, the PX4 community has decided to integrate the UAVCAN ESC drivers tightly with their mixer infrastructure - it listens for attitude and power commands instead of listening individual motor setpoints. Obviously this problem could also be circumvented by loading a dummy mixer or by modifying the ESC driver, but the approach suggested above seems to have quite some additional benefit without adding to much effort (if any at all).

Any suggestions welcome - including "forget it, I already tried that, didn't work" ;-)

Regards,

  Holger

[Robert Lefebvre]

Hi Holger, I've seen this request from many people, so you're not the only one.  I can think of a few reasons why it wouldn't work, or wouldn't be easy.  

1) Multicopters rely on the stability patch for augmented stability.  This is a very complicated system, and I can't imagine how it might be implemented in a system such as you propose.  Our motor outputs are not simply the summation of pitch, roll, yaw and total throttle factors.  There's an over-arching controller that looks at what each motor is doing, and will intelligently clip yaw and throttle output if any of the motors are saturated with roll or pitch demands.

2) Similarly, the heli code has some complexity like this, and will be getting even more complex. For example, Collective-Yaw compensation.  This is a V-shaped curve, with the minimus coinciding with zero pitch.  So the yaw output is affected by collective in a non-linear way.  Simple mixer won't work.  Then you get piro-comp, and in the future we'll have cross-coupling compensation active, which is non-trivial.

I think these simple mixers only work with very simple control laws.  

--
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-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Holger Steinhaus]

Hi Robert,

thanks for your feedback!

 

1) Multicopters rely on the stability patch for augmented stability.  This is a very complicated system, and I can't imagine how it might be implemented in a system such as you propose.  Our motor outputs are not simply the summation of pitch, roll, yaw and total throttle factors.  There's an over-arching controller that looks at what each motor is doing, and will intelligently clip yaw and throttle output if any of the motors are saturated with roll or pitch demands.

Besides the simple mixers there are specific multi-rotor mixers, they can be used instead of the simple ones and together with them as well (e.g. together with simple mixers for the gimbal). From what I have seen so far, they provide exactly this functionality (intelligent clipping, prioritizing attitude over power and yaw, etc.). Unfortunately, this part is not documented very well, but the PX4 people are flying multi-rotors as well and I guess it will work (I did not try to fly yet - may be it ends up with a big surprise).

 

 

2) Similarly, the heli code has some complexity like this, and will be getting even more complex. For example, Collective-Yaw compensation.  This is a V-shaped curve, with the minimus coinciding with zero pitch.  So the yaw output is affected by collective in a non-linear way.  Simple mixer won't work.  Then you get piro-comp, and in the future we'll have cross-coupling compensation active, which is non-trivial.

Ok, that kind of sophisticated logic would probably really hard to provide. But there is no real reason to try that - the use of the PX4 mixer would be strictly optional, it is just another supported FRAME_CONFIG in fact.

Holger

 

[Meier Lorenz]

Hi Robert,

I would suggest you look at the implementation first - this is a „complex“ mixer for multicopters:
https://github.com/PX4/Firmware/blob/master/src/modules/systemlib/mixer/mixer_multirotor.cpp

Apart from simple fixed wing mixers vehicle-specific modes have been implemented as well. It wouldn’t be hard at all to add support for a heli type there.

The *huge* benefit is that you can load complex and simple mixers in parallel (including simple pass-through scalers), allowing you to freely assign input groups (we have one for attitude control, one for aux controls, one for payload (gimbals) and one which is the direct RC data) to outputs.
Or in other words: It allows you to pick the servo channels on a per-vehicle (= per heli make / model case).

So to recap: Every complexity can be captured in a specialized mixer (its just C code), while simple use cases can be covered with default mixers. And all of them are configurable in a text file without the need to have people change Firmware code if they just want to adjust the travel of one of their actuators or add another channel.

-Lorenz

--
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-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.

[Robert Lefebvre]

Ok, so I see you've got some of that in there.  It doesn't appear to be quite as sophisticated as Stab Patch, but I guess it could be done.  

I'm not sure what your last comment is pointing at, but there's no need for people to change firmware code to adjust travel.  Adding channels as in going from Quad to Hex, yes.

The other factor is that I think the bulk of our target market is not at all interested in the complexity of writing mixer text files.  So it could only be an optional thing, an extra frame config as Holger suggests. 

Rob

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

[Holger Steinhaus]

Hi Lorenz, 

after some test flights I can confirm that the PX4 mixer works very well for copters and there are no obvious (stability) problems. 

However, I haven't found an easy way to implement the testing of single motors (e.g. on GCS command). This is a feature of ArduCopter that I really like, e.g. for balancing props or to verify my motor numbering. Is there an interface that allows to spin a specific motor at a certain level of power while the vehicle is sitting on the ground? One challenge might be that vehicle should not be armed before, otherwise all props would spin due to MOT_SPINARMED setting.

Holger

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss+unsubscribe@googlegroups.com>.

[Holger Steinhaus]

Pull request submitted: https://github.com/diydrones/ardupilot/pull/1322

Holger 

[Andrew Tridgell]

Hi Lorenz,

> So to recap: Every complexity can be captured in a specialized mixer
> (its just C code), while simple use cases can be covered with default
> mixers. And all of them are configurable in a text file without the
> need to have people change Firmware code if they just want to adjust
> the travel of one of their actuators or add another channel.

We've discussed this before, but I thought it may be useful for me to
explain why I don't think the PX4 mixer model is a good fit for
ardupilot on this list.

As Robert points out, you don't need to change firmware to change the
travel of an actuator in ardupilot, or change the channel mapping. You
also don't need to edit a text file. All of those controls are MAVLink
parameters which are accessible from all our ground stations.

You do need to change firmware to add a completely new copter frame type
(eg. if you wanted to add a 7 motor frame type for some reason). That
has never really been an issue.

I think that requiring users to edit text files to change the travels of
their servos would in fact be quite a big backwards step in ardupilot. I
was really surprised when we were setting up the SkyWalker last year
with PX4 native that we needed to go and edit a text file in order to
reverse a control surface.

We could work around this by generating a mixer text file from the
current MAVLink parameters, and I am considering writing a generator
like that primarily as it would make supporting failsafe manual control
on fixed wing easier.

My biggest objection to the PX4 mixer system is somewhat different
though. Right now the handling of the mixing is in one place in our core
code for all boards. It doesn't matter if it is a PX4, a FlyMaple, a
PXF, an APM2 or SITL - ardupilot behaves the same on all boards. Moving
the mixing logic down into PX4Firmware would move a vital algorithmic
part of the autopilot logic into the PX4Firmware tree, which means the
mixer logic would need to be duplicated in at least two places, and we
lose the current guarantee of identical behaviour on all boards.

When I flew the PXF on the SkyWalker yesterday I just loaded the exact
parameters I had for the same airframe with Pixhawk onto the PXF and
threw it into the air. It flew exactly the same as it did with the
Pixhawk. This is one of the biggest strengths of ardupilot, and it is
something I don't want to risk weakening.

The second objection is around hiding PWM values. The PX4 mixer
architecture tries to hide PWM values from users. I can understand why
that seems appealing, but I think it is misguided. The whole world of
R/C currently revolves around these values. When I'm at the field I have
a servo tester that displays PWM values. I know the PWM values for
bottle drop mechanisms. The datasheet for my EPM release mechanism
specifies PWM values for holding/releasing the magnet. My transmitter
displays and processes PWM values internally.

So we'd need to provide access to these values regardless. I know that
with CANESC that PWM values don't have the same significance, but that
is a tiny fraction of our users so far. So for now I'd prefer to see a
mapping for CANESC where we make PWM=1000 be minimum and PWM=2000 be
maximum, then leave the rest of our structure alone.

I also think the solution Holger has posted here:

https://github.com/diydrones/ardupilot/pull/1322

is good for allowing people to choose to use the PX4 mixers if they want
to. That also seems to use a 1000 to 2000 mapping.

There are also some modes in APM:Plane that really make no sense with a
PX4 mixer. For example TRAINING mode. In that mode the mixing is either
pass-thru or stabilised separately on roll and pitch axes depending on
the attitude of the aircraft. The point of the mode is to teach people
to fly manually, so for pass-thru the controls are supposed to be
identical with or without an autopilot installed.

Cheers, Tridge

[Paul Riseborough]

A limitation of the ArduPlane mixer model is that it doesn't allow the sort of flexibility in terms of channel mappings, trim, travel adjust etc that is required for larger multi servo setups or unusual control surface configurations. Eg:

mixing flaps by differing amounts to inboard and outboard ailerons
mix flap to elevator to cancel out pitch changes rather than rely on the pitch loop reacting to the flap,
differential aileron.
matching  throws for dual control surfaces, etc.

Having an output mixer that accepts the generic roll, pitch, yaw, flap, etc demands and enables the user to map them to arbitrary combinations of control surfaces would be useful. The openTX project handles this in reasonable way, but I haven't got my head around how the user would interact with that functionality with a mission planner interface.

[Meier Lorenz]

Hi Tridge,

I see that you have a pretty fundamental position. So rather than trying to convince you, let me comment for the general audience:

I don’t think you can evaluate the PX4 mixer model for a medium-term use case like you did. It is merely designed around a system being able to read and write text config files (which are much more powerful than MAVLink parameters can ever be). It is for this reason we’ve introduced MAVLink FTP, and it allows you to build GUI’s on top of the mixer config files. Being focused on technological progress we haven’t done a GUI editor yet, but the files would be really easy to parse and write.

I’m not sure your argument on consistency across hardware platforms really applies. You are already in a position where you can’t run e.g. the EKF on APM boards, but you can run the PX4 mixer (because we are using a POSIX model) on either NuttX or Linux. In fact MAVLink FTP + text config files is very close to the common Linux config model. So if you already blew the consistency with EKF and you already have the PX4 dependency on your current main hardware platform, why not focus on POSIX-like systems and get a better mixer in? You already got the PX4 dependency for your main hardware platform (and it is a great way for us to join forces, which I’m appreciating greatly!). It doesn’t seem unreasonable to have the same dependency on other hardware platforms.

Last, I believe your PWM argument is very developer specific and in hindsight might look historic. You’re assuming here that the user-facing side of the system has to look the same as the internal guts. That would be the same as requiring all calculations to be made in degrees for the attitude estimation, but all math actually requires radians (and most of the filters actually run in quaternion space, and not roll, pitch, yaw). And yet we still display degrees and roll / pitch / yaw on the HUD and let the users enter degrees into their settings - so we already have this difference between user-facing side and implementation in the system for very good reasons, and for the very same reasons I don’t see why you would need to hold on to PWM. You still can make the user-facing side output PWM where needed.

Please keep in mind that new people entering this field and interested in multicopters (which is the vast majority of people) will soon not even know what PWM is, and 1000 being 0% throttle and 2000 being 100% is by no way intuitive or a natural choice 8).

Last, on your training mode concern: You’re assuming here that people need to do the mixing on their remote control. In a world where I can set up my drone with an app (using defaults provided by the community!), I don’t want to set up the mixer on my remote control. The menus are *horrible*. The PX4 manual override mode uses the same mixer in auto or manual, and every remote control (be it a Futaba, Spektrum, whatever) is mixed the same way onboard (which, in fact, helps greatly with consistency).

I hope that once we’ve demonstrated the usefulness of a GUI driven, text-file based mixer editor you will re-evaluate if you consider it useful.

-Lorenz

[Paul Riseborough]

A fundamental question for plane users is whether we move towards a 'dumb'  transmitter model where the adjustment of throws, mixing, etc is done in the autopilot and not in  the transmitter. To me this makes sense if we can provide users with an intuitive friendly user interface that makes it easy for 'newbies', but also provides flexibility for users wanting to do more with multi-servo setups or unusual configurations. A work-flow where the handset is calibrated like it would be for a flight sim, and the servo travels, trims, mixing, etc are calibrated as a separate step could be used. We could provide a software mixing capability that at least matches if not betters what is currently implemented by most radios.

The current  system enables a existing plane that has already been set up to fly as a conventional RC model to use the existing handset settings, mixes, etc, but is this still necessary?

[Robert Lefebvre]

I also support the idea that airplane code should move away from having mixing done in the radio.  The radio should be dumb, and should be considered as simple, discrete, roll/pitch/yaw/throttle signals.  All the mixing should be done in the flight controller.  This is how Arducopter works now.  Also, simple flybarless heli controllers also do this, so there's good evidence that the hobby market can get their head around this change.

I see this as a very important step towards eventually being able to merge the Arduplane and Arducopter code-base in a way that allows us to do complicated VTOL airframes that are a blend of copter and airplane.  

Now, how that is done, with the MAVlink implementation, or text file, I won't wade too deeply into that debate.  As long as there's a good GUI system for users, that's all that really matters, and what happens behind the scenes isn't important to the end users so long as it works.

On 20 August 2014 03:49, Paul Riseborough <p_rise...@live.com.au> wrote:

A fundamental question for plane users is whether we move towards a 'dumb'  transmitter model where the adjustment of throws, mixing, etc is done in the autopilot and not in  the transmitter. To me this makes sense if we can provide users with an intuitive friendly user interface that makes it easy for 'newbies', but also provides flexibility for users wanting to do more with multi-servo setups or unusual configurations. A work-flow where the handset is calibrated like it would be for a flight sim, and the servo travels, trims, mixing, etc are calibrated as a separate step could be used. We could provide a software mixing capability that at least matches if not betters what is currently implemented by most radios.

The current  system enables a existing plane that has already been set up to fly as a conventional RC model to use the existing handset settings, mixes, etc, but is this still necessary?

--

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-discus...@googlegroups.com.