This year I was lucky enough to be able to dive into and help with the development and use of ROS on our team’s robot.
Now that the season has ended, I had some questions for the community.

What other teams use ROS?
Is your team interested in using ROS?
If so why have you not/what is stopping you from switching to ROS?

This is just a general discussion amongst the first community as I am interested in seeing what everyone around the world thinks about ROS.

Any and all input is really appreciate!

EDIT: fixed wording/Format


@marshall and 900 work ROS as I recall.

However, one big reason most teams don’t use it is that it isn’t officially supported by FRC (unlike Java, C, and Labview), so if you mess up you’re on your own. (Python has an unofficial support network as I recall, or possibly has been added to the official list.)


Python is official as of the 2024 season.


Our team had a presentation on ROS that was well received at the Championship. The slides are available here, although we don’t have a recording.

We used ROS2 this year on an NVIDIA Jetson, although we had some durability issues with that coprocessor. By the time we packed up at the Championship we were running off an OrangePi5, which seemed to be better.

PS, I’m almost always rooting for TJ^2. The kids have heard me saying many times that, “A win for TJ is a win for ROS.”


Yes! I was very lucky to have actually been able to attend the meeting and sit front row at that! It was truly a gift, and thank you for the link to the slides! There was a lot of information that I was not able to take notes on as I lacked the better judgement to bring a notebook unlike what seemed to be everyone else at the conference…

And I really appreciate your support! I figure you’d also be happy to hear that my main intention with this thread is to get an idea of the communities desire/want for ROS as I hope to work on and create a “plug and play” type package for ROS to help expand it among FIRST.


While I find ROS fascinating, and we do have mentors with experience, it jsut lacks the official and unofficial support networks that come with the standard control stack (particularly with Java).

1 Like

Hey, I spoke with 88 and 195 this weekend about their different approaches to using ROS in FRC with the intention of bringing it to our team this year.

I would be interested in contributing to a project like this.
I think a vendorlib and a coprocessor image (akin to photonvision) with a way to deploy nodes easily would go a long way for letting teams sprinkle in ROS on a small scale first before fully committing.


I will say, coprocessor and hardware concerns aside, the number one risk to consider for anyone considering the jump is the limited support network you’ll be able to lean on in terms of CSAs, FTAs, and other teams.

We’re fortunate to have alot of software mentors and students to get us past those limitations (and are obviously willing to work with anyone else making those efforts), but a hidden bonus downside has also been that our programming students can’t really offer as much help to other teams as we have at sometimes in the past, just because they’re no longer familiar at all with the normal way of doing things.

Having talked about it a lot this past week, I will say that some of the significant reasons we switched to ROS in the first place (better visualization tools, better data replay) have been specifically floor leveled with some of the impressive work that 6328 has brought to the table with advantage scope and advantage kit that offer extremely similar capabilities (with the benefit of being more widely adopted and specifically targeting the FRC audience).


we can coordinate better in the future when my schedule starts to clear up for the summer, glad to hear there is interest in this!


This is definitely something to be considered with a big project such as making ROS easily useable for teams. Does ROS hold more benefits in the long term/is it going to pay off investing the time into a system like ROS.
With the surface level work I did this year I would still say my (totally unbiased) opinion sticks strong with ROS having capabilities that make the time and resource investment worth it in the long term goal.

1 Like

Not to only harp the negatives, I think the principal benefit of ROS is it’s widespread academic and industry adoption.

When an FRC alums application crosses my desk, their familiarity with WPILib won’t really help my case that we should hire them immediately, but everyone understands what ROS is.

Even the ROS nav stack would be tremendously more interesting if it weren’t for generally not worrying about true obstacle avoidance in FRC, which the ROS nav stack is obviously designed to accommodate.


Adding on to this, in terms of making our ROS environment more accessible, we do have an image for an Orange Pi 5 Plus that should be mostly complete. As @Monjhall had mentioned, we were able to switch from a Jetson to the OPi mid-day at champs with minimal headache.

One of my main goals for this offseason is to better document the setup and development process we go through. As well as building a sample swerve drive project, that anyone should be able to get up and running within a day :crossed_fingers:


Does 195 have any other big projects with ROS that is being worked on?

1 Like

I wouldn’t say there’s anything major. Mostly looking into making the system more robust and the aforementioned documenting.

We have talked about finding third party packages that could be of use in an FRC context and trying to integrate them. But this is very much still in the brainstorming stage. The ROS nav stack would be cool to have at our disposal, but it’s usefulness in FRC feels extremely limited, as it’s more aimed at room navigation and obstacle avoidance.


Does 195 keep an updated documentation of work like this? Either here or github or anywhere else? I feel like I could continue to learn a lot from another NE team that uses ROS and I would like to follow along if possible

1 Like

We tried last year with our robot arm, but we failed. I wasn’t involved in this, but I would like to try this.


We don’t really document while we’re experimenting and testing, but you can check out our gitlab here. Basically everything we work on is a public repo, so there’s lots to poke around in.

I will try to get a simple setup doc sometime this week if you’re interested in trying to run our project locally.


Definitely will do this!

I am still in the process of getting my hands on some hardware (like a jetson) but this would be amazing!

1 Like

Look for a 4gb nano if you are trying to save on cost over the newer nano orins. Don’t skimp and get the 2gb it’s not good enough. The 4gb however I was able to run with ROS Noetic and an updated Ubuntu OS. The latest official for that was Melodic with the Jetpack. If you do get one lmk if you want the Noetic setup instructions


I think nav stack usefulness could be increased if someone were to design a local planner more tailored to FRC. One that is less scared of collisions and one that operates at a faster rate. Perception space planning would be cool.