This method is really good for fetching errors. We currently use it to get motor faults and check if limit switches are pressed, update LED states, etc. It could be used for state-machines as well, but we haven’t really felt like there is an advantage for us to go that way just yet.
I used to try to emulate procedural robot code (what I had done in VEX) in FRC Command Subsystem. It (technically) worked, but I spent hours fighting the implications that Command Subsystem would have on my routines. If you are new to FRC, I might check out going with one of the other templates until you can learn Command Subsystem in the offseason. In my experience, structuring in Command Subsystem is very different from other languages that I was used to, so the adjustment time was fairly significant.
Since it is Week 6, I would try a simple project in some of the other ones, and do whatever you are most comfortable with. I have learned the hard way that trying to restructure your entire robot program this late into the season results in bad long-term effects, unless you are able to spent tons of time working on the project. We are having people on my team what they feel most comfortable with, and then I, along with two other students, are going to adopt it for Command Subsystem since there isn’t enough time for everyone to rethink how robot code is written.
I agree that enums are the way to go for things like various scoring heights. However, I would also write the subsystem API in terms of the enum. That is:
setHeight(ElevatorHeight.ScoreHi)
rather than:
setHeight(double)
The height (in inches, encoder clicks… whatever) is a property of the subsystem and may need to adjust multiple times during development. The subsystem should define the enum to encapsulate these values and the rest of the system should just know the enum values.
Steve
2 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.