RP6 ROBOT SYSTEM - 5. Example Programs
At the beginning of the program, the transmit power of the ACS is set via the I²C bus.
In addition to the ACS, the program also reacts on the bumpers and on eventual RC5
transmissions from a IR remote control or from other robots.
All other sensors of the robot can be handled in a similar way.
Another detail of the program is the “heartbeat” display. The task_LCDHeartbeat()
function ensures that the character “*” flashes permanently at a frequency of 1Hz on
the LCD. This is useful to determine if the whole program crashed completely or if
only a certain part of the software is faulty. Once you write your own programs and it
seems to crash completely, this function might be useful to identify the error source.
A program crash can easily happen during the development.
Example 8: I²C Bus Interface – RP6 Master Library
Directory: <RP6Examples>\RP6_M256_WIFI_EXAMPLES\Example_08_I2CMaster\
File: RP6M256_08_I2CMaster.c
This program shows the use of the I2C bus master mode. The controller on the
main board of the robot must have loaded the I2C slave example program (RP6-
Base_I2CSlave.hex)!
As programs quickly become rather large and maybe even confusing for beginners,
the ready to use RP6 master library will be used now for I²C bus communication. This
has been reused mostly from the RP6-M32 module whose example programs show
how it works in more detail and goes through it step by step. This library has been de-
signed such that it can be used almost exactly as the normal RP6Lib for the controller
on the main board. Many functions and variables have the same name as in the
RP6Lib. This makes it easier to use parts of the programs for the RP6Lib with the
RP6M256Lib. Even the event handlers for ACS, IRCOM and bumper are available
again.
The I²C slave example program for the controller on the main board also contains a
software watchdog function that works similar to the heartbeat function but via the
I²C bus. If the master doesn't react within a determined time to an interrupt event
(by simply reading register 0), all systems in the base unit of the robot are switched
off and the program stops. And most importantly, the motors are turned off! Why do
we have to do this? Imagine the master controller sends the command to drive for-
wards at 10cm/s right before the software crashes, then the robot will continue to
move on even if collides with an obstacle. The watchdog stops the robot in such
cases. The software watchdog timer is normally deactivated. A command must be
sent via the I²C bus to activate the watchdog. It is also possible to configure the
watchdog in such a way that it triggers an interrupt event every 500ms in order to
check if the master controller is still alive. We will use this function in the next ex-
ample.
There are also event handlers for watchdog requests and low battery status.
The rest of the program is similar to example 7. The only new feature is the additional
watchdog timer whose requests will also appear on the LCD. Moreover all sensor re-
gisters are read and displayed via the serial interface. As before, ACS, bumper and
RC5 events are displayed.
- 46 -
