Tons! However, we’ve done a lot of work to resolve them - specifically working with NI and wpilib contributors to help get some changes on the RIO, as well as working with HQ on rules changes to help us and other teams. We actually run most of our control through the Jetson via a SocketCAN adapter, so the Jetson controls the motors directly with enable/disable coming from the RIO, the exception being the pneumatics controller at the moment.
For us, the struggle was real in the beginning but the benefits of being able to use so many of the ROS command line tools, bring up nodes on separate systems at will, and leverage so many more features have been worth it. I can’t say it hasn’t been a struggle though and there were some key architecture choices we made early that I think have helped us as things have changed. Definitely check out the original ROSCon talk and the older white papers as we explain some of that - as well as the epiphany that we arrived at trying to use LV to talk to ROS.
Not a clue. Probably not without modification. I haven’t touched Java on an FRC robot in quite some time so I’m not sure how the ROS Java implementation works at all but I’m sure it exists. I think the main thing to understand is that it isn’t “wpilib or ROS” but “wpilib and ROS” - I think it’s a huge testament to how well written the core wpilib functions are that we can utilize them and layer in the additional functionality that we find helpful. That flexibility isn’t accidentally coded, it’s intentional, and should be applauded.
ROS is effectively middleware for robots and it’s quaint to see that as “just plumbing”, particularly for higher level sensor systems where you see a lot of the research being done and demos aplenty…. but the abstractions it provides work at lower levels too. I don’t want to minimize the work done but the ROS control boilerplate and wpilib combine to form an impressive team.