Rosanswers logo

Hello, I'm trying to learn how to properly set up a standard ROS navigation and control stack to drive a field robot (one that operates outdoors, navigating primarily by GPS and possibly a compass). My own previous experience with other systems keeps getting in the way and so I have some questions about how this is meant to work.

  1. This system is not a wheeled system, (it's a boat) and so there's not a direct measure of "odometry", which move_base seems to require. Even with speed measured by the GPS and heading measured by a separate compass, the combination don't typically reflect the actual movement of the vessel, since the vessel's direction of travel rarely matches it's heading. The speed from the GPS is course made good, not speed in the vessel's reference frame. My questions is, how should one best set this up?

  2. I understand the canonical output from move_base (from the local_planner specifically) is the Twist message, containing linear and angular velocity information. Having been told the robot's position, given a local cost map and a goal, the local planner calculates the optimal velocity message for the vehicle. What is confusing to me is that the output of all this. What the robot needs (it seems to me) is a direction to travel and a speed at which to go. But a Twist message outputs not a desired direction of travel, but the angular velocity or the change in direction of travel. It seems to me move_base is acting like a controller (think PID controller) on some level by not specifying the desired direction of travel directly. Do I understand this correct?

  3. Finally, ros_control can implement a PID (or other) controller to adjust the speed of motors (or maybe maneuver a rudder on a boat) to match the desired setpoint. But in this case, it is matching a heading rate, not a heading directly. Is this not backwards? Shouldn't the output of the local_planner be a desired heading and since the motors, driving wheels or a rudder, actually change the heading rate directly, a PID controller in ros_control would then take adjust the heading rate to achieve the desired heading published by the local planner?

I hope this all makes some sense. I can't help but feel like the roles of the local_planner and ros_control are reversed in some sense (at least with respect to the desired direction of travel).

Thanks for your thoughts, in advance. Val

Originally posted by vschmidt on ROS Answers with karma: 242 on 2016-06-21

Post score: 1


1 Answer 1


Rosanswers logo

    • I suggest you look into an IMU to get 'odometry' data. It will provide you accel and turn rate info you can integrate into velocity, twist. I think there are IMUs products that will actually do the integration for you and can output relative position data.There are filters that will allow you to combine the IMU data with GPS data to give you more precise location data. The IMU will account for things such as wind and current of water, etc.
    • Yes, move_base is exactly a controller on top of the planners, for better or worse.
    • The output of the local planner is the heading, but there is a controller that takes the heading and attempts to drive that way. Now to get the boat to do what move_base is asking, you'll need to implement an additional layer of control that uses IMU in a feedback loop to match the requested velocity and turn rate, and I expect that to get decent performance you'll need to add a layer of feed forward to that additional control loop.

The local planner publishes the trajectory of the highest scoring trajectory from the last planning loop. So it's possible for you subscribe to that if you want and develop a custom control loop fit for your application.

~/global_plan (nav_msgs/Path) The portion of the global plan that the local planner is currently attempting to follow. Used primarily for visualization purposes.

~/local_plan (nav_msgs/Path) The local plan or trajectory that scored the highest on the last cycle. Used primarily for visualization purposes.

Originally posted by billy with karma: 1850 on 2016-06-22

This answer was ACCEPTED on the original site

Post score: 2

Original comments

Comment by vschmidt on 2016-06-29:
One point of clarification. In 3) regarding "a controller that takes the heading and attempts to drive that way". Is this controller embedded in the local planner (whose output is a Twist message)? Is it PID control? Are the PID parameters exposed in any way?

Comment by billy on 2016-06-29:
Based on the move_base page, the controller is on top of the planner and uses the trajectory from planner to produce CMD. I don't know what type of algo is used in the controller. There are some parameters, but not P, I, or D.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.