-
Notifications
You must be signed in to change notification settings - Fork 13.7k
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
Add support for offboard ActuatorControl set points to RoverPositionControl (fixes #13192) #13314
Conversation
/* Only publish if any of the proper modes are enabled */ | ||
if (_control_mode.flag_control_velocity_enabled || | ||
_control_mode.flag_control_rates_enabled || | ||
_control_mode.flag_control_attitude_enabled || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you tested this in mission mode? I think this will prevent you from using auto mode
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also don't want flag_control_rates_enabled
and flag_control_attitude_enabled
since they are not supported
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created a quick mission in QGC and the rover did it well (using gazebo SITL). So this should be fine? Or what is auto mode?
I just deleted the two flags in the next commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was assuming https://github.com/PX4/Firmware/blob/07d656e971a72d1202651dfd3b4642736fb078d7/msg/vehicle_control_mode.msg#L7 will be enabled for mission mode. How about offboard position setpoints?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I see, the Commander always sets flag_control_auto_enabled
together with flag_control_rates_enabled
flag_control_attitude_enabled
and flag_control_climb_rate_enabled
for the most of the AUTO_* navigation states, which includes NAVIGATION_STATE_AUTO_MISSION
.
But for missions, flag_control_position_enabled
and flag_control_velocity_enabled
are also set to true, if you're not in transition mode (for VTOL I guess).
Offboard position setpoints are also working fine. But why is the rover loitering at each position waypoint and also when using Land mode or RTL? But I think, that should be another issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is keep loitering because the position setpoints are set as a reference to the L1 controller.
37dada7
to
7e3a956
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine to me. Thx.
if (_control_mode.flag_control_velocity_enabled || | ||
manual_mode) { | ||
/* publish the actuator controls */ | ||
if (_actuator_controls_pub != nullptr) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about using "orb_publish_auto" function to handle nullptr issues?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, or even better would be to use the new API:
https://github.com/PX4/Firmware/blob/6369ae858a79cc410c1963c1c0046bfd8a59f2a7/src/modules/uORB/Publication.hpp#L68
@jbeyerstedt could you do that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@julianoes There are cases scattered around the codebase that passes handle and meta everytime the publishing is needed. Like for example ultrasonic sensor distanve sensor driver. The Publication API really tidies up the code. I guess the left overs were from the previous era without such class / API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now I use the publication API. For the sake of completeness, I also moved the position_controller_status
publication to the new API. But most of the subscriptions still use the old one (but that's not really part of this PR).
@Jaeyoung-Lim I added Edit: And shouldn't |
18e4bb3
to
64ce60f
Compare
I rebased to the latest master, because my other PRs got merged. It still works as intended with these changes. I just don't know, why the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thx.
I try to use /mavros/setpoint_raw/local control my rover ,but it do not work. is it supply? |
@weiLiangHare Please don't hijack the topic of this PR. If you have usage questions, please post it on discuss.px4.io |
As discussed in #13192, RoverPositionControl overrides the ActuatorControl messages, that get published by the mavlink_receiver.cpp when an SET_ACTUATOR_CONTROL_TARGET message is received.
This prevented using ActuatorControl set points in offboard mode (e.g. using the MAVSDK).
I took a look at the other position and attitude controllers and realized, that they simply do not publish the
actuator_controls_0
, when the control modes does not state, that the corresponding control loop should be activated.(I fixed some indentation/ formatting issues in the header file too.)