Honest question - why is there an effort to build custom solutions when there exist industry supported open source solutions that could be adapted?
Or, put another way, aside from sunk costs, what value does making WPILib look more and more like ROS have over ROS itself?
That’s something we’ve talked about on a number of occasions: “hmm, it kind of feels like we’re slowly reinventing ROS.” I would say that just adopting ROS has a number of barriers, namely that it is not particularly user-friendly in terms of learning curve, requires Linux knowledge to operate, and parts of our operating environment are not very ROS-friendly re: the way networking is set up with rate limits and WiFi small packet concerns, the fact the robot gets power cycled / rebooted frequently, etc.
The question is whether it’s better to take an evolutionary approach where we introduce concepts (e.g. pub/sub) from ROS while maintaining the familiar environment for teams, or throw everything out and try to build a more user-friendly wrapper around ROS? The latter might be more suited to a new project.
This has often been my big push for why ROS2 as a solution in FRC makes sense. It’s a massive set of wins for everyone.
ROS is typically used by academics and industry - but by spending our efforts to lower the barrier to entry this program could improve that.
ROS is used by industry - our students would get real experience using real tools
Yeah, I’ve made this exact comment a few times over the last 2 years.
The problem, as always, is resources. We barely have enough volunteer resources in WPILib to maintain and (slowly) evolve what we have. Building a student-friendly development environment for ROS is a big project, and we don’t have anyone on the team today standing up to take that on. However, there’s nothing stopping someone in the community from spearheading such a project and getting it into teams’ hands, and in a few years, assuming it grows in popularity (e.g. dozens of teams are using it), we can look at adopting it and making it official. As an example, I started RobotPy as an independent project over 10 years ago, it’s been maintained by others and used by dozens of teams each year, and we’re (finally) planning on making it official next year. GradleRIO went through a similar (but faster) adaptation cycle of independent development / team adoption over 2-3 years before we adopted it.
Thoughts on what a “Minimial viable product” might be for adoption and growth?
GradleRIO seems to mostly play in its own sandbox (IE, the team interaction is primarily the “I click a button, stuff happens, then there’s code on the RIO”). Python’s more in depth (fundamentally changes how teams do their coding, requires good authoritative examples and docs, etc.).
I’d sense a FRCRos implementation would be more like the latter - ultimately, teams need to see a one or more coprocessor images to flash (RIO, Pi, Jetson… more?), an installer that puts all the right development components in the right places on their PC, single-entrypoint “deploy” commands per node, and a good example project demonstrating distributed development?
Not that I need more side projects but… I like learning things. Also whenever ROS comes up my instant reaction is to think “Hey, this could be part of the roadmap when the RIO becomes something else and major hunks of wpilib have to be ripped up!” But also, per the resources discussion, that day scares me.
Edit: Thanks Joe for the thread split, it definitely needed it. For posterity - context was that a team did some excellent work proving out techniques for integrating ROS from a java context on the RIO. My line of thinking is toward the future, and what it takes to get this in front of more teams.
What I think a MVP needs to hit are:
The target user is a high school student with minimal to no mentor support. Simulation support probably isn’t needed for a MVP but as it’s likely a ROS selling point, it’s probably the next step.
I think the big challenges here are platform and automation related:
I think you hit the key pieces. Re: the RIO, just a note that it would need to not be a full custom image, but rather a one-time process to get the right components installed (similar to what we do for Java). Maybe if it was Rio 2 only it could be a custom image, but Rio 1 requires deployment to a running image, and there’s workflow issues that make a custom image challenging from a build/distribution perspective.
More broadly, there’s a pretty fundamental shift in thinking here from “single-threaded robot project with periodic loop” to “multiple processing nodes with message passing”. Do teams create one robot project with all the nodes, or is it a project per node? How do we teach message passing when students only have AP Java background? It’s a shift we can teach (after all, WPILib-based programming today has infrastructure and concepts teams don’t learn in AP Java), but it’s something to think about.
Also, API complexity is another thing to consider. NT4 added pub/sub APIs, but ~90% of teams still just do SmartDashboard.putNumber() to be able to see it on a dashboard / plot it. Can we make the actual ROS software stack that user friendly by layering on APIs?
https://docs.ros.org/en/crystal/Installation/macOS-Install-Binary.html
or Building ROS 2 on Windows — ROS 2 Documentation: Crystal documentation
No.
It’s no worse than the current state of things and the ability to leverage literally thousands of developers and their insights (along with searching for keywords for errors) makes it really really powerful.
Posting some responses for ROS2 based on personal experiments.
This is, honestly, a blocker. On windows and mac you are largely reliant on virtual machines. I spent several hours the other week fighting with a Docker instance doing bizarre things with networking so I couldn’t even get pub/sub working. (Though builds worked great)
Out of the box - no. With appropriate build rules in VSCode similar to how WPILib works (worked?) with GradleRio.
I know 900 has various scripts/configs that handle a lot of this. Otherwise it’s largely linux tools. I haven’t felt these were worse or better than the tools for figuring out what’s happening on the Rio currently.
I’m glad you brought this up. It was one of the key benefits I was seeing - a lot of SWE these days involves distributed systems and message passing. It is an extremely common paradigm in industry. Giving students exposure early is a leg up.
I also believe that with the advent of CommandBased we have a basis for how to layer abstractions around threading. These map passably to ROS concepts though the mapping is not 1:1.
Also, you can totally write an entire robot as a single node if you wanted to. I don’t suggest it but you could. And you’d still get all the simulation/logging benefits of ROS. As weird as it is - I almost think this might be an improvement for lower resource teams from certain perspectives.
APIs and tools - and yes I believe so. As mentioned, many of the modern FRC Programming approaches map to ROS concepts.
looked through the behaviors folder of your repo. It’s pretty understandable but there’s lots of boilerplate. Especially to get beginners to understand their code, I think ROS would have to have a small wrapper that abstracts away some of the manual ros::ok and message parsing / creation. If students get to an advanced enough level, they can delve into doing it themselves but it should be hidden away by default.
An example for those following along at home and not familiar with the 900 repos.
Keep in mind - Actions are a space that received some iteration from ROS to ROS2 (or at least there was a delay in moving them over)
YMMV… look… I’m not the one pushing this. I’ve given up. We know the benefits. We live them. Others can do what they want.
Can we take this to mean you have not found the boilerplate to be onerous?
(Personally, looking at it just seems like a sane normal amount of boilerplate around C++)
We’re still using it… been using it since the 2017 season. It hasn’t always been easy but we don’t have any plans to change.
I do really like the auto balance behavior as a simpler example: 2022RobotCode/2023_balancing_server.py at master · FRC900/2022RobotCode · GitHub
But, where are the state transitions located in code?
# we only actually care about two states, the one with no wheels and all the rest as one state
The only states used are ONE_WHEEL_ON_RAMP and NO_WEELS_ON so the chunk starting at 108 is the relevant section.
Hi! I wrote this code. The version on our 2022 repo was out of date, and only worked if we were already on the charging station as it just ran pid on pitch to balance. I updated it to what we use now for balancing. The other purpose of that code was to use to test our balancing physics sim which was pretty useful before for testing (exact same code to control sim and real life). The actual balancing code isn’t too interesting, just drive up until we see an angle increase and then run pid on pitch.
The more interesting part is about how we use actionlib to structure our code. We essentially stack actionlib servers from lowest level to highest level functionality, and then call those servers in our teleop node. We have a naming convention of -er for lowest level actionlib, then -ing. So we had a shooter and shooting server. For us it makes a lot of sense in how our code communicates, as there is feedback/success and we know when for example we have finished shooting or our 50% there or whatever. I don’t really know how normal WPIlib code “talks” (only a sophomore and have only been on 900) with each other so I don’t really know how it compares, but today our structure has ended up being super useful, we changed our align to grid method, and just swapped out the messages in our higher level align and place server and it just works.
This is where my mind went to.
The everybot bots that just need ~10 lines of code to get up and running should stick at 10 lines of code. Meaning the default project just tosses everything in one node. If that’s all you ever need, you write your code as you do today and go on your merry way.
As teams start to expand and need features and move along the learning path, at some point, the documentation drops the knowledge bomb that “hey, actually, this is a ROS node”. Then let the scope grow from there.
See post above from the author. 
I think having NetworkTables run alongside ROS makes sense. Keeping NetworkTables allows FIRST to have complete engineering control on its feature set. ROS is tailoring to a much different and broader audience. If they decide to go in a different direction like they did for ROS2, WPI would be forced to work with legacy code or rewrite the whole system. Keeping NetworkTables as the primary network protocol for FIRST allows for a software release cycle at the pace of FIRST seasons. When WPI feels its time to add new features like pub/sub or possible integrations with tools like ROS, they can do so while keeping the original requirements of simplicity (i.e. SmartDashboard.putNumber).
What I really appreciate about WPILib is that, while many of its features are tuned with FIRST games in mind, it’s flexible to being run on other hardware or being extendable to other features. Similarly ROS is the ticket to many powerful robotics tools. Every software domain has its own set of tools, some of which have repeated functionality. I think that’s fine as long as the bridges that connect them work well. Take rosbridge for example. It allows developers to forward ROS message to various web tools. I’m sure there is some repeated work between web development and ROS (message serialization, simulation, graphical tool frameworks, etc), but each has a variation that suits the target audience. And when you need both, rosbridge allows you to use both.
From the perspective of what makes sense as a leg up into industry, I’ve seen several robotics companies use ROS as a secondary messaging protocol. Its tools for simulation and data playback are super powerful, but in many cases, companies can’t fully commit to using it since the release cycle and feature set of ROS is out of their control, its message/topic structure is not suited for the product their making, or they need to maintain legacy customers. So, learning WPILib as the primary framework and ROS as secondary actually closely models what’s done in industry in my experience.
If I could ask for one change to WPILib, it would be to have the bare bones message generation and ROS communication features officially supported. Whether that’s through NetworkTables or patching in ros_comm, I’m not sure what’s best. Essentially, what I showed in my original rosjava post but as an integrated tool in VS Code and not based on deprecated libraries.