Using the same software in multiple robots.

In order to solve the time honored problem of not having enough time with the finished robot to do anything meaningful, we have three RoboRios, one incorporated in the current years robot, one in last years robot and one on a special test bench setup. We don’t have spares in for all motor controllers and gyros, etc, so the sensors/actuators are slightly different on the robots. We are using GitHub to manage our development, but we just push and pull, nothing else.

The problem is that since the robots are different the robot’s java code wants to use things that aren’t there and it causes problems. The team members end up commenting out the code that is not applicable, but gratuitous commenting of blocks of code has become error prone and untenable.

I was hoping for some suggestions on how to solve this problem. One thought was to try and isolate differences in different classes that would be called based on a chooser in the drive station. Another was to use GIT branches. Does anyone else have this problem or have have any idea how to solve it?

^^^ this.

Alternatively, you can have switches on the robot (hooked up to the DIO ports of the RoboRio) that tell it which robot it is.

Another option is to put a file on the roborio that you read to find out which robot it is.

You can also have compile (build) time options that tell it which version to build. This has the added advantage of not bringing in code for devices that are not there. This can cause problems if the code for non-existent devices is accidentally run.

If I were doing it, i would put a switch on the robot. Code is exactly the same, and no one has to remember to do anything (chooser on the DS).

This is one of the reasons our team moved towards deserializing most of our object graph from a YAML file. Different robots run exactly the same code, just plumbed differently. If the application plumbing is represented in data rather than code, it is easier to change.

Of course, this is a fairly…involved…solution, and there are numerous ways to do similar things to a lesser (and probably more manageable, in your team’s context) extent. But the general idea of “migrate robot-specific structure to a more-quickly changing layer” is certainly one you should embrace if you’re looking to reuse code.