Hello,
I am working with a USB GPS unit which i have gotten working with the gpsd_client in order to read in the GPS data from the unit. I am trying to implement VERY simple navigation in a 2D work from one way point to another. I would have to imagine that there would be packages all ready out there to take in current GPS information and to provide even a straight line path to the next waypoint.
For some background this is for a UGV project which will eventually use more complex navigation but for now we just want to get the thing up and running quickly and I we were hoping to keep the project within the ROS world any help the community could provide would be super helpful.
Thanks is advance!
The ROS navigation stack provides point-to-point navigation by default. In order to use the navigation stack, you must provide sensor streams (LaserScans and/or PointClouds), odometry information, and proper transforms. In the case of GPS, the GPS unit will provide part of the odometry required for navigation. See this tutorial for setting up odometry.
The main problem here is that A) you need a nav_msgs/Odometry message. This can be obtained using the gps_common node which will convert the Lat/Long fixes into UTM (meters) and publish an odometry message for the nav_stack. The problem here, however, is that that information is insufficient for full navigation. The nav_msgs/Odometry message also requires a geometry_msgs/Twist (i.e. the velocity of the robot in 3D space). The only way to calculate velocity using a GPS is to do a time-difference of the fixes, and even then, this information does not necessarily provide you with a heading (orientation and angular velocity). GPS is good for 2D position in x-y, but not for heading or velocities of any kind.
To solve this problem, ROS provides the robot_pose_ekf node to fuse different forms of sensor data together to use the best of each sensor.
For the time being, you could use the GPS and just take a fix-by-fix difference of position to acquire your velocity and heading. I must warn you though, GPS fixes tend to be pretty jumpy. Depending on the GPS, drift can be multiple meters between readings. Typically, GPS fixes require heavy filtering to be useful.
This is within the scope of the geographic_info project.
While there has been some preliminary work, no code has been released yet. Some basic messages and data conversions are planned for Fuerte. Please feel free to experiment with the git sources on kforge.
You are welcome to join that project. You can help us define the requirements and desired interfaces.
For what you plan, I suggest converting latitude and longitude to UTM using the geodesy package. Then, navigation can be done with straightforward Euclidian geometry.
It shouldn't be too hard to write a single node that has an action server for goals, receives nav_msgs/Odometry from the umd_odometry_node, and produces the appropriate geometry_msgs/Twist to control your base. Once you add more sensors, you can replace this node with the ROS navigation stack.
The most basic approach is to compute the desired heading to your destination, and use that as a proportional input to your yaw velocity (steering), and to compute the remaining distance to your destination, and use that to set your forward velocity.
I implemented a scheme like this on my robots, and it worked fairly well if there weren't any obstacles in the way.
Asked: 2012-01-17 05:59:15 -0500
Seen: 792 times
Last updated: Jan 18 '12
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
