Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[New feature] Tilting multicopters #22096

Closed
wants to merge 0 commits into from
Closed

Conversation

salvamarce
Copy link

@salvamarce salvamarce commented Sep 18, 2023

Premise

This is a customized version that I made to control our research platforms with PX4. After some flight tests, seeing how easy it could be to build a tilting drone with PX4, I thought to propose that to you.
I think that this feature will not be ready to be added as it is, but if you find it interesting, I would like to work on that (with everyone who's willing to help) in order to get it ready.

Customization for tilting multicopters

This repo presents a general framework for multicopters equipped with tiltable rotors (tilting multicopters). Differently from classical flat multicopters, tilting multicopters can be fully actuated systems able to decouple position and attitude control. Simulation models have been also added to the "gazebo-classic" submodule.

To test with an omnidirectional tilting drone
make px4_sitl gazebo-classic_NDT_tilting

Solution

  • A new airframe class has been added, with the ID = 12
  • The allocation matrix is static, as presented in [this paper](doi: 10.1109/mra.2018.2866758 ). Ideally, it should have a number of columns equal to twice the number of motors, but due to size restrictions, it has been implemented with two allocation matrices (like in the VTOL). The two matrices are needed to allocate the lateral and vertical force of each rotor and, from them, evaluate the rotor velocity and tilt angle.
  • The multicopters' controllers have not been changed, there are only a few additions:
    • In the position control, the output is a 3D force vector and there is the possibility to send a desired attitude (for example from an external application, and in the future from an RC channel)
    • In the attitude control, the orientation of the tilting drone is kept flat while flying, and to fly with an H-shape one-tilt tilting drone the angle for the movement is mapped on the tilt motors

Context

The description of the firmware architecture, the integration with the standard PX4 control stack is described in the following article:
Salvatore Marcellini, Jonathan Cacace, Vincenzo Lippiello, "A PX4 Integrated Framework for Modeling and Controlling Multicopters with Tiltable Rotors", submitted to the 2023 International Conference on Unmanned Aircraft System (ICUAS ’23) June 6 – 9, 2023 Warsaw, Poland

Videos

@salvamarce salvamarce marked this pull request as ready for review September 18, 2023 23:19
@salvamarce salvamarce changed the title New airframes for tilting multicopters [New feature] Tilting multicopters Sep 19, 2023
@DronecodeBot
Copy link

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-community-q-a-september-20-2023/34296/3

ActuatorEffectivenessRotors(ModuleParams *parent, AxisConfiguration axis_config = AxisConfiguration::Configurable,
bool tilt_support = false);
bool tilt_support = false, bool tilting_omnidir = false);
/*** CUSOTM ***/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you seen that we already have a ActuatorEffectivenessTilts that is used for tiltrotors? I think it would be more elegant if the tilting multirotor uses the Tilts, rather than hacking something into the Rotors

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I saw this file but here the problem is a bit different. In the file that you linked, the author just considered that the rotor can be tilted and with that the torque sign. Instead, in the case of tilting multicopters, the allocation matrix differs from the normal one, so I had to change a bit the code.
But correct me if I'm wrong

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at a closer look and talking to @sfuhrer I think you are right, but wouldn't it then be better to expand the tilt actuator to dynamically update the allocation matrix?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updating the allocation matrix with the tilt angle will lead to singularities in the allocation matrix. That's why the real allocation matrix is modified, resulting in a constant matrix with double the number of columns, which is always invertible (of course with the pseudo-inverse, being rectangular)

uint64 timestamp # time since system start (microseconds)

float32 roll_body # body angle in NED frame
float32 pitch_body # body angle in NED flag_control_manual_enabled
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is yaw left to be free?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't add the yaw at the moment because it is intended to work in offboard or position flight mode. In the first one, the yaw is already sent with the normal trajectory message and I didn't want to mess up with the rest, while in the second the yaw angle is sent from the RC.
Of course, it can be changed/improved

if(_param_airframe.get() == 12 ){ //If tilting_multirotors

//To do: change the time_constant of the filter from 0.0f to a param
_man_Fx_input_filter.setParameters(dt, 0.0f);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is there a filter with time constant 0? Is it necessary? Did you tune that in your testing?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not something that I've changed, it should be and old state of the code. I will change that according to the actual main branch

// Transform to euler angles for logging only
Eulerf euler_des(q_sp);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be prefered to do the calculations as quaternion directly or axis angle like in the stick generation.


tilting_servo_sp_s servo_sp;

if(_param_airframe.get() == 12 ){ //If tilting_multirotors
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably we should have a completely distinct attitude generation in a separate function for this use case.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can write a function with the same instructions and then call it to make it more easy to understand. Is that what you mean?

@@ -557,6 +561,74 @@ void MulticopterPositionControl::Run()
// Publish attitude setpoint output
vehicle_attitude_setpoint_s attitude_setpoint{};
_control.getAttitudeSetpoint(attitude_setpoint);

/*** CUSTOM ***/
if(_param_airframe.get() == 12 ){ //If tilting_multirotors
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say the best way would be to have a different strategy to map acceleration to attitude altogether. At least thrust to attitude. Otherwise, there are assumptions involved that don't apply if you can tilt the thrust without the vehicle. I wanted to make the acceleration to attitude part more modular such that it's easy to plug in a different allocation but the limit feedback is what makes it not trivial. At least thrust to attitude is easy to replace in terms of interface.

ControlMath::thrustToAttitude(_thr_sp, _yaw_sp, attitude_setpoint);

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure I completely understand what you mean.

Otherwise, there are assumptions involved that don't apply if you can tilt the thrust without the vehicle

With omnidirectional tilting drones you can tilt the thrust by tilting the rotors, without tilting the vehicle

Copy link
Member

@MaEtUgR MaEtUgR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool initiative. There were people requesting this before and VTOL pusher assist could benefit from a more general allocation as well. I have to look into it closer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants