Software as a Design Concern
by @Amicus1, software mentor
Robots are nothing without the software to control them – software is necessary for every bit of robot functionality and capability.
Unfortunately, far too often, software teams have to deal with design decisions that overlook their needs, which lead to unnecessary challenges during robot development.
However, achieving harmony between the design and software teams isn’t always straightforward. On NOMAD, we try to actively bridge that gap as much as possible. In fact, software capability is a decision factor early in the design process, and the needs of our controls team help guide us toward cohesive and controllable robots.
What is Cohesion?
For the purposes of this post:
Cohesion - the ability of various parts of the robot to smoothly coordinate to perform a task.
Usually, game piece handling is the task requiring the most cohesion between degrees of freedom. We don’t consider the 8 motors of swerve to be a cohesion challenge because it’s effectively a solved problem and not a concern for our design team.
Examples of designs with cohesion concerns
- Hand-offs that require one or both ends to be in a particular position. This relies on the position mechanism, is slightly complex to sequence efficiently, and is probably slow by comparison in practice when factoring in time needed to bring the mechanisms into alignment.
- Designs with potential physical interferences if controlled incorrectly. This can be an arm hitting the floor before its hardstop, or an elevator colliding with an intake, etc. The best case is that every mechanism can be driven through its whole range without interfering with other mechanisms doing the same.
- Designs with several necessary steps between receiving a game piece and being ready to score it. Though sometimes this is inevitable, generally, the more complex the sequence of touch-it/own-it/score-it, the trickier and slower the design will be to coordinate.
Cohesion is about the whole-robot integration. Even if you have perfectly controllable individual subsystems, an overall design with weak integration and coordination will struggle.
What is Controllability?
Generally speaking:
Controllability - the capability of each degree of freedom to achieve and maintain a given behavior quickly, precisely, and consistently.
Examples of designs with controllability concerns:
-
Mechanisms with significant backlash, flexibility, or feedback delay. If there is variation in the output that’s not being captured with feedback, the robot cannot account for it.
-
A fast but weak shooter pivot that struggles to handle the torques of shooter wheels spinning up or a game piece passing into the shooter. Example: our 2024 shooter pivot, where we had to strengthen the gearbox and the PID.
-
A pivot or elevator with too much mass being moved around, such that it’s hard to accurately and quickly position it. Example: our 2023 telescoping arm, especially with on-roboRIO motion profiling.
-
A pivot or elevator with too little mass being moved around, such that holding a game piece makes a significant difference in the mechanism dynamics.
-
A mechanism with mechanical resistance that is hard to model, such as an energy chain pulling a turret back toward a particular position Example: our 2022 turret, where the energy chain hung down and had to be lifted as the turret rotated.
-
A position mechanism where the encoder is too low-resolution to achieve the desired precision. Example: our 2024 shooter pivot needed an external encoder, since 18:1 and 42 counts per motor revolution only gave us about half-degree resolution.
There are many reasons why a mechanism might be hard to accurately tune, more than can be covered here. It is worth trying to eliminate well-understood issues early in the design process.
Before moving on, it is important to stress that cohesion and controllability issues in a concept are not deal-breakers. They must be balanced with the manufacturing and programming resources of the team. The issues must also be analyzed in the context of the game. If a given task does not require too much precision or consistency, perhaps a less controllable mechanism might be fine, especially if that mechanism works better for other requirements.
How We Prioritize Cohesion and Controllability
or, why programmers should do CAD review
We want to minimize risk and focus on design cohesion and controllability early in the design process, preferably before an archetype is even decided. One component of our approach to this is that our software lead and mentors evaluate each subsystem and archetype concept early in the CAD process.
Elements of the Review
-
Identify controllability and cohesion issues in the concepts.
-
Start a discussion about feedback for each mechanism (external encoder, zeroing, etc.)
-
Identify ways that a position mechanism could be reduced to a drive-to-hard-stop mechanism.
-
Evaluate the scoring sequence: steps and end conditions, independence of subsystems, additional sensors.
- Simpler scoring sequences are better for autonomous performance and make bare-minimum functionality less complex.
Scoring sequence example from 2024
We decided against an architecture like Unqualified Quokkas, with an arm that had to go down, intake, stop the note before the shooter wheels, raise the arm, and then shoot it. Though the Quokkas and many teams made it work, my reaction as a programmer was that this sequence is nontrivial to program for autonomous, even with note-path sensors. It also has mutual exclusion between being ready to intake and ready to shoot, since the whole arm has to move between those states. With the arm also used for climbing, it was geared for torque, not for speed. This is a case where cohesion is not about doing everything with one degree of freedom.
Instead, our desired balance of mechanical simplicity and performance led to a focus on separate mechanisms with straightforward coordination.
Our final design had more degrees of freedom than the Quokkas design, but was much simpler in sequencing in the most basic case: the shooter pivoted separately from the intake and could aim correctly as a default action, the intake could pivot down independently, and we simply spun up our wheels and ran every roller in our note path at near-max speed for the duration of our 4-close-note auto path.
We still ended up needing a note path sensor if we wanted to stop the note at the right spot (shown in the picture) before it went too far into the shooter. However, it was only a single beam break under the front fixed roller, and we were able to place it so that the note being just past the beam break meant the note was touching neither the intake rollers nor the shooter rollers, and both pivots were unobstructed. Our entire autonomous game piece handling was sequenced using only that sensor for detecting when the note had been received and when it was on its way to the shooter.
Conclusion
Creating a robot that operates efficiently and consistently on the field requires plenty of forethought. It is all too easy for designers to create something that is hard to control or coordinate, just because they are unaware of the needs and capabilities of the controls team. We address this by bringing our controls team leadership in early to make their needs known and to help the designers create a robot with a simple, efficient, and repeatable sequence of operation.
As a general takeaway, cohesion in design goes beyond controls feedback. If your team’s mentality is that the mechanical team just has to build whatever the CAD team designs, and the software team has to program whatever the mechanical team builds, and the drive team has to use whatever controls the software team designs, this is a recipe for struggle. Though we can’t fully reverse those relationships in the season timeline, it is best to consider each sub-team as a client for the previous one, not a customer. Communication across sub-teams is critical when creating something that meets everyone’s needs.
