Goals and waypoints!


Here´s some example of what im exepriencing:

The image on the left shows the robot goal trajectory being followed as instructed, the image on the right shows the same line from a different start position but the same goal_waypoint but the robot ending in a unknown location! This is happening very often, but as you can see on the image on the right, the “purple line” that is for the target is well drawn on the map, but the robot seems to loose imself on the map and ends going to “no mans land”

Theres something to do about cases like this? Are anyone else experiencing the same issue? Could be a faulty camera doing a bad reading of the fiducials?

Hope somebody can help me!

Another question, and i think @rohbotics is the person for the job :slight_smile:
It is possible to send waypoint goals trough command line instead of the AndroidApp? Once the waypoints are deleted on reboot i need something to make them persistent trough reboots!


@davecrawley @rohbotics maybe i´ve found a bug on the motors.

When i run this code :

"rostopic pub /move_base_simple/goal geometry_msgs/PoseStamped “header:
seq: 0
secs: 0
nsecs: 0
frame_id: ‘base_link’
x: 1.0
y: 0.0
z: 0.0
x: 0.0
y: 0.0
z: 0.0
w: 1.0” "

in order to obtain a full 180º degrees rotation the robot executes the perfect 180º by itself, but then whe i just run the exact same code the robot do an almost 183º degrees!

Can this be a problem on the motors? See picture attached to see if you observe anything wrong!

To address one of your questions, you are already half way to sending nav goals from the command line.

Use the same rostopic pub command that you are already using, but use the frame_id map to specify the goal in the map frame.

To get the coordinates of waypoints, run rosparam dump - /waypoint they should be in the output.


sorry to kinda hack this thread, but is there a somehow shorter way to send those waypoint through command line using default rostopic pub command ? (afterall, we just need x,y,theta) instead of a 10 lines commands?

or i will have to write my own wrapper in python and call it with a rosrun command ?

please advise.

after changing the frame_id to “map” im now able to navigate trough waypoint, altough i was unable to retreive the waypoints using your command i found a easy way to find the position of the robot, i just move the robot into the desired position of the fiducial map, making sure that at least 2/3 fiducials are in the camera range and the run on the robot “rostopic echo /fiducial_pose” and i get the exact position, i then extract the output and run, the robot now know where he is and goes to the Waypoint ive just extracted!

I will now try to build an app to send those outputs the way i need it!

The only problem im facing now is the robot are stoping in slightly different positions due to the angle he does before he starts to go forward! I believe that its related to the problem i´ve mentioned above, that when i order the robot to do an 180ºdegrees rotation he “kinda” does an 182º, and if i order again he seems to compensate that º2 degrees and do an 182º… so in the end the 360º is ok but to do an 180º or even an 90º for the first time, the robot always ads an extra 2º/3º degrees…

Sorry for this long post but im trying to explain exaclty the problem!

May this be a faulty motor? or only an minor glitch? can u try to do the same test as i did in one of your robots to see?

PS… When i use the andoid app and speech “Rotate right 90º or Rotate left 90º” the problem is the same, can some one test this aswell pls?


This is likely not a faulty motor.

Move basic has a parameter that sets the minimum acceptable accuracy. We do this so that when the robot rotates to roughly the right orientation it quickly moves on to the next stage and the robot doesn’t stop and spend a lot of time trying to get the angle perfect. Similarly when we set the waypoints - the robot doesn’t need to get to the exact point of the waypoint so that the robot doesn’t spend a lot of time driving back and forth trying to get to the exact point. These are parameterized acceptable accuracy. The default values are set for quick robot movement - and so you might find them a little too loose for your application.

There are two ways to solve this:

  1. You can set multiple waypoints along the way to where you are trying to get the robot to go. When the robot reaches a waypoint and you set a new waypoint the robot will recalculate the path to that waypoint. This way if the robot doesn’t get the angular accuracy perfect it will still follow a reasonable path to where you want the robot to go.

  2. You can tighten the parameters that set minimum acceptable accuracy. I believe that this can be done in the launch file.

Im testing on a 10meters area… imagine doing that in 90meters linear… I’ll try the 2 option to see if it fits better…

Is this the parameter that i can adjust?


I believe the ones you want are angularTolerance, and maybe linearTolerance.

For a 90 meter path you probably want to have a few intermediate waypoints along the way, even if the path is a straight line. In the current software setup that gives the robot the chance to course correct. By the way planned updates of our software will eliminate that need as well as make the angular tolerance parameter almost redundant but we aren’t there yet.

1 Like

Thanks David! I’m rooting for your team to have more and more features… so this awesome project can spread to more people :wink:

1 Like

@davecrawley I thought I could just reach the file move_basic into the robot and can just change the parameter! But I can’t…

We are working on making waypoints persistent. The idea is to write the waypoints to a file whenever they change and read them back in at startup.

1 Like

That would be awesome! :smiley: Thanks for the commitment to help my project!!

@brunolfm you need to look at the launch file that’s where the parameters are set.