Firmware

Dieser Artikel ist in der englischen Sprache verfasst, um Teams auf der ganzen Welt einen Einblick in unser System zu geben.

Once the robot hardware and electronic components of the robot have been assembled, there’s still one piece missing to bring the robot to life: The firmware which determines the robots behavior. It processes the radio commands sent to the robot, controls the motors, triggers the kicking circuits and collects information about errors in different parts of the robot. These tasks are spread over the main-board, the motor-boards and the kicker-board. As this requires coordination among the boards, we use a shared CAN bus for communication.

The processing on each board is handled by either a STM32F407 or a STM32F303 microprocessor. Instead of reinventing the wheel and writing yet another embedded operating system, the firmware is implemented on top of ChibiOS. The latter is a tiny operating system for embedded devices that provides an abstraction for most low-level hardware details, thus easing the development significantly. Programming the boards requires additional tools: A JTAG connection between the robot and the developer’s computer is established by our JTAG-Programmer called ERPROG. The actual flashing procedure of the firmware is then carried out using OpenOCD, which also provides invaluable support for debugging the firmware directly on the robot.

We use a simple trick to ease the detection of problems: All boards are equipped with a „heartbeat“, a rhythmically blinking LED, that provides a visual hint whether the firmware runs properly. This is complemented with a LED to signal errors and further status LEDs on the main board. Each board also uses its microprocessor’s watchdog that resets a board whenever it becomes stuck, which in turn ensures that robots don’t get stuck on the playing field.

Main Board

The main-board is the central piece of the robot and unites a lot of different tasks:

  • Radio communication from and to the controlling computer
  • Providing commands for each individual motor board
  • Collecting errors from each board
  • Debugging support using a SD-card
  • Battery voltage monitoring

Motor Boards

Each motor-board „just“ controls its motor, which in fact requires a lot of work:

  • Measuring the motor current
  • Measuring the motor speed
  • Controlling the motor driver based on several control algorithms

Kicker Board

The kicker-board translates the kick commands sent by the strategy to actual ball kicks:

  • Detecting the ball using an IR break beam
  • Triggering the kicking circuits