Project Planning/Management
- Scope the project well. Aim for simple mechanical / electrical subsystems with freedom to build on them later. Leave the complexity to the software so you can make the robot "smarter" and more robust.
- Make sure to spend a lot of time planning out all aspects of the design early on. You want to have a solid design and a solid strategy before you begin prototyping and developing the mechanical aspects. Commit to your strategy to avoid going back and forth on your design.
- Communicate with your teammates well. Make sure EVERYBODY is on the same page. Get to know all the aspects on the robot so you can have four heads debugging the issue instead of relying on one "master".
- Keep good documentation. This allows for all team members to know what TIVA ports are being used, which timers/ interrupts are free, what the various modules / SMs are built, etc. Reduces hardware / software debugging which is essentially the biggest time consumer of this project.
- Use LucidCharts to develop block diagrams for the software, power distribution, and overall system. Easily conveys what is going on in the robot and each team member can easily check.
- Constantly update documentation. It is easy to get lazy later on in the project and ignore documentation whilst making changes. Do not make that mistake. Everyone needs to be on the same page. We figured out that we were using the same timer interrupt for different functions because we could catch the error through our documentation.
- Work in parallel and integrate constantly. Design a new software piece in parallel and integrate as soon as possible to avoid any conflicts / reduce debugging time. Develop the software / hardware for a component in parallel and then integrate and test as standalone system. Doing so will allow you to integrate EVERYTHING together later on with minimal debugging.
- Checkoffs don't really matter: Although the checkoffs do count towards your grade, slapping on some code just to make things work for checkoff is a TERRIBLE idea and a waste of time! Checkoffs are designed only to keep you on track. We stuck to a timeline that ensured that our robot was able to carry out all the necessary functions 1-2 days before final grading, with team-defined milestones.
Coding
- Use Sourcetree to effectively build code. Making sure you learn how to use it properly will most efficiently help the team build the software. You should never be iterating in the master, make branches and only merge in code when it is tested and proven to work, and even then only merge if others from your team are nearby to help with potential merge conflicts.
- Keep an eye out for merge conflicts. Especially in ES_Configure.h, sometimes Sourcetree with replace something without you noticing, which can cause hours of debugging headaches. Timers seem to be especially in danger of silent changes.
- Keep track of ISRs. It's easy to lose track of what interrupts you have, and how they're being utilized. Make sure that your interrupts are as short as possible and that you're setting the correct priorities. Also, take special care when your ISR's are modifying variables that other parts of your program are also modifying. Also be wary of reading from hardware pins on an ISR if you're also reading them from somewhere else in the program.
- Reading from the A/D converter: Make sure that you read from the A/D converter only in one location in your entire project. If the A/D reading is queried more than once within a certain time period i.e. when the previous query is still in progress, the A/D will give you garbage readings! We had both a service and an ISR querying the same values from the A/D sensors at different time rates so it messed up our readings when the queries were too close.
- Developing State Machines: Develop your state machine independent of the hardware and check its behaviour by passing keyboard events. This is a super clean way to do it. Keeping adding states to manage edge cases as the robot will definitely encounter them during checkoff/competition. Eg: Manage collisions, failed line-following, failed navigation, etc.
- Debugging is a pain. The vast majority of the project is spent debugging some subsystem. Making sure you adhere to these tips: focusing on the mundane little things, communicating with each other often, keeping good documentation / updating frequently, integrating software/hardware early and often, scoping your project well.... Our team won the competition not because we had the greatest ball collecting mechanism, or the fastest robot. It was because we scoped the robot well, were able to build a functioning robot early on, and spent the last week or so optimizing our software so we could reliably carry out our strategy.
Mechanical/Electrical Design
- Spend extra time on the little things. Make sure you have a convention for wiring, take time to make sure all solder connections are solid, carefully wire the robot when assembling, etc. These aspects are tedious but the extra few minutes you put in now will save you hours and hours in debugging later on.
- Soldering on Perfboard: Make sure that your perfboard circuit is functioning and does not have any "bad" solder connections before installation. It can be a huge pain to debug hardware while it is mounted on your robot. Start early with soldering your TIVA signal distribution board and make sure you add access to extra pins so that you can add hardware if necessary later on. Spend some time practising how to solder on perfboard (especially bridging) before you move to your actual circuits. Blackboard is a great open-source software that you can use for perfboard circuit design.
- Make sure you correctly install a new TIVA. If you break a TIVA and get a new one, make sure the TAs remove the correct resistors and snip the switch pins. We spent 12 hours debugging our code because we did not correctly install the new TIVA.
- Keep wire routing in mind when designing your robot. Cleanly wiring will save you debugging headaches and will make your robot look much more polished. Allow for more space than you think you need in your mechanical design to route your wires throughout your robot, and add as many holes as you can for your wires up front, so that you don't have to hand drill them later on.
- Make sure your robot is easy to assemble and disassemble. Use non-permanent fasteners wherever you can. Avoid using epoxy or glue for the chassis of your robot, since it will be difficult/impossible to access the inside of your robot if something goes wrong.
- Don't make mounting electronics an afterthought. Important components such as the TIVA and power distribution board should be mounted so that they can be easily accessed for debugging. Place as many circuits as you can on the outside perimeter of the robot to avoid disassembling your robot to get to them.