Gems of Wisdom
Some thoughts about circuits:
Some thoughts about software:
- Take the time to think about board organization, layout and management of boards, connection options between boards, how you're going to test boards, when you're going to solder boards, how you're going to label boards and make sure EVERY member of the team knows which rail is power and which rail is ground. Especially at 4am.
- Get a power board (logic voltage and motor voltage, and common ground) soldered and bullet-proof as early as possible
- Make your boards accessible. Mount them right-side up so you can quickly and easily connect, disconnect, debug, and see what's going on
- Avoid soldering an IC directly into a protoboard - use DIP sockets
- Have a status LED on every. single. board. And have a contingency plan for when a board stops working as you expect it to.
- Protect against plugging in power to ground, and add components that will save you if (when) you do
- Get your circuits finalized and soldered onto protoboards as soon as possible.
- Spend the time and money early on to design a robust drive-train so navigation does not become problematic.
- Cut a first rev of your chassis as soon as you can (ie have the first design done in CAD asap) - you'll want at least a skeleton of your bot with which you can test navigation.
- Depending on how you spec your motors, definitely factor in the weight of your bot when designing. If a piece doesn't need to be solid, design cutouts and spaces or holes.
- Even if it's not essential for checkoff, it's nice to have a unique aspect of your mechanical design that you're extremely proud of. For the Golfer Bot, that was our shooting mechanism, which was spring-loaded and servo-actuated. In hindsight, we probably spent too much time on it, but it still turned out to be very successful in terms of functionality, and very cool in terms of bad-assery.
- If you don't have to buy something off of McMaster (it is available locally), try to pick it up yourself. Sometimes shipping on McMaster can be exorbitantly expensive (we had a $15 order become a $45 order because of a $30 shipping charge).
Some thoughts about software:
- Go through the hierarchical state machine framework early (review the prelectures and lecture notes), and know the relationships between
- Don't go crazy with complexity and nested state machines - your master state machine design shouldn't be more than two or three deep max
- Make your code as modular as possible - write libraries that take care of some of the functionality that is needed throughout your code
- Include public functions (such as query functions) in your various state machines that can help you share information between modules. Along those lines, think early on about what variables (i.e. status of the game, parameters related to your bot, current state of your bot) that you'll want to keep track of at a high level.