Categories
Build Blog

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

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:

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

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.

Leave a Reply

Your email address will not be published. Required fields are marked *