Pixhawk reference: Without IO clarification

[hamishwillee]

This clarifies the Pixhawk Reference Hardware section "Main/IO Function Breakdown" to make it clear what happens when you disable the IO parameter - ie change of the AUX to MAIN and inputs to IO move to UART on FMU.

Note, I separately updated and merged a change to the diagram to swap over the AUX/MAIN ports and show that you can have either 6 or 8 AUX ports.

[ndepal]

Thanks for this @hamishwillee

What I think is still missing here is an explanation of what constitutes "AUX" and "MAIN" outputs. Since "MAIN" outputs can move from I/O to FMU, there must be a property of them beyond which micro-controller outputs them.

You also write that "AUX ports for motors or control surfaces" only works when I/O is present (and thus FMU outputs "AUX"). What I infer from this is that, without an I/O, "AUX" is still available to some extent but somehow not usable for "motor control surfaces". Can this be clarified?

[ndepal]

From Lorenz on Slack:

So you can get trigger going on a Pixhawk Mini because the “MAIN” device is trigger capable.

The documentation should explain what makes the "MAIN" outputs trigger capable.

[hamishwillee]

You also write that "AUX ports for motors or control surfaces" only works when I/O is present (and thus FMU outputs "AUX"). What I infer from this is that, without an I/O, "AUX" is still available to some extent but somehow not usable for "motor control surfaces". Can this be clarified?

@ndepal I really don't see how you infer this, but never-the-less, I have changed this to be very very very clear. Please review.

[hamishwillee]

What I think is still missing here is an explanation of what constitutes "AUX" and "MAIN" outputs. Since "MAIN" outputs can move from I/O to FMU, there must be a property of them beyond which micro-controller outputs them.

I don't understand what you mean, but from an end user perspective you don't care - you just need to know what port you need to connect to.

@bkueng Can you help explain to me what the property is, and who it is relevant to.

So you can get trigger going on a Pixhawk Mini because the “MAIN” device is trigger capable.

The documentation should explain what makes the "MAIN" outputs trigger capable.

@bkueng This discussion was relevant to camera triggering, which currently only talks about triggering from AUX ports. My assumption was that it only worked for AUX ports, but Lorenz made some comment about there being some way to make MAIN outputs trigger capable.

I'm not sure whether or not that is relevant in this doc, but I would like to understand how it is done so I can tidy up the camera triggering doc. Can you help or recommend someone else who might be able to?

[ndepal]

Thanks for the clarification @hamishwillee .

@ndepal I really don't see how you infer this, but never-the-less, I have changed this to be very very very clear. Please review.

Because I read "AUX ports do not work for motors or control surfaces without an I/O" as "but they do work for other stuff", otherwise I would not expect the qualification of "for motors or control surfaces" to be needed. But I understand that that is not what you meant to say here.

The confusion was confounded by the fact that I know that some functionality that is described in the user guide as using the AUX ports (i.e. camera trigger) does work when there are no AUX ports. That seemed to confirm what I inferred above.

but from an end user perspective you don't care

That may be true, but as a developer I do care.

Here is why I started asking about this: We are about to make our own flight controller board. We have been using the PixRacer so far and were thinking about switching to an FMUv5 "nano" based design (i.e. no I/O) and I wanted to be sure that all the functionality that we need would be available on such a board. While I suspected that on v5 it's the same as on v4, the docs did not allow me to come to that conclusion definitively. Asking some core developers about the distinction between AUX and MAIN outputs and what exactly happens when there is no I/O processor showed that that's a concept that is not fully clear to more than just myself.

[hamishwillee]

@ndepal OK, it doesn't matter whether I get it or not, as long as you are happy with the wording now :-)

[bkueng]

@bkueng Can you help explain to me what the property is, and who it is relevant to.

Not sure what you mean either. The property should be the label, which is what is relevant for the user. Another one might be the mixer, which is consistent with the label except for SYS_USE_IO=0.
Maybe the camera triggering is confusing?

@bkueng This discussion was relevant to camera triggering, which currently only talks about triggering from AUX ports. My assumption was that it only worked for AUX ports, but Lorenz made some comment about there being some way to make MAIN outputs trigger capable.

As confirmed with Daniele, triggering only works on the AUX pins. Or more appropriately might be on the FMU pins (or the MAIN pins in case of no IO).

[hamishwillee]

As confirmed with Daniele, triggering only works on the AUX pins. Or more appropriately might be on the FMU pins (or the MAIN pins in case of no IO).

Ah, so trigger 56 always triggers the FMU pins 5,6. On a board with I/O this is the AUX pins. On a board without I/O these are the MAIN pins. Right?

[ndepal]

AUX pins. Or more appropriately might be on the FMU pins

I think this is where my confusion comes from.

My questions are:

• Is there a specific role that the "MAIN" pins have, irrespective of whether they are driven by the FMU or the I/O processor?
• What things can only ever be done using "AUX" pins, which you lose in case of no I/O, where FMU now drives "MAIN" (camera triggering is apparently not an example of this, but what is)?

Or is this fundamentally the wrong way of thinking about it? Is whatever the FMU code outputs available regardless of I/O or not (always on the FMU pins), and whatever the I/O code outputs available regardless of I/O or not (but then it switches to being output by the FMU)?

If this is correct then I find the distinction between "MAIN" and "AUX" somewhat useless/confusing. And I think this page is then missing an explanation of how these pins are shared between the FMU and IO code in the absence of an IO processor.

[bkueng]

On a board with I/O this is the AUX pins. On a board without I/O these are the MAIN pins. Right?

Yes.

@ndepal apart from resource-constraints, you can do/ouput anything with IO as you can with FMU. The camera triggering for instance uses direct pin access, which is why it does not work on IO (in other words: it's simply not implemented).
Dshot will be another thing only on FMU. And I think input capture too, but otherwise I can't thing of anything else ATM.

[hamishwillee]

@bkueng I added two issues for capturing the camera triggering info in the parameters and the docs.

Should I also add?:

Most PX4 PWM outputs are mapped to either MAIN or AUX ports in mixers. A few specific cases, including camera triggering and Dshot ESCs, are directly mapped to the FMU pins (i.e. they will output to either MAIN or AUX depending on whetheror not the flight controller has an I/O board)

If not, is this otherwise good to merge?

[bkueng]

Should I also add?:

Yes make sense

[ndepal]

I'm still not entirely clear on how the pins are shared between / assigned to the FMU and IO code in the absence of an IO processor. If you don't want to add this to the dev guide I have no further requests. But I would appreciate more help understanding this.

[hamishwillee]

@bkueng @ndepal Merged.

I'm still not entirely clear on how the pins are shared between / assigned to the FMU and IO code in the absence of an IO processor. If you don't want to add this to the dev guide I have no further requests. But I would appreciate more help understanding this.

Me either. I don't know if this needs to go in the dev guide or not; it basically depends on whether a developer needs to know this in order to write code that goes to the correct outputs.

However I would broadly like to understand it too.

A mixer output group maps to a physical bus - PWM on FMU, PWM on IO, UAVCAN or whatever. The docs seem to indicate that when you're writing the mixer you're mapping an input group to an output group (but they don't say what the output groups actually are, or how they are selected). But what that means to me is that it isn't clear how MAIN and AUX can work unless there is some magic underneath that says on a board without an IO board the output control group that maps to PWM on FMU instead of PWM on IO. Smacks of magic.

@bkueng Where is the best place to host this discussion? Essentially though this also highlights that the mixer docs aren't very good.

[bkueng]

But what that means to me is that it isn't clear how MAIN and AUX can work unless there is some magic underneath that says on a board without an IO board the output control group that maps to PWM on FMU instead of PWM on IO. Smacks of magic.

That's correct. This happens in the startup scripts. In particular here: https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rc.interface.
An output driver creates a device like /dev/pwm_output0. Then a mixer file is loaded to that device: https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rc.interface#L162. That abstracts the actual driver, meaning the mixer file can be loaded to different drivers, that then control the pins/bus the driver is designed for. In case there is an IO, there will be /dev/pwm_output0 (IO driver) and /dev/pwm_output1 (FMU driver).

@bkueng Where is the best place to host this discussion? Essentially though this also highlights that the mixer docs aren't very good.

Not sure, maybe here or slack?

[hamishwillee]

@bkueng Here works for me. Thanks very much. That may well be sufficient - let's see what @ndepal says.

I think I get how main/aux work. So basically you have mixer file that defines up to 8 outputs. The output isn't explicitly specified but is done by order of declaration - using Z: to specify and empty spot in a simple mixer.

There are basically 2 types of mixer. Main is used for motor control, and might be loaded into any of the drivers - FMU/IO/UAVCAN. The aux one is loaded into whatever is defined as AUX. Presumably you can't load that into UAVCAN and would not need to.

Is that about right? Worth capturing something about this - maybe in 2 sections just before here: http://dev.px4.io/master/en/concept/mixing.html#px4-mixer-definitions "Output Groups" and "Mixer Loading"?

[ndepal]

Thanks, this is starting to become a lot clearer.

Perhaps one last question for @bkueng: In the case of camera triggering, which seems to bypass the mixer definition (?) what ensures that the trigger pin selection does not clash with what the mixer file wants to do?

[bkueng]

Is that about right?

Exactly.

In the case of camera triggering, which seems to bypass the mixer definition (?) what ensures that the trigger pin selection does not clash with what the mixer file wants to do?

The fmu driver is told to not use these pins via set FMU_MODE pwm4, which has the effect of ignoring additional mixer entries if there are more than 4.

[ndepal]

I see. Thanks @bkueng! And thanks to both of you for bearing with me.

[hamishwillee]

FYI, I have tried to capture the way this works (exxcept camera triggering thingy) in #856

@ndepal No, thanks for not giving up. The docs were very unclear on how this works, and it is good to have it down somewhere.