AutoRally A-star Path Finding

[27Apoorva]

I am trying to setup the ROS Navigation Stack with autorally platform. I was able to put a laser on the robot in Gazebo and was able to get the laser data in RViz. The problem is I am not able to get the map. Also, even though robot moves in Gazebo but it is not moving in Rviz. It looks like only its wheels are moving. I tried writing a node to get tf between map and base_link but apparently a new tf tree is being created. Even the static_transform_publisher isn't working for map(worked for hokuyo laser). Can anyone suggest how to setup Navigation Stack? Also, I am not able to setup WayPoint Controller. How to visualize the waypoints in Rviz? One more doubt is which is line 93 in autorally_gazebo/launch/autoRallyTrackGazeboSim.launch that I need to comment? Please let me know if you need any other details

[bgoldfai]

We don't use tf for any of our work, so we have never taken the time to set it up properly with the AutoRally platform. It's something we'll sort out if one of us can find time to work on it. You're also welcome to submit a pull request if you get something working before that.

For the waypoint controller, can you provide a few more details about not being able to setup the controller? Such as OS/ROS version, branch you are working in, error messages that are generated when running the controller? I've heard of an issue with the waypoint follower crashign on launch in 16.04/Kinetic on the kinetic_devel branch but have not had time to isolate and debug it yet.

As for commenting out line 93, it refers to commenting out the line: <include file="$(find autorally_control)/launch/joystickController.launch" /> which has moved to a different line in different branches and it looks like we need to update the instructions to reflect that.

[gsimon2]

Hello,

I am also trying to get the ROS Navigation Stack to work with the autorally platform? Has there been any advances in the last couple months?

If not, do you have any pointers for how I can get started on setting up the tf package properly? I am still pretty new to ROS, but am willing to take a stab at it.

[27Apoorva]

@gsimon2 Hi. I was able to make some progress but gmapping was still little broken. For the starters, I can say that you can put Laser Sensor on autorally. Follow this awesome guide to understand navigation stack http://moorerobots.com/blog/post/3 . Please see my github for the current status of my project ( https://github.com/27Apoorva/RBE502Project ) Also, to fix tf I know we can take static transforms between the frames which are broken. Please let me now if you are able to achieve it or if you have any questions about my code. I am happy to help.

[bgoldfai]

We haven't looked into fixing tf and using autorally with the nav stack yet, but will soon. In the mean time, if you are able to get tf working, feel free to open a pull request to get the fixes back in the the repo.

As for a pointer, here's the ROS example for setting up a robot with tf: http://wiki.ros.org/navigation/Tutorials/RobotSetup/TF I'm assuming that the fix will include updating the robot xacro file for the robot, but that may not solve everything: https://github.com/AutoRally/autorally/blob/kinetic-devel/autorally_description/urdf/autoRallyPlatform.urdf.xacro

[gsimon2]

Hello. Just wanted to check in and give an update with my progress for getting the ROS navigation stack working on the Autorally platform and ask a couple questions. I would just like to point out that I have been working on this part time over the last couple months so if I mess up some of the details here I am sorry. It has been a bit since I did some of this work and if I get some points confused just ask me and I can look them up in detail.

I have a fair bit of the navigation stack working. I have been working off of the guide linked below (as well as many others for specific problems) http://wiki.ros.org/navigation/Tutorials/RobotSetup

I believe the image should be included in this post and I'll be referring to it. If the image does not attach, it is the first diagram from the above link.

I have all of the nodes shown in the diagram finished (but not throughly tested), besides the base_controller, which I will discuss in a second.

First, I added a lidar sensor to the urdf file for the Autorally as 27Apoorva did in his repo (though I did change the positioning a bit since it appeared to be clipping inside of the chassis partially.) I then made separate nodes to broadcast the static tf messages required to complete the tf tree from the base_link to the new lidar sensor. I also had to create a tf broadcaster node relating the base_link to the odom data. I originally used your pose_estimate topic for the odom data, but while it close the errors proved great enough to make it impossible to produce accurate maps of the environment (the provided track world). I then made a node which provided the base_link to odom transform using data pulled from the gazebo model_states. This is accurate, but unfeasible for a physical platform deployment and will have to be revisited.

With these tf broadcasters in place, an accurate map of the environment could be produced using either the gmapping or hector_mapping packages. This map is then fed to subsequent simulations using the map_server package. I then added an amcl node (feeding it a fixed initial position since for simulation we are always spawning the rover on the same spot on the map). At this point using RViz you can overlay all of the topic information and ensure that the autorally correctly localizes itself on the known map and overlays the sensor (lidar) data correctly.

From here I started working on the move_base package. I used multiple tutorials to configure both the local and global costmaps, but in general this was not too difficult and I will share my config files if desired. What I am currently still playing with is using the teb_local_planner (linked below). This planer can handle the restrictions imposed by using an Ackermann driven vehicle. I have not been able to really test this much since I am still working on the base_controller node.

teb_local_planner link: http://wiki.ros.org/teb_local_planner/Tutorials/Planning%20for%20car-like%20robots

The base_controller node is where I am running into issues. This node is responsible for taking geometry_msgs/Twist and converting it to a platform specific command message, in our case chassisCommand. I have implemented the code from the tutorial above and normalized the values, but am getting pretty bad control performance. I was wondering if anyone would be willing to assist me in this task?

I will attach the code that I have done so far below. I work in python, but understand C++ as well so as long as there are comments, I would greatly appreciate any help.

I can also provide my whole repo containing the work that I have done. I have it mostly separated from the autorally repo (minus the changes to the urdf file and a couple launch files).

Thanks in advance! If you are busy I completely understand. This task has proved to involve more work than I originally thought. base_controller.txt

[gsimon2]

By the way, here is a link to my repo (contains the version of the autorally repo that I pulled as well). https://github.com/gsimon2/msu_autorally_src

I have not had time to clean it up a whole lot yet. Once everything is at least semi working I will restructure it into multiple packages rather than just one.