paper: ZebROS 1.0: ROS for FRC

#1

Thread created automatically to discuss a document in CD-Media.

ZebROS 1.0: ROS for FRC
by: FalconWarriorrr

Bringing ROS to FRC, this whitepaper outlines the Zebracorns’ journey to using ROS for the entirety of our robot code.

In 2016, Team 900 wrote a neural network for detecting boulders. Last year, we implemented the Robot Operating System, ROS, into our vision code to facilitate communication between multiple processors. But this year, we’ve gone above and beyond what anyone thought we would be crazy enough to attempt. We transitioned our entire robot code – including hardware control – into ROS.

It wasn’t an easy transition – not only did we have to rewrite all of our code from the very basics of controlling motors to starting robot code automatically, but our problems were completely unique to FRC. Since we’re blazing a trail where no one one else has dared to go, we had to figure out most of our problems on our own without any specific resources. In this white paper, we explain why we did it, how we did it, and what we plan to do in the future. We hope to be a resource for any other teams crazy enough to try this out.

There’s no doubt that it’s been a difficult year, but many exciting things happened as well. We played back driver station data in real time to debug our different autonomous modes. We made huge strides with localization and mapping. We began integrating vision code with generated motion profiled paths. We’re looking forward to next year where we will do even more exciting things. Stay tuned!

Thank you to the entire team that worked tirelessly on the ROS transition and to our programming mentors Eric Blau and Kevin Jaget for their help throughout the competition season to surmount such a significant codebase transformation. Thank you to our mentors and fellow students for their help reviewing this paper. Finally, thank you to our sponsors for providing us with the resources that allowed us to make these groundbreaking leaps. We couldn’t do any of this without your continued support!

ZebROS1-0.pdf (12 MB)

Idiots guide to programming
#2

In 2016, Team 900 wrote a neural network for detecting boulders. Last year, we implemented the Robot Operating System, ROS, into our vision code to facilitate communication between multiple processors. But this year, we’ve gone above and beyond what anyone thought we would be crazy enough to attempt. We transitioned our entire robot code – including hardware control – into ROS.

It wasn’t an easy transition – not only did we have to rewrite all of our code from the very basics of controlling motors to starting robot code automatically, but our problems were completely unique to FRC. Since we’re blazing a trail where no one one else has dared to go, we had to figure out most of our problems on our own without any specific resources. In this white paper, we explain why we did it, how we did it, and what we plan to do in the future. We hope to be a resource for any other teams crazy enough to try this out.

There’s no doubt that it’s been a difficult year, but many exciting things happened as well. We played back driver station data in real time to debug our different autonomous modes. We made huge strides with localization and mapping. We began integrating vision code with generated motion profiled paths. We’re looking forward to next year where we will do even more exciting things. Stay tuned!

Thank you to the entire team that worked tirelessly on the ROS transition and to our programming mentors Eric Blau and Kevin Jaget for their help throughout the competition season to surmount such a significant codebase transformation. Thank you to our mentors and fellow students for their help reviewing this paper. Finally, thank you to our sponsors for providing us with the resources that allowed us to make these groundbreaking leaps. We couldn’t do any of this without your continued support!

#3



Bringing ROS to FRC, this whitepaper outlines the Zebracorns’ journey to using ROS for the entirety of our robot code.

In 2016, Team 900 wrote a neural network for detecting boulders. Last year, we implemented the Robot Operating System, ROS, into our vision code to facilitate communication between multiple processors. But this year, we’ve gone above and beyond what anyone thought we would be crazy enough to attempt. We transitioned our entire robot code – including hardware control – into ROS.

It wasn’t an easy transition – not only did we have to rewrite all of our code from the very basics of controlling motors to starting robot code automatically, but our problems were completely unique to FRC. Since we’re blazing a trail where no one one else has dared to go, we had to figure out most of our problems on our own without any specific resources. In this white paper, we explain why we did it, how we did it, and what we plan to do in the future. We hope to be a resource for any other teams crazy enough to try this out.

There’s no doubt that it’s been a difficult year, but many exciting things happened as well. We played back driver station data in real time to debug our different autonomous modes. We made huge strides with localization and mapping. We began integrating vision code with generated motion profiled paths. We’re looking forward to next year where we will do even more exciting things. Stay tuned!

Thank you to the entire team that worked tirelessly on the ROS transition and to our programming mentors Eric Blau and Kevin Jaget for their help throughout the competition season to surmount such a significant codebase transformation. Thank you to our mentors and fellow students for their help reviewing this paper. Finally, thank you to our sponsors for providing us with the resources that allowed us to make these groundbreaking leaps. We couldn’t do any of this without your continued support!

ZebROS1-0.pdf (12 MB)

WOOOOO! Very proud of all of you.

#4

There has been some discussion around the cost-benefit tradeoffs of using ROS for FRC. Living with it for the past year has given me some insight into the benefits. Note that none will be “free code for SLAM/autonomous path planning”.

  1. Breaking code into individual nodes is a big plus. Being able to drive each node individually from the command line is terrific for testing. This can be used for unit tests as well as for injecting commands to any point in a fully connected compute node. Plus it makes it way easier to have multiple coders collaborating without breaking stuff (but this might also be partly due to switching to Perl, uh, I mean C++).
  2. There’s existing code for how to do anything. That doesn’t mean that we’re just slapping other people’s code together, but if we need a way to communicate something, someone’s already figured out and implemented the right way to do it (or at least a good one).
  3. Pre-written command line tools to record, analyze and play back the entire state of a robot from a match has the potential to be huge. We’re still looking at the full benefits of this but it is great so far.
  4. This is kinda a sub bullet of 1, or forced by it : since code is broken into nodes, we only have to replace the hardware interface node with a simple simulator and can test the rest of stack as-is. It is so nice to be able to bring up robot code on a laptop and test 90%+ of everything without touching a robot.
  5. Moving code between processors is changing a config file and it just works. Communication between CPUs, coprocessors and so on is a solved problem.

Granted, a motivated team could code any of this. But getting it for free after (an admittedly impressive) investment in adapting to ROS is a nice benefit.

Most of this should be in more detail in the paper - read it already :slight_smile:

#5

Great work guys! This is one impressive paper. I’m excited to see what you all do next season.

#6

Speak of the devil - your name is in the paper. Along with some others…

#7

Regarding the starting scripts, was the robotCommand script just not running? I’d be interested in helping to figure that issue out, as it might help make the WPILib startup simpler as well.

#8

Legacy and/or blame. It is a fine line.

#9

Woot woot! It’s done! Thanks so much to Marshall, Kevin, Eric, Meg, Mason, and countless others for help reviewing the paper!

#10

Man I would love to figure this out too. I spent a week on this exact issue. Maybe it was just an issue with the way we hacked up our roboRIO because someone I was working with got it to work on their end, but no matter where I tried sticking the startup script it never got run.

#11

You have to execute this at least once to get it to run the robot command. RobotPy executes that anytime we deploy a new version of the code.


/usr/local/frc/bin/frcKillRobot.sh -t -r
#12

Our team got ROS up and running this past year and then for various reasons scraped it. One of the main reasons is the closed loop feedback and processing that the talons provide. We could not leverage that as intended. So until another day. Thanks for the update. You work is interesting and helpful.

#13

I will let the students respond to this but from an old-linux-dude standpoint, what I’d REALLY like to see is a simplified startup process that is basically a “FRC Teams using non-traditional stuff please put your startup scripts here”-Folder. Where each script is a name like 0-startMeFirst.sh, 1-startMeSecond.sh, 2-startMeThird.sh. And then those are all executed in the appropriate order with each returning a success/failure. This is similar to how init worked and granted, systemd has replaced it so maybe systemd is an option. Basically, I’d like the roboRIO to behave more like the linux system that it is(n’t).

I remember you contacting us a couple times early this season and getting an email forwarded from Omar I think. As I recall, you were using the ROS for LabVIEW implementation from Tufts. We have moved 100% away from LabVIEW at this point as we also found it a hindrance to making ROS behave like ROS. Hopefully our paper helps you out with getting it working down the road.

#14

There is a traditional init.d/rc.d folder on the RIO, and it works exactly as you would expect. I was actually quite surprised you tried to use robotCommand instead of this.

#15

LOL - as if I have anything to do with coding the robot. :wink:

Build season is a crazy time and the obvious solutions sometimes escape us. Probably worth digging into this.

Though, honestly, what we ended up with worked well for us.

#16

I appreciate the shout out. And hey now, I didn’t recommend switching everything to ROS in a year haha. Though, now that you have done it, next year should be really interesting!

#17

I like that the paper has about 150 downloads at this point and I can only surmise that almost all of them are from former Zebracorns based on the comments so far.

#18

I downloaded it. Read about 20 pages, at which point I was treading water not swimming. I appreciate the bleeding edge work, but I just didn’t see the payoff for FRC, at least right now. Maybe once the path is more sufficiently forged. My comment would just be that in a year or two, if things progress that way, that something akin to a getting started document, rather than a more documented paper, would be more inviting to step into ROS. Which I think they’d be people interested in introducing it to their students, even if they may not be using all the things that increase its worth (co-processors, certain sensors, etc). The last two years during outreach events I’ve had a robot hobbyist approach me and talk, and he asks me why we don’t program with ROS. I am glad to at least tell him that some teams do and then I try to convince him to come to our meetings (his kid is in 3rd grade, so maybe in a few years).

#19

Our team has been looking forward to the release of your white paper since it we first heard about it. The students had decided they wanted to combine the lidar, jetson, and ROS for an off-season project. We really had no idea where to start, or any experience with this these systems. Since your team was able to make these things work together, our students are even more motivated to work on this project.

I foresee many long nights and long weekends between now and January.

#20

The robotCommand script is only set up when you deploy code through Eclipse, which we didn’t use at all this season. And since we had nodes running on both the roboRIO and the Jetson, it was better to just use the network capabilities we had with ROS to launch all of those nodes from one central location – that is, the Jetson, which was easier to work with than the RIO anyway.