Over the last couple of weeks, I’ve been keeping an eye on the RoboSumo participants’ blogs and providing as much feedback as I can. Well done to those of you who have been updating regularly with details of your progress – I hope you’re finding that documenting your work provides a useful focus, but even if you’re finding it hard work, stick with it! If you haven’t been posting on your blog, it’s urgent that you start doing so, or you will lose a lot of marks.
I’ve found myself repeating a lot of the same feedback to different people, so I thought I’d post it here as general advice for everyone. In terms of assessment, what reaps the best reward is plenty of content about the following:
- The design and implementation of your robot, including plenty of technical detail.
- How you’re organising yourselves as a team, making team decisions and allocating individual tasks.
The best way to document how you’re organising your work within the team is to post minutes of your team meetings on your blog. That way, we can see that you’re contributing in this area.
The kind of things we see on high-scoring blogs are:
- Design sketches. These provide evidence that you contributed to your team’s brainstorming process by bringing original ideas. They can also show that your team considered multiple alternatives before settling on one design for the robot (or a part of it).
- Schematics of the robot’s physical design. These show that you carefully thought out the size and shape of the robot and manufactured it in a methodical way. Good drawings are crucial for clear communication within an engineering team. This is an opportunity for you to show us that you can produce professional quality schematics.
- Circuit diagrams. The biggest problem most teams have turns out to be getting their circuit right. However, many people can’t actually draw a diagram of their robot’s circuit when I ask them, which largely explains why they’re having problems. A clear and correct circuit diagram helps everyone on the team to understand exactly how the circuit should be laid out and makes collaborative fault finding possible. It also allows us (the RoboSumo tutors) to suggest corrections and improvements you can make. Finally, drawing a circuit really helps to clarify it in your own mind.
- Source code listings. Your team’s code inevitably goes through a lot of changes during periods of intensive robot development. However, it’s a good idea to publish a snapshot of it now and then, either when it’s working (for future reference if it stops working), or when you’re struggling with a persistent problem (one of the tutors will be able to read over it and possibly suggest a solution). Personally, I find that publishing my code on a blog encourages me to tidy up the indentation and comments. Neatly indented code is far easier to debug.
- Photos of the work you carried out. This provides excellent evidence of work you have carried out and it only takes a minute to snap and publish a photo.
- Videos of anything you get working. Again, this provides excellent evidence of things you’ve got working. Just in case things stop working on the day of the Race to the Wall or the RoboSumo tournament, a published video of your robot working provides an insurance policy of sorts for assessment purposes.
- Minutes of your team meetings. One of the best ways to show that your team is well organised and that everyone is contributing is to document your team meetings by taking minutes. It also encourages the team to make decisions that everyone is clear on and to assign tasks to individual team members in a way that ensures accountability. It’s best to take it in turns to record the minutes, so that everyone gets to practice it (it can be tricky to scribble down everything that’s discussed while the meeting is going on). Minutes are usually written in brief form (e.g. bullet points) and should include: Date/time/location of meeting, who attended, what was discussed (the agenda), who said what, what decisions were made, what tasks were assigned to each team member (action items).
Adding this kind of content to your blog will really increase the marks you get, not only in the documentation component, but probably also in the assessment components for individual contribution to the group process and design / implementation. Furthermore, the documentation will be much more useful to you and your teammates and we’ll be able to give better technical advice when you’re having problems.