Tackling ROS2 in FRC to Leverage Open Source Robotics

Technical Programming
1

What is ROS

According to ros.org, “The Robot Operating System (ROS) is a set of software libraries and tools that help you build robot applications. From drivers to state-of-the-art algorithms, and with powerful developer tools, ROS has what you need for your next robotics project. And it’s all open source.” This is a pretty apt description because it doesn’t fall into the trap of describing what the core ROS code is. Because, at its core, ROS is a messaging framework for distributed applications. However, ROS’s libraries, tools, and open-source nature make it unique.

Note: When I say ROS, I am specifically referring to ROS2 (I am currently using ROS2 Jazzy)

Motivation

Seeing teams such as CyberKnights (195) and Zebracorns (900) successfully implement ROS on their competition robots inspired me to see what was possible with the open nature of the FRC control system. Teams continually struggle with the tight build, program, and test cycle in FRC. In an FRC season, you have barely six weeks to go from an idea of what the robot needs to accomplish to a fully functional, programmed, and tested robot. This is especially hard considering most teams don’t even have a built robot until near the end of these six weeks. I propose using ROS to lighten teams’ software load during the season.

Teams have continually tried to improve their simulation capabilities and implement newer and more advanced controls such as state space and linear quadratic regulators that Tyler Veness has added into WPILib and detailed in his awesome book (seriously it is amazing, if you are at all interested in control theory I highly recommend giving it a read here). But, over my time in FRC I have come to the opinion that teams dont need more advanced control algorithms or more complex simulations, they need tested and working control code. This means writing as little control code as possible which is slightly at odds with the current FRC paradigm where teams write their own robot code and sparingly use vendor dependencies for hardware interaction and path planning. This results in teams continually reimplementing the same exact code to control the realitvely few mechanisms that every team in FRC decides to deploy on their robot.

This is where I propose ROS comes into play, by leveraging the composable node architecture of ROS we can reuse code from previous robots simply by running an already written node, or we can use part of another teams code simply by pulling and running their nodes. Since all ROS nodes need to communicate through a distributed pub/sub architecture that automatically handles message serialization and message type code generation we can write generic interfaces between different parts of our robot control such that they can easily be swapped out for a different implementation or removed entirely.

Differences from previous implementations:

Looking at how teams have implemented ROS in the past there a few things that I would like to do differently in my approach:

  1. Simulation: Utilizing Gazebo to do full physics based robot simulation will allow many teams to program and validate their full control system including vision and sensing without a physical robot or field.

  2. Leveraging Open Soure: A major benefit of ROS is the massive breadth of open source nodes and packages such as ROS2_control, ROS2_controllers, MoveIt2, and Nav2. Utilizing these as much as possible will reduce the amount of reimplementation needed for every robot,

  3. Use ROS2_Control: Many of the previous implementations do not use ROS2_Control. I think this is a downside to some of the previous implementations, ROS2_Control allows for hard realtime control loops in ROS while not requiring you to write new controllers or hardware interfaces for each mechanism. By creating a set of hardware interfaces working with ROS2 Control for all the major FRC motors we can allow controlling motors from the ROS network directly through a CAN connection for the coprocessor or over a network connection between the coprocessor and the RoboRIO,

  4. Contributing to the Open Source Robotics Community: Many of the geometry and control algorithms integrated into WPILib that we all take for granted are much more advanced than what other robotics competitions and hobbyists have access to. By developing reusable ROS nodes that conform to the ROS standards, we would all be able to have a much greater impact on the community as a whole.

Current Implementation Plans:

Currently, I plan on implementing a set of hardware interfaces to communicate with the motor controllers that my team uses (Talon FX, Talon SRX, Spark Max) and the sensors we commonly use (CANCoder, Pigeon IMU, BeamBreaks). I also plan on implementing a Swerve Drive Controller, After that I plan on experimenting with using behavior trees as an alternative to command based architecture.

Current Progress:

I have started writing a Talon SRX hardware interface that talks to the RoboRIO over the network utilizing ZMQ and ProtoBuf (very heavily inspired by CyberKnights)

I have also started working on a simulated SwerveDrive to test the controller, kinematics, and odometry.

Goals and Timeline:

Goals for this project include:

  • Being able to write a full FRC robot in ROS before the 2025 season.

  • Running a ROS robot at Roboticon and Pirates Pillage offseason events

  • Creating a written and video tutorial series to bring the power of ROS to other teams in FRC and create better documentation for the open source robotics community in general

How to get involved:

This is a massive undertaking for one person so i would love some help. If you have a strong passion for robotics and programming I would love to talk to you. The best ways to contact me are this Chief Delphi thread for more general questions or comments, or my teams discord server. The link for the discord server is below and my name in the server is Henry. Please don’t hesitate to reach out or just join to hang with the awesome community we have in there.

My current plan is to make a post on CD about once a week detailing my current progress and starting to create tutorials for how you can get started on programming your own robots in ROS.

Note #2: Tyler Veness (@calcmogul) I would love to chat with you about the WPILib lie theory implementation of Swerve Drive Odometry.

8 Likes
2

The odometry classes use Pose2d.exp() to turn local chassis pose deltas into global pose deltas (derivation of exp() is in section 10.2 of Controls Engineering in FRC).

The drivetrain’s forward kinematics can turn wheel measurement deltas into a chassis delta.

3

I strongly agree, both in terms of what the existing opensource ROS community has to offer FRC teams and how underresourced teams can use it to collaborate and otherwise reuse code.

Like you i have also been experimenting with ROS2 for FRC. However, I took a slightly different approach and used network tables as a bridge between a linux coprocessor and the Roborio. The linux computer runs the ROS stack, while the roborio continues to function as the interface with the FMS and vendor harware. So far, i have reached a point where i have a ROS2 controller for a differential drivetrain with full ROS2 mapping and localization capabilities using a RP-Lidar (ncluding, sim capabilities).

It has been a few months since i worked on it, and i am traveling right now, but I will dust it off and try to post a link here when i get home.

2 Likes
4

Obviously I (we) have a lot of similar thoughts.

I think that if the community made some reusable components alot of the positive benefits you propose could be realized, especially if we had more developers involved.

Right now we (shamelessly) only really target our own use cases (re: motor controllers, hardware etc) but a lot of it could be relatively easily abstracted. If you run into any hurdles we’d be happy to consult. After some issues with the carrier board we were running a jetson on, we’re using an orange pi now as our ROS coprocessor and just got out of WVROX’s 33 matches this weekend without a ROS or hardware issue in sight.

1 Like
5

WPILib has discussed a ROS migration before because we’re essentially reinventing a monolithic version of ROS. The biggest hurdle we identified was setup. Distributed architectures like ROS are inherently more difficult to correctly configure than monolithic ones, and we have to cater to students who have never programmed or done sysadmin work before.

If that problem can be solved, ROS has a much better chance of widespread adoption.

4 Likes
6

ROS 2 has a capability for node “components” in C++ which allows a single process to run multiple nodes. This allows you to be more monolithic but then seamlessly abstract out nodes to other processes or processors later in development if a need arises

7

Part of my goal is to make it as easy to get involved in ROS as possible. Now I understand that it will always be harder than getting started with WPILib just due to the fact that you need to develop a distributed system and currently you need to handle all the deployment yourself.
Handling cross-platform development in ROS is also pretty difficult as they have very little macOS support and the windows support is a little sketchy. I am currently using WSL2 to do all my development in windows and managed to get GPU acceleration working so it is very smooth.
The first tutorial I make is going to cover getting your development environment set up in Windows and Linux.

Windows is also the only supported driver station client currently, but I do know people who do all their FRC development on macs because their driver station is not an ideal development computer

8

Based on WPILib’s installer download metrics, the vast majority of FRC programmers use Windows, so the experience there is most important. Currently, an FRC programmer laptop can be set up with one non-admin installer (if you install for the current user only). Imo, you should strive for that level of ease-of-installation as well.

The instructions on Installing ROS 2 on Windows — ROS 2 Documentation: Crystal documentation don’t sound too bad. Pretty much all the dependencies could be bundled instead of using chocolatey (which managed school machines can’t use anyway). Visual Studio would have to be installed separately like C++ teams do already for simulation. Making it required for Java teams to deploy any code would be new.

WSL2 is a non-starter imo. My FRC students used to use it, but it took way longer to set up than just using the WPILib installer and provided VS Code install. It also isn’t available to students using school laptops (not enabled by default, and no admin permissions to enable it).

3 Likes
9

Installing ROS itself on windows is not bad as long as you can use chocolatey, The problem is the nodes have to be developed for windows because the windows c++ compiler has different symbol visibility than gcc. Adding these visibility control headers make the code a lot more complicated to read which is why I started in wsl2. As long as you have admin on a windows computer wsl2 has become a breeze to install. It is two commands and then after that you have a fully setup fresh ubuntu image.

10

Yeah I don’t think wsl is practical either. For better or worse we use arm MacBooks for programming now, to avoid the cross compilation hurdles for our typical targets.

I do like that we use ROS for a large number of reasons, but it’s certainly not within putting distance of being ready for the typical FRC team.

11

i believe that widespread adoption of ROS will only happen once school CS curriculums come to approach it. C++ is not taught as widely as java, and requires more knowledge about how computers work rather than english syntax.

it is still definitely possible and I am also working to get ROS working for my team as well. feel free to contact me, ill work with you if you would like.

if there is one thing tho, do not make a black-box solution to this problem. limelight is an amazing product, but its closed-source software removes the learning opportunity.

12

But ROS2 100% supports python and because of the “nodes” structure you can use python team code and C++ libraries together.

13

is python really a good choice for robotics? for machine learning stuff it works well because its just calling underlying c/cpp libraries, but for core robot code, cpp is better

14

It depends. RobotPy is almost entirely just wrappers around C++ WPILib, but control flow is still Python’s performance weakness. Python 3.13 getting a JIT compiler will probably help.

15

Python is very popular in ROS because of the ease with which one can write a simple Node.
ROS Nodes can often be very simple, often processing a handful of topics and outputting 1 or 2 new ones, not interfacing with any direct hardware.
When you’re writing a lot of nodes like this, people tend to be drawn to python due to the lack of boilerplate.

16

You are right about C++ being better in robotics than Python. But for educational robotics, not so obvious. I have been coding since grade 9 and C++ is still difficult for me. Python on the other hand can be mastered within a month.

1 Like
17

One of the benefits is mixing Python and C++ (and technically any other language that can use a c shared library) but this is not as well supported in practice as it seems. Pluginlib which is what ROS2_Control uses to dynamically load hardware interfaces and controllers only supports C++. This means that any hard realtime code has to be written in C++ whereas your more high level nodes can be written in Python. But you still can’t write everything in Python

18

i guess it does depend on the specific use case. for FRC, high-speed, low-latency movement is a priority, so i think it makes more sense to avoid python. but when its the only option aside from learning a new CS curriculum, it makes sense (@catrix exactly)

19

As an engineer and hobbyist I love the idea of leveraging ROS2 and the open source community. The idea of contributing from FRC to the open source robotics community is also strongly appealing.

However, as a mentor I would be a little worried about the impact fully embracing ROS2 would have on new and low, or even medium, resource teams. The resource barrier to teams, especially new teams, is consistently rising. I think there is a place for ROS2 in FRC but I’d be worried about it raising the performance ceiling for high resource teams and raising the already high barrier to entry new and low resource teams.

On the other hand, robotics and the engineering fields will always be changing and the technology we use in FRC should reflect those changes.

2 Likes
20

The ability to mix and match has been wonderful for our team. Many of our high performance nodes are C++ and handled by more experienced students, while low performance nodes are often python and written by newer students.

For instance, our shooter_node, climber_node, and autonomous_node are all python, while our swerve_drivetrain_node, pheonixpro_control_node, and rio_control_node are all C++.

3 Likes