Using ROS for inspiration in FRC

Hey everyone!

For the past two years, I’ve been working with team 88 to implement ROS on their robot. I’ve written a paper on some of the work we did to get ROS running at worlds in Houston this year! We implemented LIDAR-based localization and got some significant scoring improvements.

You can find that paper here: Link to the paper

Here’s a wiki walking through our code base: Link to the code wiki

I’d like to take this opportunity to ask for your help. I believe ROS is a ticket for more interesting robots and more aspiring robotics engineers. If you’re interested in helping make these tools accessible to more teams, send a reply to this post and I’ll reach out.

I’d also love to hear how you’re using ROS on your robot if you’re already doing that. I know there are at least and handful out there. Our approach wasn’t perfect and I have some ideas on how to improve it. Let’s compare implementations!


paging @marshall :grinning_face_with_smiling_eyes:


This is really cool! It looks to me like its using ROS on a Jetson and then sending data to and from the RoboRIO using networktables. It seems to be how most folks are trying to tie ROS into FRC.

The code and documentation are absolutely top notch though and there is some stuff here I’ll have to take a closer look at.

We’ve taken the approach of running the full ROS stack on both the RIO and our Jetson(s) on the robot. We’ve found a lot of benefits to it with the ROS toolsets and command line and it keeps us in the ecosystem:

I’ll let past me and past Zebracorn students provide some cool links via this post:

And we’ve got a lot of our work published here and though we haven’t made it back to an in person ROSCon yet, we did continue the tradition of having our students present at ROSWorld:


This is really cool thanks for sharing.


The pros of putting ROS on the roboRIO are appealing. Are there cons you’ve encountered with this setup? We chose to use networktables because our team primarily uses Java to develop. I would say it was a bit painful/error prone to split functionality like this. For auto targeting, the Jetson essentially acted as a sensor that suggested turret and shoot flywheel speeds. When the Jetson was running auto modes, we wrote commands that surrendered control the Jetson for a bit.

Even if our team was willing to put all control on the ROS side, I’m still a bit hesitant to do that. WPI has put out some pretty sophisticated tools for multi-variate state space control. We’re using these libraries here:

Would it be possible to use these libraries if ROS is the main driver?

1 Like

Tons! However, we’ve done a lot of work to resolve them - specifically working with NI and wpilib contributors to help get some changes on the RIO, as well as working with HQ on rules changes to help us and other teams. We actually run most of our control through the Jetson via a SocketCAN adapter, so the Jetson controls the motors directly with enable/disable coming from the RIO, the exception being the pneumatics controller at the moment.

For us, the struggle was real in the beginning but the benefits of being able to use so many of the ROS command line tools, bring up nodes on separate systems at will, and leverage so many more features have been worth it. I can’t say it hasn’t been a struggle though and there were some key architecture choices we made early that I think have helped us as things have changed. Definitely check out the original ROSCon talk and the older white papers as we explain some of that - as well as the epiphany that we arrived at trying to use LV to talk to ROS.

Not a clue. Probably not without modification. I haven’t touched Java on an FRC robot in quite some time so I’m not sure how the ROS Java implementation works at all but I’m sure it exists. I think the main thing to understand is that it isn’t “wpilib or ROS” but “wpilib and ROS” - I think it’s a huge testament to how well written the core wpilib functions are that we can utilize them and layer in the additional functionality that we find helpful. That flexibility isn’t accidentally coded, it’s intentional, and should be applauded.

ROS is effectively middleware for robots and it’s quaint to see that as “just plumbing”, particularly for higher level sensor systems where you see a lot of the research being done and demos aplenty…. but the abstractions it provides work at lower levels too. I don’t want to minimize the work done but the ROS control boilerplate and wpilib combine to form an impressive team.


Question: why do teams choose to run ROS on a coprocessor instead of completely on the RIO? Is it difficult to compile for the RIO?

I would like to see more ROS in FRC, given its use in academia.

1 Like

Yeah, I only know of two efforts to do so and only one that’s seen field time, though I wouldn’t be surprised to see a third before too long.

It takes some work. We are in the process of an upgrade to ROS Noetic (have been on Melodic for a while) and I think that’s going to be a big game changer for us and enabling students to use python3. It’s a fair amount of checking and verifying things - specifically some updates to gcc 7.5 being a recent blocker for us that we had to resolve but all of our code is public and we are always happy to answer questions.

Ohh, and it’s not just academia using ROS anymore, it’s industry and the number of jobs and companies is growing rapidly.


Glad to see more folks using ROS in FRC. The ROSCon / ROS World talks Zebracorns gave in 2018 and 2021 was a blast for me!

Although my team don’t use ROS for our own reasons for now, I’m more than happy to help making it more accessible. I work at PickNik Robotics, who is a member of TSC, and I am one of the maintainers of MoveIt and contributor to some other widely used packages including ros2_control and Gazebo. If I can be of any help regards this topic or anything ROS related please send me a DM, and I will be delighted to meet and talk more.


Please tell Dave Coleman that The Zebracorns say hi!


Will do gladly!


My team chose to run ROS on a coprocessor primarily because the team develops with WPIlib and Java. This was their first their first year using ROS so they didn’t want to do a full lean into it. I suspect that this team will continue to do it this way for the foreseeable future for this reason.

1 Like

Awesome! Our robot has basically four robot arms on this year. I thought about trying MoveIt to create our climbing routine but didn’t have the time. I’d love to learn more about it.


Started looking at this beginning of the season.


We had two matches where our neural net recognized and picked up cargo at Battle Cry!

As described in the paper, we ran our static trajectory and picked up cargo automatically after. In the first link, we actually picked up our rebounded shot and scored it!


There has been a new initiative in ROS community called ROS Sports, posting here since there may be some teams that want to join / contribute: Proposal for ROS Sports Community Working Group - General - ROS Discourse

1 Like

Very cool! Looks like it is focused on ROS 2 packages. We’ve just recently been talking about our transition plans to get on 2 but will keep an eye on this. Just saw the announcement from NVIDIA too about them releasing some code to coincide with the hardware accelerated working group. Very cool stuff.

1 Like

Cool! 88 is working on some demos for nav2 in FRC: tj2_ros/tj2_navigation at dev/ros2 · frc-88/tj2_ros · GitHub
Still work in progress. We aim to improve our live object following routine using nav2’s GoalUpdater behavior. Hopefully we’ll have it ready for next season. We’ve encountered a lot of reliability issues so far.

If more teams adopt this kind of thing, we should create a common package repository for FIRST.


woah woah woah… you guys aren’t using ROS 2? My smart toaster is SLAMmin’ away as we speak with ROS2 humble running on its built in C64. Get with the times marshall, get with the times.