FRC Robotics with ROS

In the 2020 FRC Season, 624 decided to implement ROS throughout our robot code.

In less than one year we’ve produced a fully functional ROS robot, and a strong code base with documentation to continue to build off of in future years. For those who don’t know, ROS is an open source system for robots that provides many useful tools, libraries, and a system of communication that is helpful in building an effective robot.

We’d like to share the repository in an effort to provide a working example and base framework of an FRC robot using ROS to other teams, so that they too can explore the advantages of ROS without starting from scratch.

Within the repository is a more complete overview of what we accomplished this season along with documentation of the code that will continue to be expanded in the future. We hope to add many new useful features like a complete Unity Simulator for easily testing code without access to a robot very soon. The repository also includes a short video showcasing the physical robot and the process of creating an autonomous.

Nearly anyone can run the demo included within the repository in almost no time with no installation using the free ROS Development Studio, which is a web based environment for running ROS. You can check out some simple instructions on how to set this up and run a simple demo within the wiki of the repository below.

I’m currently a sophomore on Team 624 and worked on implementing ROS within our robot throughout the past year. If you’ve got questions or would like to contribute to the repository please feel free to contact me at [email protected], or the team at [email protected].

GitHub- https://github.com/LeonidasVarveropoulos/robot-frc

ROS Website- https://www.ros.org/

-Leonidas Varveropoulos

15 Likes

Pros? Cons? Experience? Would you recommend doing ROS? Can you elaborate on the benefits specific to FRC?

1 Like

This is very cool and I’m glad others are starting to dip their toes in the water. Is there a reason you went with an architecture that had LabVIEW on the RoboRIO but relied on NetworkTables to transmit data instead of using native ROS messages and compiling the ROS framework on the RoboRIO? Do you think that is something you’ll do in the future?

I’m also curious what made you go with Kinetic over Melodic. We were stuck on Kinetic for an additional season because of dependencies but your code doesn’t seem dependent on it unless I’m missing something.

I’ll also mention that teams can get additional information about ROS for FRC from the presentation that we (The Zebracorns) gave at ROSCon a while back: https://vimeo.com/293294796 and from our continued work published here: https://team900.org/labs/

Excellent work with this and I look forward to seeing how it evolves!

2 Likes

One of the main reasons we went with the NetworkTables communication instead of compiling ROS on the RoboRio with LabView was because of time. Pre-season we were mainly testing the ROS framework on a java programmed robot, and when we made the decision to fully try to incorporate ROS within our robot we didn’t have time to explore that route. While we haven’t had any problems with latency using NetworkTables, we will definitely explore using ROS within LabView in the future.

Originally the goal was to create an autonomous robot using the rplidar and realsense cameras as sensors, using the typical gmapping/amcl and move_base nodes to navigate throughout the field with this setup we had packages which depended on Kinetic. We got a basic form of this working pre-season but it wasn’t ready for competition just yet, so we switched to the diff_drive package and found that it accomplishes the task of auton rather well. We set up all the co-processors running Kinetic and just haven’t switched yet.

Great presentation at ROSCon which really highlights what teams can gain from using ROS. I also noticed in the video that it mentioned building a simulator for ROS with Unreal, has this been done?

1 Like

Nothing we want to share publicly but being located in NC, we know some folks and have been trying to gain some support from our friends at Epic Games on that front. We still think it’s the best physics simulation platform that’s readily accessible at the moment but integrating it with robots has not been easy. Check out NVIDIAs ISAAC project for more details on what could be possible with it.

Thanks for the response!

1 Like

Have you looked into using Unity at all? From the brief research I’ve done it looks like ROS robots have been simulated using the ros-sharp library.

Not really. The unity physics engine is no more robust than Gazebo/Ignition from what we have experimented with it. We are using Unity for other things but not in the scope of 3D physics simulation - it’s just not as good as other options.

1 Like

Here are some of the main pros and cons I can think of.

Pros

  • ROS comes with many packages that are useful when creating an autonomous robot. For example in this repo the goal follower is modified from the diff_drive package. And robot_pose_ekf is a node from ROS which takes in multiple sensor data from different sources and combines them into a usable pose of the robot. The use of these packages allow for more time to be spent on other robot specific things.
  • ROS comes with many useful tools that come to use when testing with the robot. For example rosbag allows for the recording and saving of data being transmitted throughout the system allowing for easy debugging of the robot code when something goes wrong. Rviz is a helpful visualization tool for seeing and interacting with what the robot is doing. If you have a point cloud from a camera or a laser scan you can easily display it here. Rqt is yet another useful tool which is basicly a dashboard which allows you to easily display and interact with data throughout the ROS system.
  • ROS is one of the most popular standard framework for robotics around the world and learning it provides a helpful skill for the future.

Cons

  • There is a bit of a learning curve
  • You will likely need to use a co-processor which introduces complexity, but it is also a pro because you are able to do more outside of the RoboRio

Overall I would definitely recommend looking into and experimenting with ROS as a system used on an FRC robot.

2 Likes

I think you mean pROS

5 Likes

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.