Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
setpoint_position: accept set-position-target-global-int messages #1184
This PR attempts to allow mavros to accept SET_POSITION_TARGET_GLOBAL_INT messages from the flight controller or GCS. This is useful because it can allow a ground station operator to pass the position target to ROS (so that it can do the path planning) without using rviz.
Below is an image of a test using Mission Planner attached to an ArduPilot Rover with ROS running on a tx2. I was able to select ROS using MP's upper-left vehicle selector and the right-mouse-button-click and select, "Fly To Here". When mavros consumes the message it converts the latitude, longitude, altitude into ENU and publishes it to /mavros/setpoint_position/cmd_pos topic
While testing I found two issues which I'm hoping the reviewers (@vooon?) can give me a hand in resolving:
Anyway, all feedback is welcome, thanks!
Mar 7, 2019
I think this PR is working now and I've done a blog on ardupilot.org including a couple of videos (auto mode, guided mode) showing how ROS's path planner can be used as an external navigation source for object avoidance.
@vooon, any chance this can be merged?
I'm happy to make changes but I probably need some more specific feedback on what needs changing.
I understand @TSC21's comments that we need to be careful of mixing up commands received from a GCS and those received from a vehicle but with these enhancements to ArduPilot Rover, the position target is now coming from the vehicle.
At the risk of overblowing this minor change, I think it a nice enhancement that allows the flight code to remain in control and only use ROS as a navigation tool when it wants to.
@rmackay9 just because something is working for a particular case doesn't mean that we are doing things thr correct way. There is an API and an implementation logic that should always be respected, unless there's nothing we can do besides messing with the API logic.
As a reviewer, I gave a specific feedback on what needs to be changed :) I am happy to help you make this implementation correct (not make it work, cause it seems to be).
I wonder if this is correct from the Mavlink API standpoint. Again,
@TSC21, thanks again for the feedback. So the objection is with the SET_TARGET_POSITION_GLOBAL_INT messages coming from the FCU? I think we haven't had SET_ messages come from the FCU only because we haven't previously tried to make the flight controller the "master". I.e. the flight controller has always been the "leaf".. it's been pushed around by upper level controllers within ROS. I don't really see why there would be a restriction on a flight controller providing a position target to ROS's navigation controller... and if we accept that it is OK for a flight controller to provide a position target to ROS, I don't see how it would get it there unless it used the SET_TARGET_POSITION_GLOBAL_INT message (or the very similar SET_TARGET_POSITION_LOCAL_NED)..
.. by the way, I'm very happy to having a voice chat somewhere if that would help speed things along.. we could use AP's mumble server but skype or hangouts or whatever also works for me.
@rmackay9 this is not a matter of what has been tried or not. Is what the API is set to do and changing that paradigm first needs a discussion on the Mavlink API. We can't just assume we can use a message in a certain way just becaude it works. Then we would be using all the messages the way we wanted.
If one wants to update the Mavlink protocol API, then one should suggest that same change first, and not apply the message in a certain way that contradicts the API.
vooon left a comment
Besides really confusing message usage (with it's description),