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

[Bug] Normalized 3D Thrust and control allocation #22746

Open
Jaeyoung-Lim opened this issue Feb 13, 2024 · 1 comment
Open

[Bug] Normalized 3D Thrust and control allocation #22746

Jaeyoung-Lim opened this issue Feb 13, 2024 · 1 comment
Labels
bug-report Flight Controls 🦅 Anything about flight control algorithm (Navigation, Attitude control, etc)

Comments

@Jaeyoung-Lim
Copy link
Member

Jaeyoung-Lim commented Feb 13, 2024

Describe the bug

Currently, the 3D thrust setpoints are assumed to be normalized, basically resulting in a bounding box ranging from [-1, 1].

There are two issues with this approach.

  • The box constraint results in a thrust range that exceeds the normalized thrust boundaries[-1, 1], ranging to a maximum magnitude of sqrt(3) (=1.732).
  • The maximum thrust may depend on the direction of the force.

For the second issue, the problem is that the pseudo inverse in control allocation assumes that the maximum thrust is uniform around all direction and therefore resulting in different thrust scalings depending on the direction of thrust.

For the omnicopter, the maximum attainable thrust is the shape of a polygon, rather than a sphere:
image
(Source: Brescianini, Dario, and Raffaello D’Andrea. "An omni-directional multirotor vehicle." Mechatronics 55 (2018): 76-93.)

Therefore by assuming a spherical maximum thrust (1.0 is maximum thrust), we end up having scaling effects of thrust depending on the direction where the thrust command is sent.

To Reproduce

This can be easily reproducible in SITL

make px4_sitl gz_x500
  • Takeoff the omnicopter
commander takeoff
  • Observe that with the same 3D thrust setpoint, the output thrust changes. (Different steady state errors depending on attitude).

Expected behavior

Possible Fixes

  • We calculate the maximum thrust value from the motor output, and rescale the thrust setpoint to incorporate direction-dependent scaling effects.
  • We move away from normalized thrust completely, and use metric control allocation. We can still keep the normalized workflow, if everything ranges from [0, 1], but they are assumed to be a metric value

Screenshot / Media

This explains the behavior of the vehicle moving around while rotating: https://youtu.be/nsPkQYugfzs?si=g2c6UyJeXZD7LFzI&t=6

Flight Log

  • Log:

Software Version

latest main

Flight controller

SITL

Vehicle type

Other

How are the different components wired up (including port information)

No response

Additional context

No response

@DronecodeBot
Copy link

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

https://discuss.px4.io/t/control-allocation-roll-pitch-torque-effectiveness-actual-meaning/37070/3

@junwoo091400 junwoo091400 added the Flight Controls 🦅 Anything about flight control algorithm (Navigation, Attitude control, etc) label Feb 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug-report Flight Controls 🦅 Anything about flight control algorithm (Navigation, Attitude control, etc)
Projects
None yet
Development

No branches or pull requests

3 participants