Student Robotics is an exciting annual competition that challenges teams of 16–18 year-olds to build fully autonomous robots. Participating teams must design, build, and test their robots, ready to compete against other teams.

The organisation started out as an idea from a few students at the University of Southampton. Since then it has grown massively, and continues to attract students and schools from across the UK, France, and Germany.

All of what we achieve as an organisation is lead by our team of hard working volunteers. Volunteers have a wide range of different roles: mentoring competitors, writing software, solving engineering challenges, organising large events, public speaking, and many more are open to you. The most important role for our volunteers is mentoring; making sure that teams have a robot to compete with each year and getting them excited about robotics and engineering. As a mentor, you will be assigned a school and visit it as often as possible (usually on a weekly basis) to talk with the team and make sure everything is going to plan.

The idea of mentoring can be a little scary at first, but we aim to make you as comfortable as possible in your new role.

I expected it to be more like teaching, but it was more about supporting the teams, I think that’s a good idea because it doesn’t waste their time. — A new volunteer after first time mentoring

For your first few mentoring sessions, we always make sure that new volunteers are sent out with an experienced mentor as a tutor. The idea behind this is to let you watch how your tutor deals with situations and also let you ask them questions about mentoring in general. Your tutor will also help you to communicate with the school to agree meeting times and other details.

After you’ve been mentoring with your tutor for a few weeks, it’s time to fly the nest!

Starting on a more serious note, you should be aware that in the appendix, you will find an incident flow-chart, that you can use if you have to while mentoring a school.

Before you go mentoring, you must have a DBS check to make sure that you are able and suitable to work with children.

Many mentors are worried at first that they won't be very helpful as they don’t know all the answers… don’t be! The aim of the mentor is about helping teams find out the answers on their own. There is no need for you to memorise the rulebook or anything like that; you can look up queries with the competitors.

It’s important to let competitors figure out problems on their own; it’s not your job to fix everything. You should ask leading questions about how the build is going and nudge them in the right direction. For example, you can ask questions like “If you do that, what do you think will happen in this situation?”.

You should encourage the team to prototype, rather than discuss, ideas. Get them to split the build into small sub-goals and then attempt to achieve each of those goals one at a time. For example, start by getting the team to have the kit move a motor in a contolled manner and then get a moving chassis. Perhaps then start looking at getting a robot which moves in a straight line, then one that turns towards markers and then one that drives towards markers, etc.

Encourage your teams to use the forums as much as possible. This helps them to get to know other teams and our volunteers better, and even allows rival teams to help each other to build better robots.

As well as helping them code in our online IDE, make sure that the competitors are aware of the simulator that we provide them. It’s inevitable that teams will leave the programming until the end—when the robot is built—however, with the simulator they can get started on that right away.

Debugging is the methodical process of solving problems and removing bugs from software or hardware. Competitors will spend the majority of their time debugging their robots and it’s your job to help them through this process, although certainly not to know all the answers.

An important step in helping your team to debug is to let them tell you what they’re doing, and regularly. This works as an excellent strategy to find bugs. As the competitors explain what’s going on, they will end up thinking about it and spot any mistakes.

If the team are experencing problems with their robot, you could get them to build a minimal set up with only the required boards and peripherals plugged in to see if that makes a difference. If there is a specific problem with any of their boards, you should get in touch with another volunteer to sort that out.

We provide a troubleshooting section in our documentation that is ready for competitors to use. Pointing them towards this page is an excellent first step. Remember, mentors do not need to immediately know the answers. Helping competitors to find the answers by looking through our documentation is more useful to both the competitors and the mentor.

You should encourage your team to post any questions on the forums. This allows teams to communicate with other teams and volunteers from across the whole of Student Robotics.

Finally, it’s okay if you are unable to solve the problem yourself. There are plenty of other volunteers who would be more than happy to diagnose the problem and help you find a solution.

The best way of keeping up to date is by subscribing to the news and events mailing list. On this list, you will find newsletters, event announcements and other news.

Every fortnight, a newsletter is sent out, named SR(A)WN—Student Robotics (Almost) Weekly Newsletter. It contains information on what’s been happening over the past two weeks.

Any events that are happening near you will be announced on the mailing list a few days beforehand. This way you know exactly what’s going on, and you can choose to join in with activities you find interesting.

As well as mentoring, we offer a large range of other activities that volunteers might want to get involved in—after all, we do have a competition to run!

• For software developers, we have a large number of code repositories that you might be interested in getting stuck into and contributing your own ideas and concepts. We also have a code review platform powered by Gerrit that all volunteers have the ability to submit their feedback on.
• For electronics people, we develop all our custom boards in-house and would welcome any sort of input on how we could improve them for future kits.
• Moving away from software and hardware, we always need people who would be interested in helping to manage our events and organise people. Since the organisation has grown to span many parts of the country, we often run parallel events at different locations and they require a large amount of coordination.
• Communication is an important part of what we do, from writing documentation to filming and editing videos.

Generally, students who run the various branches will have weekly meetings (otherwise known as doings) which are a way of getting stuff done with lots of other volunteers. The reason they're known as doings instead of meetings is because a doing is where things get done, not just discussed.

To help manage everything that needs to be done, we have a project management system running, which is powered by Trac. We use the ticket facility for everything from recording if teams have broken equipment to organising who needs to do what at the competition.

If you’re familiar with the command line, we also havea number of useful tools for working with our budget system, our inventory system and a few other miscellaneous things.

We also have a few mailing lists on Google Groups that you may wish to subscribe to.

• General Happenings
• Development Discussions
• Game Decisions and Proposals
• News and Events

It’s worth noting that the mailing lists can be a little overwhelming at first, and they’re not necessarily useful to all volunteers.

As your spend more time with Student Robotics, you may find certain terms being used.

SR

Shortening of Student Robotics.

srobo

Another shortening of Student Robotics.

Branch

Student Robotics has a number of student branches, mostly based at universities, where certain events such as Kickstart or Tech Days are hosted.

Kickstart

The first event in the Student Robotics calendar, where we meet with the teams, supply the kit and announce the game.

Tech Day

Each branch will run two or three tech days over the Student Robotics year allowing teams to come in with their robot and spend a day working on it with the help and advice from volunteers.

Trac

A tool we use to help manage Student Robotics allowing us to keep a record of bugs or improvements and also providing a wiki.

Gerrit

A way of allowing lots of people to collaborate on some programming code by letting others review code before it gets submitted.

• Incident flow-chart