I’m trying to catch up with the new PX4 allocator. Previously in v1.12, I could create my own custom mixer (with M: O: S: etc.) which allowed me to fly any custom vehicle.
Question 1: is it still possible to use the old fashioned mixer in v1.15 ? (Looks like not)
Question 2: is there something like a pass through with the new allocator ? (To be clear I want to pass a custom signal to my chosen actuator, I don’t want to pass my RC.aux signal).
My system is a quadrotor with a central engine where all four propellers spin at the same RPM. The roll-pitch-yaw moments and quick trust are achieved by changing the individual propeller pitch blade (i.e. collective, which is activated by one servo per prop).
I also need my pseudo inverse to allow negative thrust signals, since the servos are bi-directional.
I need a signal for the engine throttle that is not mixed into the pseudo inverse of the allocation, therefore a passthrough would be needed for instance.
Q3: I see that CA_AIRFRAME = 9 allows for a custom airframe, what’s the influence of that?
Q4: I also see PWM_MAIN_FUNC1 = 301: Peripheral via Actuator Set 1. That does look like a passthrough, which uORB topic signal is sent to that ?
A lot of questions, thanks for you kindness and patience with my learning curve
@Romain_Chiappinelli I suspect many are on holiday. I am a bit too. Sorry for response delay. Here’s my take on this:
Question 1: is it still possible to use the old fashioned mixer in v1.15 ? (Looks like not)
No. In v1.13 it was the default. By 1.15 it was gone. Good riddance - I’m glad you could use it, but I had to document it and it did my head in.
Question 2: is there something like a pass through with the new allocator ? (To be clear I want to pass a custom signal to my chosen actuator, I don’t want to pass my RC.aux signal).
I don’t know. You you can always bypass an estimator by providing your own but not “genericallly”. I..e. you can do it in offboad mode for copter like this Offboard Mode (Generic/All Frames) | PX4 Guide (main) if that helps?
My system is a quadrotor with a central engine where all four propellers spin at the same RPM. The roll-pitch-yaw moments and quick trust are achieved by changing the individual propeller pitch blade (i.e. collective, which is activated by one servo per prop).
I also need my pseudo inverse to allow negative thrust signals, since the servos are bi-directional.
I need a signal for the engine throttle that is not mixed into the pseudo inverse of the allocation, therefore a passthrough would be needed for instance.
Q3: I see that CA_AIRFRAME = 9 allows for a custom airframe, what’s the influence of that?
Q4: I also see PWM_MAIN_FUNC1 = 301: Peripheral via Actuator Set 1. That does look like a passthrough, which uORB topic signal is sent to that ?
A lot of questions, thanks for you kindness and patience with my learning curve
All of this is beyond me. Let’s see if we can get some advice from the experts. @MaEtUgR@bkueng Can you advise?
From my perspective I am quite interested in “how far you can go” with the existing configuration. AIUI each CA_AIRFRAME maps to code to select allocators/estimators etc for a particular geometry, but customisation beyond what is provided would require code changes. So I’m wondering if that CA_AIRFRAME is a hook through to your own code somehow - in which case we need to explain how that might work.
So I ended up implementing my 1 dimensional pass through by having a single motor facing forward (in reality it does not face forward, but the orthogonality with the other motors end up generating a pass through for this one signal), then I send my custom signal to rates_setpoint.thrust_body[0] inside mc_att_control. (I know this breaks the functionality for most other vehicles, but this is a dev branch for a prototype only, not intended to be merged back).
I guess the relevant signal being passed through is vehicle_thrust_setpoint.xyz[0].
My HIL airframe script defines the standard quadcopter parameters, then param set-default CA_ROTOR_COUNT 5 param set-default CA_R_REV 15 param set-default CA_ROTOR4_AX 1 param set-default CA_ROTOR4_AY 0 param set-default CA_ROTOR4_AZ 0 param set-default CA_ROTOR4_KM 0 param set-default HIL_ACT_FUNC5 205
Q5. I’m still curious to hear if there is a cleaner way to define a pass through for a custom signal, without using the orthogonality trick (which allows only up to 2 pass through signals). Thanks
Q5. I’m still curious to hear if there is a cleaner way to define a pass through for a custom signal, without using the orthogonality trick (which allows only up to 2 pass through signals).
Me too. Let’s see if @bkueng or @Benja or @MaEtUgR can comment in the new year. Ping me again if you don’t hear from one of them .
Hi! The old mixer isn’t fully supported in v1.15. You can use actuator outputs for passthrough—PWM_MAIN_FUNC1 usually handles uORB signals. Setting CA_AIRFRAME = 9 lets you define a custom airframe for your vehicle.
And thanks @bkueng for the details, this is the kind of thing I was looking for. Is that documented somewhere ? If not, is there a desire / need to do so ?
For now, I’ll keep the orthogonality trick since that works.
@bkueng I’m happy to write some documentation on what you described, but I want to avoid the rabbit hole of modifying the code, compile, test it, etc. Are you willing to do some testing if I write the documentation?
