Software-Hardware Mapping in a Robot Design

Pavol Jusko, David Obdrzalek, Tomas Petrusek

Faculty of Mathematics and Physics, Charles University, Prague

Malostranske namesti 25, 118 00 Praha 1, Czech Republic

Abstract. In this paper[1] we present a way how to change the design of a small robot for Eurobot contest from a design with a lot of hardcoded, hard to maintain and hard to extend functionality to a more universal design with much better maintainability and upgradability by use of software-hardware mapping. In the process, we show how the change of communication topology and software design rework helped to achieve the goal.
Keywords: autonomous robot design, layered software design, software-hardware mapping

1 Introduction

Autonomous robot design is a complex process covering many aspects and containing many decisions. This paper describes second-year experience of MART (Mat-phys Robot Team) – a student team based at Faculty of Mathematics and Physics (authors of this paper are MART members) [1].

Our team in its current composition took part in Eurobot autonomous robot contest [2] first in 2007. After this participation we carefully re-evaluated our design in the light of our experiences and observations gained during the work on our robot and during the contest itself.

In this paper, we present the way how we have changed the design and implementation of our robot to be more robust, scalable and simpler to maintain, upgrade and further develop. In our paper we focus on the mapping between hardware and software and leave aside other tasks like mechanical construction, high-level algorithms, overall robot “intelligence” and others.

2 Original Design

Our robot was designed for Eurobot 2007 contest as the first robot of a renewed team. It was build from scratch without reusing older pieces of hardware or previously written software. The core controlling part used standard PC based on mini-ITX motherboard with Linux operating system, and all mechanical parts were constructed on purely amateur level.

The task we were facing was to design simple, yet robust mechanism of message passing between sensors and effectors at physical layer and their corresponding hardware abstraction layer in the software. Our old hardware communicated using well known RS-232 interface, which is common on personal computers and is easy to program in POSIX environment. The first implementation connected all the peripherals to one microcontroller (MCU) which provided all communications with the PC using its internal serial communication module. To transfer the data, we developed a simple packet oriented protocol.

Since the number of peripherals increased, it became necessary to add another controller. Therefore we had to split the RS-232 link to multiple MCUs (using a simple hardware splitter), and start to use packet addressing. The packets were created in the main control program. Upon reception, the MCU firmware decomposed the packet, checked its consistency, took appropriate action, and sent back an answer message, which contained complex sensor information. Since the MCU response was obligatory and the format of such message was fixed (= full information from the sensors), it can be seen that the protocol complexity gradually raised to an unacceptable level and was no longer simple.


Fig. 1. Original communication design before (left) and after (right) adding new peripherals

As we mentioned above, we wanted to develop universal software for a universal robot which uses any kind of hardware. To achieve this, we decided to implement a layered design. The layers should separate used HW and higher logic of the robot. There were always doubts, how many layers do we need to cover this abstraction and yet not to suffer from too complex design. Too few layers would make the design messy; too many layers would make the design unnecessarily complicated. With this on mind, we have created 3 layers named ”Communication layer“, ”HW abstraction layer“ and ”Smart layer”. From top to bottom (see Fig. 2), the layer functions are:

-    The Communication layer handles the RS-232 link and takes care of the packet representation. Its name depicts the functionality from the topmost layer point of view and does not necessarily mean that actual communication with real hardware modules must be performed from this layer (as will be seen in Chapter 4).

-    The HW abstraction layer performs two main middle layer tasks: it controls the motors (and generally any actuator) and maintains localization data (and generally any other environmental data). To fulfil these tasks, it is composed of two objects, the Driver and the Localizer. The Driver object handles the motors by setting their speed and braking. It provides the interface to steer easily. The Localizer object reads the information from all devices which can help robot positioning. It computes the exact location and let other objects to read and exploit it.

-    The Smart layer contains, as the uppermost level, “The Brain” of our robot. The Brain is the most important part of this layer so, we usually use this name for simplicity to address the whole layer. The Brain itself is implemented as a finite state machine. It tries to achieve all the given objectives, drives the robot and takes care of all the other things which can happen around the robot and are significant for its work. This layer can also use any other peripherals connected by any other way than using our RS-232-based link, for example the USB-connected web-camera or a display.

Fig. 2. Original layered software design

The communication is the key of successful robot behaviour. For example, the Driver needs some information about the real speed of the wheels to correct the trajectory (e.g. when we want the robot to go straight but due to any reason it diverts slightly), or the Brain reads the position from the Localizer and gives orders to the Driver to achieve its high-level goals (e.g. to navigate to a specific place).

This design fulfilled its goal to be easily adjustable for other tasks. In 2007, we used the robot in two contests: Eurobot [2] and Robotour [3]. They both focus on autonomous mobile robots, but they differ a lot:

-    Eurobot is an indoor contest played on a relatively small playing field – a planar table 2x3m, Robotour is an outdoor contest taking place in a huge park with routes made of paver blocks and tarmac.

-    Robots in Eurobot contest must meet size limits (maximum height of 35 cm and perimeter of 120 cm). These restrictions do not apply in Robotour, but in this contest the robot can gain bonus point for the ability to carry a 5 kg ballast load, whereas Eurobot robots are not permitted to carry any unnecessary ballast at all.

-    During Eurobot contest, two robots compete on the playing field in a 90 sec match and must avoid collisions with the opponent; in Robotour, individual robots start for their 1km long journey in 5 minute intervals and usually travel without any interaction with other robots.

-    For navigation during Eurobot contest, the robot can use beacons placed on fixed position around the playing field, but there is no such equivalent in Robotour.

From the start, we designed our robot not to be limited exactly to Eurobot contest. We wanted to create a more flexible platform and it has proved that we have reached this goal. The necessary modifications needed for the robot to be able to switch between Eurobot and Robotour consisted of necessary changes to the traction and required almost no software modifications except the highest level application logic due to different overall contest setup.


In contrast with the fact the robot was successfully used in the two mentioned contests, we have realized severe drawbacks in our design of the hardware and the lowest software layer (Communication layer). Firstly the hardcoded solution of packet handling is not maintainable, nor expandable. For example, when we wanted to add a new peripherals (LED panel, compass etc.), we had to make a lot of changes in the protocol handler (the packet anatomy) and, worse, to make changes even in the hardware, namely to add a new MCU. Further, the use of RS-232 implies certain bitrate, which could cause unacceptably low data bandwidth (or latency) if higher number of devices is connected or if more data transfers are needed.

In our case, we were not able to enjoy the qualities of fast encoders because the maximum packet transfer rate would be exceeded. This situation did not have a solution without complete protocol change, for which we did not have time in the tight contest schedule.


The Eurobot contests rules are changing every year. Also, different contests have different rules and so need different robot implementations. To prepare the robot for a new contest edition or another contest at all, it is obvious the mechanical part of the robot need a change. We also wanted to develop and add new devices to improve the cognition and mobility of the robot and therefore changes in software were necessary too. We used this as an opportunity to improve the software design as well, and the next edition of Eurobot contest was the right impulse to start.

3 Hardware Changes

In order to address the disadvantages we removed the one-to-one concept and implemented new communication based on bus topology. The layered design allowed us to change quite a lot of hardware-related parts with only small changes to the software. We have chosen the well known I2C high speed bus [4] with SMBus-based packet protocol [5] as the new transport link. This allowed us to use full I2C high speed transfers while gaining from the SMBus protocol comfort. Our devices are connected to the computer using 3rd party USB to I2C bridge [6]. In Linux, the preprogrammed kernel I2C support allows its easy use (e.g. it handles packet transfers and performs the SMBus checksumming). On the application level, the I2C-connected devices are represented by regular files with regular read/write operations on those files. On the system level, the read/write I2C transfers are implemented using a set of callbacks which convert the binary application data to the SMBus protocol compliant packets and vice versa.

Fig. 3. New communication design

Fig. 4. Comparison of peripheral modules: new I2C version (top), old RS-232 version (bottom)

The individual modules for motor control were implemented as a “HBmotor board” (see Fig. 5 or reference [1]). The board consists of one MCU controlling the board main functions (Atmel AVR-based microcontroller, in our case), H-Bridge for motor power drive (standard MOSFET circuit driven by PWM - Pulse Width modulation) and interface for encoders and switches (digital inputs). The MCU firmware implements following tasks:

-    control of the H-Bridge operation: enable/disable rotation, direction and PWM signaling for motor rotation control

-    motor feedback: input from encoders giving odometry information for the control software

-    SMBus slave function for communication between the main control PC and this module.

Even the HBmotor board was designed for motor control, its MCU firmware is reusable for other sensor and effectors boards, for which purpose the hardware specific code must be changed but the core can remain unchanged.



Fig. 5. HBmotor board schematic diagram and photo of implemented board

4 Software Changes

Due to the new hardware design, the modules changed to be independently communicating with the PC. It allowed us to use this behaviour also in the object-oriented software design. The old packet handler called ”Bios“ in the Communication layer became unnecessary and was replaced by independent objects which represent real devices. These objects create a mapping between the software and the hardware. Consequently, more classes appeared at the HW abstraction layer. Their purpose is to provide more information for the Brain and also for other objects in the same layer to increase their power. The diagram (see Fig. 6) may now look bigger, but the design consists of bigger number of smaller independent modules whose size does not reflect code size (in fact, the total size of the code remained roughly the same).

To separate the physical layer implementation (in our case SMBus communication) from the upper level software, we have created Linux kernel modules for handling the devices. These modules use standard Linux virtual filesystem (sysfs) I2C implementation, which is based on directories and files: each directory represents one device and a file in a directory represents certain ability of the respective device. Our simple approach binds each file to one MCU SMBus register. This design decision separates the hardware implementation (MCU code, choosen bus technology etc.) from the application which uses this hardware. Besides other advantages, such approach easily allows different people to work on these separate parts (which was also the case of our team).

Every device is now handled by an object used for the communication (via read/write operation upon I2C interface files). The objects provide the interface to access all needed low-level device data from other objects. On the HW abstraction layer, new classes may be implemented to raise the functionality of the raw devices so that they can be considered “smarter” by the Brain or other objects in the HW abstraction layer. For example, such class could implement moving-average or a sample memory for a range-finder device which standardly provides only a single value representing the range finder actual measurement. Also, with the use of object-oriented programming methods it is now easy to use more devices of the same kind or of the same type origin as their software abstraction will be created using simple instantiation and inheritance.

After changing the communication to asynchronous model, straightforward implementation could easily lead to every single device being handled by a separate thread. However, for certain cases this is not the right way. For example, the encoder information from the two driving motors should be read synchronously to eliminate readout differences and jitter. Using independent threads, the load on the I2C bus could also cause unwanted harmful peaks because of the unpredictable process scheduling performed by the operating system. To better benefit from the asynchronous communication, we decided to implement a very simple scheduler instead of a completely new threading model. This scheduler helped us to shorten the waiting period between individual cycles of communication with a specific devices (e.g. motors with encoders, in our case via the HBmotor board). This decision lead to improved reaction time of the Driver and the information topicality in the Localizer (see Chapter 2).


As the communication is one of the most important issues to solve to reach the overall goals, we gave special attention to its design and implementation. At the same time with the completeness, we also aimed for simplicity. In our design, the layers communicate strictly with only adjacent layers in a standard way. From top to bottom, the process is following (see also Fig. 6):

-    The Brain is implemented as a finite state machine. It uses information from the HW abstraction layer to accomplish its top-level objectives – it reads the robot’s position by calling the Localizer (getPosition()) and guides the robot by giving orders to the Driver (gotoXY(position)).

-    The orders are propagated from the HW abstraction layer to the Communication layer by setting the right speed for each individual motor. The Driver receives the information about desired direction and the speed from the Brain and regulates the individual motors on each powered wheel using standard PID (proportional–integral–derivative) regulation. The PID regulation needs data from the motor encoders, which is provided by the Communication layer objects via the Localizer.

Fig. 6. New layered software design

-    Information needed by the Brain for navigation is provided by the Localizer and Range finder objects from the HW abstraction layer. These two objects encapsulate the individual modules information and thus the robot may be easily supplemented by new hardware providing nearly any other type of data. In such a case, the data for the Brain would be processed by the Localizer first and so can be of the same format as before.

-    Basic task for the objects in the Communication layer is to provide interface between the HW abstraction layer and the operating system Kernel modules (files). Here, the Scheduler takes care of balanced communication.

-    To reduce the unnecessary communication and to improve the reaction speed, we decided to implement certain simpler functionality in the (rather low positioned) Communication layer. This functionality can be depicted as a parallel to reflexes, which do not have to be controlled from the high level control modules. For example, without the need to process inputs and give orders by the Brain, the motors are able to work in a simple self-control mode. When the Brain switches the motor to this “goUntilBumper” mode, the motor (or precisely the instance of the motor object) takes care of the necessary action: using the set speed, the real motor is driven until its bumper (every HBmotor board is equipped with a bumper input) signalizes its activation. Then, the motor is automatically stopped and the information is propagated to upper layers. Such event can be used by the Brain for qualified decision about further robot activity. This approach seems to have a lot of benefits, because it is easily usable by higher layers and at the same time upper layer does not have to deal with it. Furthermore, such automatic reaction is immediate and is not burdened with communication between layers.

5 The Results

With the new design, the maintainability and upgradability of our robot improved a lot. To add any new device now we need only to:

1.   Attach it to the I2C bus and assure it can communicate using SMBus protocol.

2.   Provide the kernel module a function responsible for translation between SMBus-transferred data and their corresponding virtual data files for this device.

3.   Create a communication and logic class, which knows how to interpret the transferred data. This class may either provide the data “as is” or may perform quite complex data processing to simulate the device capabilities and thus increase its usability.

4.   Use the new module from the Smart layer of the software or from other device objects.


For the three first steps, we have prepared (and successfully used during work on our robot) basic prototype code which may be easily adapted with specific new device attributes:

1.   A MCU firmware prototype, which provides the SMBus functionality and leaves space for specific device handling .

2.   A stub kernel module, which transfers data written to the virtual file onto the I2C bus and data received from the I2C bus from its dedicated device into the virtual file buffer.

3.   A simple class, which encapsulates the file data and allows standard read / write operations. This class may be arbitrarily extended to provide more complex functionality as mentioned earlier.

(4. The fourth step is using the data in the highest layer which obviously cannot have a prototype implementation.)


During the depicted process, a lot of hardcoded stuff has been removed and replaced by new code which follows the proposed methods and design decisions. This code is simpler and easier to read and the new design allows improving the robot by adding new devices with only minimal effort needed.

It is now possible to add a wide variety of new devices, e.g. the infrared range-finder, acceleration meter, GPS receiver as new sensors, or new motors, tool handlers or other various actuators and manipulators. Even the change of the transport link from I2C with SMBus to other standard transport (e.g. CANopen) is easily possible. We plan to add such peripherals to our robot so that it can be used for new contest editions and even for other contests at all. Thanks to the new design, any such single change will not affect other parts of the robot or the software.

6 Conclusion

In our paper, we have shown a new design of a robot as a result of a change from a design with a lot of hardcoded, hard to maintain and hard to extend functionality to a more universal design with much better maintainability and upgradability. The new design has proven its qualities; it provides the functionality of the old design and at the same time it gives much better opportunities for the future.


The work was partly supported by the project 1ET100300419 of the Information Society Program of the National Research Program of the Czech Republic. As our work was part of a bigger team project, we would also like to thank other MART team members for cooperation, as well as people from Department of software engineering of Faculty of Mathematics and Physics, Charles University, Prague for their support.


1. Homepage of MART team:

2. Eurobot Autonomous robot contest:

3. Robotour competition:

4. I²C-bus specification:

5. System Management Bus (SMBus) Specification:

6. i2c-tiny-usb:


[1] The work was partly supported by the project 1ET100300419 of the Information Society Program of the National Research Program of the Czech Republic.