FRC and ROS tutorials

Hey All,

My team currently is programming in C++ and we have been thinking of maybe trying ROS out. Are there any tutorials on combining ROS and FRC in terms of programming??


sigh Zebracorn Labs



So many tutorials and papers. Start with the first ZebROS paper and go from there. It’s been a long journey. There is also a ROSCon talk that we gave.

[email protected] for questions. We answer quite a few from other teams and are always happy to answer more.

1 Like

Could you please detail what the difference you guys are doing and what other teams like 624 are doing?

My understanding (admittedly from knowing your code) is that you are running ROS on the RoboRio so it acts as a node the same as your driver station and the TX2.

1 Like

FWIW, while ROS is an incredibly powerful tool, using it and training members in the basics might be more effort than it’s worth, especially if you don’t have mentors to teach it


From what I have seen, most of the other efforts to utilize ROS in FRC are also dependent on another service/protocol like NetworkTables to convey information from a co-processor or driver station back and forth to the roboRIO.

We actually started off this way too. What we quickly realized is that it wasn’t the “ROS way” of doing things. It can work but ultimately we felt like we were spending a lot of time fighting how ROS works instead of embracing it and seeing the benefits. Once we took the plunge and got it working on the roboRIO, things got easier and better for us. Now with that said…

This is very true. It’s not simple. It takes work and understanding and a lot of learning and teaching. ROS isn’t an Operating System in a traditional sense. It’s not Windows or Linux, though it does run on either. It’s basically middleware for robotics. That is what makes it so powerful and useful though.

The best metric I can provide to explain the benefit for us (and yes, we have mentors who support all of this, including myself) isn’t the number of awards or banners we have because of ROS. It’s not the number of sensors we have been able to utilize either, or the number of co-processors we can use or how easy it is for us to use those things. It’s the number of students each year we have actively contributing to the same code base. It fluctuates a bit but 10-15 students programming for our team in various capacities has been the norm for the past two or three seasons. The modular nature of ROS makes that possible.

1 Like

I’ve been working with ROS for the past week for a personal project and I’ve alternated between wanting to use this on every project I ever do going forwards and banging my head against a wall wondering why I brought this upon myself


So you’re saying you’re a software developer?

I tell people that software developers cycle between 2 extremes:

  1. I AM A GOD
  2. Why did they even hire me?

This cycle can happen multiple times a day.


Aside from the phenomena that @notmattlythgoe is describing, this also comes with learning any abstraction. At least that’s been my experience. Fight it at first, trying to replace/overcome existing knowledge and ideas and then eventually it clicks and the abstraction becomes a powerful tool that leads to more interesting developments.

1 Like

How do you find enough work for that many people? As an example, my FRC team assigns one student per mechanical subsystem (maybe two if the controls are especially difficult), so we usually cap out at six people doing useful work. That’s all we need to effectively implement our teleop and automation requirements, so it’s hard to keep additional people engaged. Does 900 compensate for the larger team by increasing development scope, and if so, what does that scope look like?

1 Like

A larger team is an asset than enables us to expand the scope of what we do. Systems for the current season’s robot are always the top priority during build season, but we also at any one time have several long term or R&D projects going on, and are constantly writing whitepapers to document what we do and share it with the broader FRC community. We try our best to have team members self-assign to projects that interest the most; that way, they are engaged and passionate about what they are working on. We encourage people to bring in others on projects. Having multiple people with different skills sets and experience levels allows students to learn from each other and fosters further innovation. One great example of the sort of thing we are able to do is a project that @yambati and I have been working on. We created a particle filter localization system using camera data (more details in our most recent paper Zebravision 7.0). This system does not directly interact with robot hardware, and it’s full potential will only be realized in future seasons by systems that are still in various stages of development. Having a large team of people focused on a mix of short term and long term goals enabled us to work on a project like this with no immediate reward but that will open up many possibilities in the future.

To coordinate this, we make use of ZenHub for project management, which allows us to keep track of where various projects are and which tasks need doing. We encourage student leadership at all levels. In addition to students acting as project managers and leading subteams, team members take initiative and leadership of the projects they are working on within or across subteams. Perhaps most important to facilitating what we do is our culture of peer-to-peer teaching. More experienced programmers help new team members become involved in projects, and students consult with each other, as well as mentors, about ideas and questions they have. This allows everyone on the team to benefit from the knowledge and expertise of everyone else. This way, new team members are able to more quickly become familiar with the tools we use, such as ROS, and begin to create and innovate.


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