Does anyone use product/programming specs for FRC/FTC? If so, does anyone know of public examples? I’m interested in diving into them myself, and would love a “jumping off” point.
During the season, largely “no”. The most important piece of documentation is the whiteboard that Electrical and Programming share to track what stuff is on the robot, and where it’s plugged in.
Lots of secondary whiteboards too:
The rest is ad-hoc and communicated verbally in meetings.
This is somewhat intentional: ~6 weeks is way too short to go through a full, formal design process. Plus, the end product only needs to work for a few weeks (and will be handled with “kid gloves” by the development team the whole time, never shipped to a customer). While it’s certainly a good breeding ground to introduce topics in professional engineering, it’s not actually ideal to apply the real process.
That being said, two FRC relevant examples I can share:
Network Tables 4 is currently under development, and has a very good spec. It’s written in a way that is well-designed for consumption by the general public.
I’m currently working on an upgrade to our team’s on-robot development tool suite, and opted to start with a spec to get thoughts down on paper. It’s written in a way that’s much more “personal stream of consciousness”. Take it as an example of “what thoughts were important to one person at one time”, and an anti-example for “how to organize things in a way others can understand”.
A lot of that wraps back around to what the goal of the docs is. Making and maintaining documentation takes time, effort, and motivation. The doc end product has to be worth the effort put in. For something like NT4, which is designed to be public facing, absolutely makes sense to invest time and effort in maintaining that.
However, for our robot’s specific auto routine details for one year? eeeh. Probably not gonna see the payoff.
2 Likes
You probably need at least 7ghz to run the robot at 2fps on low graphics.
3 Likes
This is pretty much a style guide and I would change a lot if I were to rewrite it today. Not sure if this is what you had in mind.
1 Like
The best we do is to try and create a “Driver’s Manual” describing what controls map to what actions and detail what key things need to be displayed. We use the game to audit this and understand what actions we need from the robot to play the game.
It works well to understand what the minimal controls we need are, helps drive us towards command-based sequences rather than “one person band” sort of robots (where everything has a discrete control leaving everything to the operator to deal with) and helps us to bring key, actionable information up on the dashboard which impacts how the drive team can use the robot without cluttering the dash board up with what is essentially debugging info.
It helps the programming team to understand how sequences will get triggered and what we expect them to do.
We don’t go any deeper (mostly do to time and interest) but the value has been pretty high. It’s an in-progress effort…
Reading through the NT4 spec and your team’s dev tool suite, I’m starting to get deja-vu…
@marshall, how do you feel about the development of some sort of OS that standardizes communications between multiple processors on a robot? Like, some sort of Robot OS? Maybe we should call it ROS?
2 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.