GPS based navigation on a map with ROS

If you like this article, don’t hesitate to like and/or comment it. You can also follow me for more stories around robotics. Thanks in advance for your support.

In the context of an R&D project, I created an autonomous robot ables to navigate through golf courses while avoiding golfers, trees, bunkers and so on. A bit like a human, right ? More specifically, the purpose was to create a fully autonomous golf trolley. In this article, I want to give my lessons learned as well as a path to follow in order to implement your own outdoor fully autonomous robot using ROS.

Specifications

I gave you a quick overview of what we expect from this robot but as an engineer you definitely know it isn’t enough to start the implementation. Let’s dive into what is required :

• The owner of the caddy must be able to give him a GPS goal with the help of a friendly user interface and without giving any other information to the caddy. In other words, the robot must automatically find its position at startup without any input from its golfer.
• Golf rules are strict for trolleys : trolleys can’t go through a bunker, ride on the green and should avoid the rough. In addition to it, the robot can obviously not fall into water.
• This golfer friend must avoid static objects like trees as well as dynamic objects like golfers, animals, other trolleys,…

Hardware

I don’t want to go deep into this section because it isn’t the purpose of this article which is ROS oriented but that’s nevertheless mandatory to give you a quick overview of the choices my teammates and I made to achieve this goal.

The gazebo representation of our trolley

• The robot is composed of 3 wheels as on the picture above : a front castor wheel and 2 back wheels. Each back wheel is controlled by a motor. It is a differential wheeled robot.
• The main sensor is a GPS. In an outdoor environment, this kind of device is almost mandatory if you want to do autonomous navigation. But it isn’t sufficient on its own. Indeed, that kind of signal isn’t continuous and the provided accuracy isn’t acceptable. That’s why 2 other inputs provide odometry of the robot while it is moving : an IMU sensor and a feedback from the motors.
• A camera ables to provide distance to an obstacle (human, animal, tree,…) is widely used to avoid them when the robot navigates to its goal.
• Last but not least, the brain of the robot is a Jetson Nano from Nvidia. It isn’t mandatory for pure navigation stuff but some enhanced features not covered by this paper are GPU dependent.

Implementation

And now, what I guess you are looking for since the beginning of this paper… The implementation using ROS Noetic. Of course, the main piece of the puzzle is the ROS navigation stack. While a lot of tutorials are provided for indoor navigation, you can’t find that much tutorials on outdoor navigation. That’s why I wanted to publish this paper.

Get Van Malleghem Antoine’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Let me share with you a list of the different nodes in the final system. For each node, we can review its purpose and I can give you some insights on how to implement it on your own. I have voluntary omitted nodes responsible of converting raw input sensors (GPS, IMU and camera) signals in ROS standard format.

• rosbridge_websocket : the entrypoint of the system. This node is provided by the rosbdrige_suite package and allow a simple web frontend to interact with the robot using websocket protocol. This node will receive GPS goal instructions from the user interface and convert it into a ros message published in a ros topic. Notice that it isn’t required for our usecase to use an action but it is something you can do if required.
• gps_navigation_goal : this node listens to the ros topic described above and converts GPS goal in an understandable goal for the navigation stack. I created this node using C++ and it simply translates GPS coordinates into coordinates relative to the map frame. 2 steps are required to get the expected goal : convert longitude and latitude to UTM and then transform UTM coordinates to map frame. When it’s done, the goal is sent to the navigation stack.
• map_server : this node is the standard node from the map_server package. That’s interesting to notice that you can specify the frame ID you want to localize your map into. In my case, I decided to use the map_image frame ID and keep the map frame for the initial position of the robot. Using another frame ID is the first step if your robot must automatically localize itself based on GPS signal. The other steps are provided by the 2 localizer nodes described below.
• initial_localizer : provide the initial position of the robot. Most of the time, in other tutorials, this information is provided manually but our specification are clear for this point and the robot must be able to automatically find its position (translation + orientation) on the provided map. This custom node creates a static transformation between earth (the global frame) and map (frame for the initial position of the robot). To do so, you must convert GPS position toUTM format. The geonav_transform package can help you.
• map_image_localizer : provide the static transformation between earth frame and map_image based on GPS coordinates of the bottom left point of the map. You need of course to provide this GPS coordinate (using a parameter for example). Again, don’t forget to convert latitude and longitude to UTM before sending the transformation.
• navsat_transform : this is a standard node from the robot_localization package. In my case, the output is directly used by the ekf_filter_map node. In fact, I really follow the diagram provided by the package itself

Integrating GPS Data diagram from robot_localization package

• ekf_filter_map : on the diagram above, this is called EKF global. It provides the map to odom transformation based on GPS (output of navsat_transform), IMU and wheel odometry.
• ekf_filter_odom : as the package suggests, it is the EKF Local and it provides the odom to base transformation based on IMU and wheel odometry. For this one, GPS is not used.
• point_cloud_provider : provide point cloud information from images provided by the camera. This one is really related to the camera you use. You need a depth camera in order to get distances to points.
• diff_drive_controller : controller receiving a Twist from the navigation stack and able to output a command for each wheel. We had to provide a custom robot hardware implementation according to our robot motors specifications.
• controller_rosserial : this node is provided by the rosserial package and it receives the output commands from the controller and converts it to serial commands because it is the protocol used by our motors.
• move_base : do I really need to talk about this one ? This is the main node for the navigation stack of course ! This one takes everything you did before and provide the smart algorithm so that your robot can move towards a given goal given the set of constraints I described above. It will for example use the map to avoid static objects like bunkers and the point cloud informations to avoid dynamic objects.

That’s it ! I hope you have now a clear view on how to implement your own robot ables to localize itself in an outdoor environment and to navigate based on a global and local map.

Don’t hesitate to contact me if you have any question. If you want to follow our project, you can visit our website and register to our newsletter : https://www.otto-project.golf/ (it is in french for now but your browser is able to deal with it I think).