Thread created automatically to discuss a document in CD-Media.
An Approach to Robot Control by: SoftwareBug2.0
How to structure robot code for modularity and testability. Examples in C++ and Java.
This whitepaper describes a method of structuring robot code used in the FIRST Robotics Competition. Many sources give examples of how to get basic functionality working or how to use specific sensors but fewer have approached how to structure the system beyond splitting code by the physical components controlled. This paper is intended to be language-neutral but is aimed at teams who already have some basic level of proficiency in their chosen language.
I haven’t been on CD in awhile and didn’t see this, but it’s interesting to me.
Your paper appears to be very object-oriented-centric although the concepts themselves could be ported to other paradigms. Moving the block-diagram to the beginning might help with this, and switching from code snippets to more abstract figures and psudocode could help with readability. I honestly don’t know C++11 (I learned C++ before 11 and haven’t used it since), and I had to look up your note on the ‘auto’ keyword.
As to the overall architecture:
-Could the status block be removed, as the status-detail should contain all of the information and the method is usually a passthrough?
-Could the ready block be removed, and included in status-detail struct?
Regarding the block diagram: It might make some sense to move it earlier. If I do a new rev I also have a nice colorful picture that’s a little less detailed that I might do that with. I’m also thinking about adding a little more about the motivation.
To answer your questions:
-Yes, the Status block could be removed without any major effect. In fact, in our 2016 robot we only had one subsystem where they differed, and that was only in omitting one field.
-Regarding the ready block, it could not be moved into Status_detail without other changes. The Status and Status_detail are not dependant on the current goal, so they know what’s going on but not whether that’s the right thing. For example, a shooter’s status might be able to figure out that it’s going 2000 RPM. But it might be that some of the time you want to take a short shot at 1000 RPM and sometimes a long shot at 2000 RPM. So knowing exactly what the system is physically doing is not enough to deduce if it’s “ready”.