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

[WIP]: mc_att_control split out rate controller and sensor aggregation into new modules #12225

Closed

Conversation

dagar
Copy link
Member

@dagar dagar commented Jun 10, 2019

Requires #12207 before merging.
Background - #12207

The multicopter attitude controller currently contains a rate controller, attitude controller, and logic for handling multiple gyros.

mc_att_control components

  1. polls primary sensor_gyro based on current sensor_selection, then adds corrections and in run bias
  2. rate controller
  3. attitude controller

This PR splits mc_att_control into 3 separate modules, each running out of a WQ. We can afford to do this because each will be running out of an appropriate WQ thread, rather than as a new standalone task.

sensors/vehicle_angular_velocity

  • subscribes to all gyros directly (sensor_gyro), estimated bias (sensor_bias), primary gyro from sensors (sensor_selection), and optional corrections (sensor_corrections)
  • publishes a single vehicle_angular_velocity

mc_rate_control

  • simpler rate controller that runs on new vehicle_angular_velocity updates
  • publishes actuator_controls_0 and rate_ctrl_status

mc_att_control

  • simpler attitude controller than runs on new vehicle_attitude updates
  • publishes vehicle_rate_setpoint

@dagar
Copy link
Member Author

dagar commented Jun 10, 2019

The overall diff is actually quite small. The majority of the change in the main loop is one level of indentation.

@dagar dagar force-pushed the pr-orb_subscription_callback-mc_att_control branch 2 times, most recently from 8a5e1b5 to c5f9664 Compare June 13, 2019 03:00
@dagar dagar changed the base branch from pr-orb_subscription_callback to master June 13, 2019 03:00
@dagar dagar force-pushed the pr-orb_subscription_callback-mc_att_control branch 2 times, most recently from 6516ae8 to 479756b Compare June 13, 2019 15:02
@dagar dagar changed the base branch from master to pr-orb_subscription_callback June 13, 2019 15:02
@dagar dagar force-pushed the pr-orb_subscription_callback branch 2 times, most recently from 312999b to a67e42b Compare June 13, 2019 18:07
@dagar dagar force-pushed the pr-orb_subscription_callback-mc_att_control branch 2 times, most recently from b7c96c9 to ca93abd Compare June 13, 2019 18:38
@dagar dagar changed the title [WIP]: mc_att_control move to WQ with uORB callback scheduling mc_att_control move to WQ with uORB callback scheduling Jun 17, 2019
@dagar dagar force-pushed the pr-orb_subscription_callback-mc_att_control branch from ca93abd to 3ff00e0 Compare June 17, 2019 20:17
@dagar dagar requested review from a team and MaEtUgR June 17, 2019 20:17
@dagar dagar marked this pull request as ready for review June 17, 2019 20:17
@dagar dagar changed the base branch from pr-orb_subscription_callback to master June 17, 2019 20:17
@dagar dagar force-pushed the pr-orb_subscription_callback-mc_att_control branch from 3ff00e0 to 5e4cca9 Compare June 18, 2019 00:11
@Junkim3DR
Copy link

Junkim3DR commented Jun 18, 2019

Tested on Pixhawk 4mini v5:

Modes Tested

  • Position Mode: Good.
  • Altitude Mode: Good.
  • Stabilized Mode: Good.
  • Mission Plan Mode (Automated): Good.
  • RTL (Automated): Good.

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoint activate RTL and see landing behaviour.

Notes:
No issues noted, good flight in general.

Log:
PR 12225

Master

@Junkim3DR
Copy link

Tested on Pixhawk 2 Cube v3:

Modes Tested

  • Position Mode: Good.
  • Altitude Mode: Good.
  • Stabilized Mode: Good.
  • Mission Plan Mode (Automated): Good.
  • RTL (Automated): Good.

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoint activate RTL and see landing behaviour.

Notes:
No issues noted, good flight in general.

Log:
PR 12225

Master

@jorge789
Copy link

Tested on PixRacer V4:

Modes Tested

Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL (Automated): Good.
Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoint activate RTL and see landing behaviour.

Notes:
No issues noted, good flight in general.

Log:
PR 12225
https://review.px4.io/plot_app?log=f2af7211-1b9a-4f8c-9193-29bbba244fc9

https://review.px4.io/plot_app?log=5d6fcd40-dc85-4bf2-a042-9dc7788042b4

Master:
https://review.px4.io/plot_app?log=d8565407-cab5-43f6-9abc-5cfcea1b4fcf

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.

Looks very good, I had some small questions but I generally like the direction this takes.
It all seems fine in SITL, I don't see any issues.


uint64 timestamp_sample # the timestamp of the raw data (microseconds)

float32 rollspeed # Bias corrected angular velocity about X body axis in rad/s
Copy link
Member

Choose a reason for hiding this comment

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

Could we make that an array?

* POSSIBILITY OF SUCH DAMAGE.
*
****************************************************************************/

Copy link
Member

Choose a reason for hiding this comment

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

I think a very brief description of the class would help reading through the code.

@@ -123,6 +123,7 @@ set(msg_files
ulog_stream.msg
ulog_stream_ack.msg
vehicle_air_data.msg
vehicle_angular_velocity.msg
Copy link
Member

@MaEtUgR MaEtUgR Jun 24, 2019

Choose a reason for hiding this comment

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

What about vehicle_angular_rate? I know this term is used a lot in this pr, I'm just suggesting it because terminoligy would be consistent with "rate controller". What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't feel that strongly about it as long is we try to be consistent at some level (with literature, ROS, internally, etc). When I first sketched this out I was just calling it vehicle body rate or even vehicle rates.

bool
MulticopterAttitudeControl::init()
{
return selected_gyro_update();
Copy link
Member

Choose a reason for hiding this comment

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

Do you select the gyro on module start "only"?

Copy link
Member

Choose a reason for hiding this comment

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

Why was I already outdated? 🤷‍♂

Copy link
Member Author

Choose a reason for hiding this comment

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

I think it was commenting on something in the 1st commit (mc_att_control changes) that changed again in the 2nd (moving this out of mc_att_control entirely)?

Copy link
Member Author

Choose a reason for hiding this comment

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

Do you select the gyro on module start "only"?

It also updates if sensor_selection (from sensors voting) changes as well.

@dagar dagar force-pushed the pr-orb_subscription_callback-mc_att_control branch 3 times, most recently from 0e4b030 to b045539 Compare June 27, 2019 05:28
@dagar dagar force-pushed the pr-orb_subscription_callback-mc_att_control branch 3 times, most recently from 444c22f to cf50d84 Compare June 28, 2019 15:27
@dagar dagar changed the title mc_att_control move to WQ with uORB callback scheduling [WIP]: mc_att_control split out rate controller and sensor aggregation into new modules Jul 1, 2019
@dagar
Copy link
Member Author

dagar commented Aug 6, 2019

Continued in #12650.

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.

4 participants