Gems of Wisdom
General
- Split up your work time in shifts. When possible, have 1-2 people work early mornings, 1-2 people work afternoons, and 1-2 people work evenings. This lets everyone get a chance to work on the robot without overcrowding and means your robot is being worked on 14-18 hours/day without any one member needing to put in too much time in one day.
- The field will always be very crowded at night, but is completely empty early in the morning. If you skip the late night work session and just turn it into an early morning session, you'll have the field completely to yourself for debugging.
- Getting your decision tree to work properly takes longer than you'd expect!
- Don't let your robot drive against the wall for too long while testing. Stalling the motors can cause them to burn out very quickly, which can be a pain to replace. Also not a bad idea to implement some motor stall-detection software that stops the motors if they've been stalling for too long!
- Do all your state charts in Lucidchart and keep them updated continuously throughout the project. It will give everyone an easy reference to pull up and edit on the fly as needed, and helps tremendously with debugging.
- Use good version-control for committing, branching, pushing, and merging. It makes it easy for everyone to work separately and test changes without breaking things on integration. It also retains all old files so if something breaks you can easily revert to see if the problem is from hardware or from software.
- Install uVision and TeraTerm on your laptop so you can quickly debug while using your robot on the field.
- Plan out your software infrastructure early and as a full team. It's more work up-front but will save you time later when integrating different modules.
- #Defines are your friend and your teammates will love you for using them in your code.
- Make your design easy to take apart so you can easily access circuits and swap out parts as needed.
- Start early on your mechanical design. It will save you lots of headaches later and give you a chance to see what does and doesn't work.
- If using an IR beacon, make sure you are using enough mechanical shielding of the sensor so that IR signals are only detected head-on.
- Don't use wheels that are too large. They will limit how slow you can go and will amplify any backlash from the motors, which can result in some angular error right at the beginning of a straight drive.
- Unthreaded spacers are a good way of separating different tiers to hold mechanical components and circuit boards. They make it really easy to take the robot apart or access a particular component.
- Label all your connectors thoroughly so that anyone on the team can connect the necessary wires, even if they didn't build the circuit.
- Be very careful when reading H-bridge datasheets. The provided H-bridges have an error flag EF, which is NOT an enable line EN. You can very easily burn out H-bridges if you treat this port as an enable line. Learned from experience!
- Using limits switches for contact-based sensing is very easy to implement and very robust.
- Create a different power switch for your motor power and your Tiva power. This lets you turn off the motors while still letting you work on the Tiva if needed.