Overall feasibility of adding support for fully actuated hex with non-coplanar rotors?

[jpreiss]

I am interested in implementing a hexrotor with tilted rotors (i.e. this). The tilted rotors make the robot fully actuated, decoupling attitude from acceleration. This holds when the attitude is not too far from flat, and the acceleration is moderate.

I am considering using PX4 as the flight controller. I am not familiar with PX4 code architecture. Briefly looking through, it seems like the thrust mixing and control architecture is highly modularized to avoid redundant code for different rotor configurations. However, all the supported multirotors still have coplanar rotors.

Basically, I am wondering how "baked in" is the assumption of coplanar rotors. I am prepared to implement control and thrust mixing from scratch, but I want to make sure I am not fighting an uphill battle against the code architecture.

Thanks!

[MaEtUgR]

Short Explanation
Currently the default multicopter architecture works as follows:

• The position controller calculates a 3D thrust vector in world frame here https://github.com/PX4/Firmware/blob/98bd6e43e88e2274095168c2415903f419261ed8/src/modules/mc_pos_control/mc_pos_control_main.cpp#L1809
• Retrieves a projected total thrust in body z direction which is assumed to be orthogonal to the coplanar rotors here https://github.com/PX4/Firmware/blob/98bd6e43e88e2274095168c2415903f419261ed8/src/modules/mc_pos_control/mc_pos_control_main.cpp#L1985
• And calculates a body attitude setpoint in which the body z vector points into the thrust vector direction here https://github.com/PX4/Firmware/blob/98bd6e43e88e2274095168c2415903f419261ed8/src/modules/mc_pos_control/mc_pos_control_main.cpp#L2039
• While the total thrust remains unchanged, the attitude setpoint runs through attitude controller here https://github.com/PX4/Firmware/blob/98bd6e43e88e2274095168c2415903f419261ed8/src/modules/mc_att_control/mc_att_control_main.cpp#L860
• And rate controller here https://github.com/PX4/Firmware/blob/98bd6e43e88e2274095168c2415903f419261ed8/src/modules/mc_att_control/mc_att_control_main.cpp#L1022
• This results in 3 torques around the body axis roll, pitch, yaw and a total thrust in (negative) body z direction which are published through this universal actuator_controls message https://github.com/PX4/Firmware/blob/master/msg/actuator_controls.msg
• From there on you can easily even as a non-developer configure your own mixer file for your particular airframe which through linear combination distributes these outputs to your actuators.

To your Question
From our discussion I think with @dagar (who is on holiday right now) amongst others I remember that we aim to allow arbitrary thrust actuator orientations and therefore an interface with a 3D thrust vector also in the body frame. I'm not sure if anyone already worked on this or where it stands but I personally think it's a good idea.

The general structure proposal not exclusive to your question including visualization can be found here: #7318 (comment)

So I think in summary we would really appreciate any work done in this field as it would be nice to extend support of PX4 for such vehicles. The architectural changes should of course be properly arranged with the general control structure goal such that we all work into the same direction.

Here's just an other example that would profit form such an extention and was built at ETH: https://www.youtube.com/watch?v=0gR1ekapOAE

[bresch]

@jpreiss FYI, here is a good document about control of a fully actuated hexacopter: www.mdpi.com/2226-4310/2/2/325/pdf (p.331-333)

[jpreiss]

Thanks for the detailed response! I am currently prototyping on a Crazyflie because I am already familiar with that platform. I still may be interested in porting to PX4 later to run on a Snapdragon Flight.

In general, I think the (thrust, 3x torque) interface boundary between control and actuator mixing might need to be broken for fully actuated control. Since the set of achievable thrusts is defined by the actuator orientations, a good controller would probably need to know the actuator configuration and exploit this knowledge to get the best performance.

Fully actuated platforms are also used for aerial manipulation, so ideally a code restructuring should consider force control and hybrid position/force control too.

It seems like it might be too big of a change for a non-core contributor.

Either way, when I get my controller working on Crazyflie, I am happy to release it open source (it's a standalone C function) in case it is useful for you.

[Jaeyoung-Lim]

@jpreiss are there any updates regarding the fully actuated hex? This sounds super interesting

[dagar]

We're hoping to bring support for this into PX4. jlecoeur#1

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale.