S-Trike: A Mobile Robot Platform for Higher Education

Tobias Schubert Jan Burchard Matthias Sauer Bernd Becker Chair of Computer Architecture, Institute of Computer Science, Faculty of Engineering Albert-Ludwigs-University of Freiburg, 79110 Freiburg, Germany {schubert, burcharj, sauerm, becker}@informatik.uni-freiburg.de
Abstract
This paper introduces S-Trike, a mobile robot for student education at university level. Build around a robot chassis, our S-Trike equipped with an FPGA, a microcontroller, and multiple sensors, oers students a large amount of diversied possibilities: A turn-rate sensor can be used to turn the robot a certain amount of degrees, three ultrasonic sensors allow it to navigate around obstacles, and a Bluetooth module can be used to connect it to a mobile phone, just to name only a few examples. One of the main advantages of our approach is that the various components are not hard-wired to each other. Instead, the students have to take care about the entire design ow, starting from connecting sensors and actuators to the FPGA and/or the microcontroller using jumper wires, and then implementing appropriate functions to receive sensor data, to process the data, and nally to control the actuators. The positive feedback we received from students after introducing a total of 50 S-Trike robots during the summer term 2012 clearly demonstrates the success of our approach. which may be simple ip-ops or even complete blocks of RAM. Usually, FPGAs are programmed/congured using hardware description languages like VHDL or Verilog, both of which dier substantially from software programming languages and require at least a basic understanding of the underlying hardware. Compared to the number of microprocesser-based robots the number of mobile robots using FPGAs available on the market is far less [3, 14]. This paper presents S-Trike, a mobile robot platform for higher education at university level, which was rst introduced to students during the summer term 2012. Utilizing both, an FPGA and a microcontroller, it oers a much broader range of experiments than classical educational mobile robots like for example the wellknown Lego Mindstorms sytem [8]. The main advantages of our approach are exibility and high performance at an aordable price: Flexibility, because none of the sensors or actuators are xed in hardware, but can be connected to either the FPGA or the microcontroller by using jumper wires. This architecture allows us to start with simple experiments, using the easyto-understand microcontroller only (ts perfectly for students without any prior knowledge), then switching to the more complex but also more powerful FPGA as the robots control unit, and nally end up with more sophisticated experiments integrating both the FPGA and the microcontroller together. In the last case, the students have to implement at least a simple communication protocol to be able to exchange data between the FPGA and the microcontroller. High performance at an aordable price. While S-Trikes microcontroller provides enough capabilities for quite a number of applications (wrt. clock frequency, I/O pins, and memory), the FPGA is even more powerful (50 MHz clock frequency, about 80 I/O-Pins, 32 MB memory), making it the rst choice when developing complex tasks. Furthermore, compared to simple microcontrollers FPGAs allow dierent tasks to be executed in parallel, providing real concurrency. By using as many standard components as possible, we have been able to keep the price of a single S-Trike robot at about 420 euro.

Introduction

At universities, mobile robots are a promising way to get (undergraduate) students hooked on many aspects of computer science, e.g. in the area of embedded systems engineering. There are many robotic systems available, oering an easy to learn introduction into the world of computers and programming. Most products are based on a microcontroller as its control unit [2, 4, 6, 8]. Mobile robots controlled by microcontrollers are often easy to program, even without a deeper understanding of the underlying hardware. As an alternative to microcontrollers, so-called Field Programmable Gate Arrays (FPGAs) have become more and more popular in both, industry and academia within the last years. FPGAs are integrated circuits designed to be congured by the user after manufacturing and contain programmable logic components called logic blocks. A hierarchy of recongurable interconnects allows the blocks to be wired together in dierent congurations. The logic blocks can be congured to perform complex combinational functions, or merely simple logic gates like AND and XOR. In most FPGAs, the logic blocks also include memory elements,

The remainder of the paper is structured as follows: Section 2 introduces the hardware of our S-Trike robot in more detail. Afterwards, Section 3 presents dierent scenarios and projects that can be realized on S-Trike. In Section 4, an overview on how the S-Trike robot is used for teaching purposes at the University of Freiburg is given. Section 5 summarizes the paper and briey discusses future work.

Hardware

As can be seen in Figure 1 the S-Trike is build around the Parallax Stingray robot chassis [9]. A total of ve custom circuit boards are placed on and in the chassis: One large Printed Circuit Board (PCB) is used for motor control (placed within the chassis), a second one is used as the experimentation board (on top of the chassis), and three small PCBs contain the ultrasonic sensors (mounted at the front of the robot). Apart from these PCBs, all sensors and controllers are standard components and used as they are.

to access power switch has been added to the back of the chassis. It is integrated directly into the positive power line from the battery. In addition to the two main circuit boards described in Sections 2.1 and 2.2, three ultrasonic sensors are mounted at the front of the robot. They are able to detect obstacles within a range of four meters [5]. The entire hardware has been designed in a modular fashion: All major components are plugged into one of the two large PCBs and can be removed if they are not needed. The experimentation board features four additional servo connectors, in case the robot is extended or the board is mounted onto another chassis which uses servos. The overall schematic of our S-Trike is shown in Figure 2, further demonstrating the modularity of our approach. Around the two controllers (namely the FPGA and the microcontroller) the various sensors and actuators have been arranged in such a way, that they can be attached to both the FPGA and the microcontroller. As a result, the S-Trike can also be run with just one of the two controllers. Additionally, the design makes it quite easy to integrate new components (e.g. a front camera). The only work that has to be done is to provide an appropriate interface so that the new module can be connected to the controllers with jumper wires.

Figure 1: A fully equipped S-Trike robot. Three ultrasonic sensors are attached to the front, while the experimentation board is mounted on top of the chassis. A 7.2V battery pack, two DC motors (one for each wheel) and the motor control board are located within the chassis. Including sensors, the robot has a length of about 36cm and a width of 28cm (from wheel to wheel). Since S-Trikes main purpose is student education, additional safety measures have been integrated into both main circuit boards: The motor voltage can be lowered from 7.2V (battery pack voltage) to 5.0V, which results in a slower robot. Additionally, there exists no direct connection from the battery to the experimentation board. As a result, the total power available on the board on top of the robot is limited by a 3.3V voltage regulator. Furthermore, all connectors are reverse polarity protected. For power control, a large and easy

Figure 2: Schematic of S-Trike. All components connected to the Controllers box are available to both the FPGA and the microcontroller.

2.1

Motor Control Board

The motor control board, located within the chassis, serves two main purposes: It contains voltage regulators, which supply 3.3V and 5.0V to all sensors and the experimentation board. Additionally, it contains the transistors for full forward and backward rotation of the two motors. These transistors form a typical H-bridge which can be used to easily rotate a DC motor backwards and forwards. The motor speed is then regulated by Pulse Width Modulation (PWM) on the corresponding control signal. Additionally, a hall eect based current sensor and a voltage divider are integrated onto the motor control board. The voltage divider allows reading the battery

voltage through one of the 3.3V analog to digital (A/D) converters on the FPGA or on the microcontroller by dividing the battery voltage by three1 . Finally, the three ultrasonic sensors are connected to the motor control board, too, while a single 16 lead ribbon cable connects the experimentation with the motor control board.

2.2

Experimentation Board

The experimentation board (see Figure 3) is mounted on top of the chassis. Its main components are a microcontroller, an FPGA, an LCD, a Bluetooth module, a turn rate sensor, several push-buttons, a speaker, and an array of LEDs. All active components are connected to the required supply voltage on the board. However, to use a specic component, the remaining connections (i.e. the control signals) have to be placed by hand, using wires to connect the female sockets next to each module. In the middle of the experimentation board a breadboard has been integrated to be able to handle additional electronic parts, further increasing the exibility of our approach.

ponents of our S-Trike. For the microcontroller we make use of an Arduino Pro Mini based on the ATmega328 microcontroller [12]. The popularity of the Arduino project spawned numerous projects, resulting in libraries for servo and DC motor control, for writing text on an LCD, and for sound output, to name just a few [10]. Combined with a high-level programming language similar to C++, it allows students to execute their rst projects within minutes. To program the microcontroller, a small USB to serial converter can be attached to the experimentation board. The ArduinoIDE then compiles and transmits the programs directly to the chips ash memory. An Altera Cyclone IV FPGA mounted on a Terasic DE0-Nano experimentation board forms the basis for all FPGA related experiments [13]. In addition to the sensors on the experimentation board given in Figure 3, the FPGA board itself consists of eight LEDs, two pushbuttons, and a 3-axis accelerometer (all of them are therefore only available to the FPGA). The DE0-nano also features an integrated USB-Port for programming and debugging purposes. To program the FPGA, a free version of the Quartus II IDE can be downloaded from the Altera website [1]. Compared to the Arduino microcontroller, the Cyclone IV FPGA provides signicantly more I/O pins, more on-chip memory, and more computing power, making it the rst choice when implementing complex tasks, while the microcontroller perfectly ts for rst experiments in the area of mobile robot programming.

Usage Scenarios & Student Projects

This section highlights some of the S-Trike projects the students have to deal with at the University of Freiburg. Obviously, these examples introduce just a fraction of the possibilities our robot oers. They do, however, form the basis for more elaborate scenarios and tasks that more advanced students might think of. The overall structure of the set of experiments the students have to execute, is set up in a way, that it strongly supports modularity by means of code re-use: Modules to read specic sensors or to drive the motors have to be written only once and can be reused for future experiments. Each of the following projects implements modules for new sensors while reusing already available modules from the previous examples. Figure 3: Experimentation board.

3.1

Turn Rate Sensor Based Driving

2.3

Controllers

The microcontroller and the FPGA (also referred to as the controllers) are the most important com1 A six cell NiMH battery pack with a nominal cell voltage of 7.2V when fully charged and around 6.0V when discharged, results in a voltage of 2.4V to 2.0V on the output of the voltage divider, which is within the range of an 3.3V A/D converter.

The analog turn rate sensor calculates the current heading of the robot, where the sensors output voltage is proportional to the turn rate. Without movement, is centered at half of the supply voltage Vcc . Turning the sensor results in a higher or lower . Therefore, the heading H can be calculated by integration:
t

H =
0

( Vcc /2) dt. This calculation can be easily

implemented on the microcontroller, requiring only a few lines of code: // s e n s o r i s a t t a c h e d t o a n a l o g p o r t A0 void loop (){ c t = m i l l i s ( ) ; // c u r r e n t time H += ( analogRead (A0) Vcc /2 ) ( c t o t ) ; o t = c t ; // time o f l a s t measurement } To turn the robot the two motors have to rotate at dierent speeds. This is achieved by Pulse Width Modulation (PWM). Although it is possible to create PWM signals on the microcontroller, the FPGA oers a more precise control of an output signal. Therefore, one might decide that the motor controller should be realized in hardware on the FPGA. With the microcontroller calculating the heading and the FPGA controlling the motors, some form of communication between the two controllers has to be established. The Arduino web site oers a ready to use serial protocol. So, only on the FPGA side a serial data receiver has to be implemented, receiving the heading sent by the microcontroller. Finally, to test the developed modules, a small robot controller which drives the robot in the shape of a square, has been added to the FPGA. The controller implements a simple nite state machine, using the turn rate sensor to measure the 90 degree turns. This small example incorporates all major design steps of a classical embedded system : There are sensors (in this case the turn rate sensor), which are connected to analog/digital converters (integrated into the microcontroller), generating digital signals. The digital signals are processed by the microcontroller and the FPGA, and converted back to analog signals via PWM to control the actuators (the two motors). Furthermore, the division of tasks to hardware and software can be seen as a simple example of hardware/software co-design. The project utilizes around 15% of the total microcontroller memory and around 3% of the logic blocks available on the FPGA. While both controllers still have computing power available, one could also extend the routines or use them within other applications.

received, the line is pulled back to low, making the distance to a detected target proportional to the length of the returned pulse (see also Figure 4).

Figure 4: Signal on the data line of a S-Trike ultrasonic sensor. Although an Arduino library for this kind of ultrasonic sensor interface is available, direct digital line manipulation is much simpler and cheaper in terms of resource utilization on the FPGA. Since all three ultrasonic sensors are located at the front of the vehicle, they cannot be used at the same time (because each sensor could receive multiple echoes from the dierent sensors sound waves). Instead, they have to be activated one after another. As a result, each sensor value can be requested about three times per second. With both the motor controllers (Section 3.1) and the sensor reader realized on the FPGA, the robot controller can be easily implemented there, too. However, it is also possible to use the Arduinos serial transmission capabilities to receive the ultrasonic sensor data from the FPGA, process the sensor data on the microcontroller, and send some sort of motor signal back to the FPGA. As a side remark, FPGA softcores2 oer a third option: The sensor data and the motor speed values can be written directly into a shared memory location which is available to the software running on the softcore processor. This allows the design of the robot controller in a high-level programming language, while the sensor values and control signals still can be accessed in hardware without any transmission overhead. Turning back to our example, a simple robot controller could turn the S-Trike slightly to the left, if the right sensor detects an obstacle at a certain distance (and vice versa), and initiate a sharp turn into any direction in case the center sensor detects an object. Moreover, the turn rate sensor module (see Section 3.1) could be used to drive more precise turns and straight lines. If the robot controller as sketched above is implemented on the microcontroller, it uses about 20% of its total available memory and about 3% of the logic blocks on the FPGA, which in this scenario is responsible for managing the motors and reading the ultrasonic sensors. Clearly, the controller can be much more advanced, before being limited by hardware constraints. Starting from the simple robot controller, more advanced tasks could include drive around an obstacle and continue driving in the same direction as before,
2 The programmable hardware of FPGAs allows the implementation of a microprocessor which then can be programmed in a high-level language.

3.2

Ultrasonic Sensor Based Driving

The three ultrasonic sensors on the forefront of the chassis oer a broad eld-of-view in front of the STrike. Obviously, one of the main application areas of such sensors is obstacle detecting, either while driving from point A to point B, or to stay within a given course marked by a barrier. The ultrasonic sensors each use their own IC to generate the sound pulses. To activate one of them, a single high pulse of 10s duration has to be sent to the sensor. The sensor then sends out sound waves and pulls the line to high. As soon as an echo has been

or nd a number of obstacles (e.g. tennis balls), and push them out of a given area.

3.3

Mobile Phone as Remote Control

As the nal example, we explain how the Bluetooth module can be used to connect the S-Trike robot to a mobile phone. The Bluetooth module oers a simple serial interface which can be easily accessed by the Arduino microntroller or the FPGA. In normal operation mode, the module accepts all incoming connections with the correct PIN. Obviously, the Bluetooth module requires another Bluetooth enabled device. In the scenario discussed here, an Android 4.0 mobile phone is used to control the S-Trike robot, facilitating either the inbuilt accelerometer of the phone or touch buttons (see Figure 5). Additionally, the ultrasonic sensor data, the battery voltage, and the total current consumption (calculated by integrating the output of the current sensor) is transmitted back to the phone.

Figure 5: Experimental user interface to control the STrike by a Bluetooth connection. The bars above the robot represent the current ultrasonic sensor values.

cuses on the hardware implementation on the S-Trike as displayed in Figure 6: The FPGA reads the ultrasonic sensor values the same way as described in Section 3.2. The sensor data is then transmitted to the microcontroller via a serial connection. The microcontroller collects the data from the FPGA, the battery voltage, and the current sensor data and relays them to the Bluetooth module which transmits them to the mobile phone. The mobile phone calculates the speed of the two motors from the current user input and sends them back to the S-Trike. To achieve a RC-car like transmission performance, the current motor speed has to be transmitted by the mobile phone as often as possible. However, high refresh rates result in a higher workload on the microcontroller. In addition, the data transmission bandwidth is limited by the serial connection between the Bluetooth module and the Arduino microcontroller. Experiments have shown that the signal can be transmitted every 60ms without any negative impact. The telemetry information is not that time critical and therefore only submitted ve times per second. Driving the robot by a mobile phone is not only a good example for many dierent components of the S-Trike working together, but also a lot of fun. Furthermore, it sparks the interest of both students and the public, as presentations have shown. Although this experiment is limited by the microcontroller, which cannot handle more calculations, the FPGA is almost dormant (only 2% of the logic blocks are utilized). By shifting some of the calculations from the microcontroller to the FPGA, both could handle additional tasks like automatic collision detection for example.

S-Trike in Education

Figure 6: The hardware architecture used to control the S-Trike with a mobile phone. The development of the Android application will be skipped here. Hence, the rest of this section fo-

The S-Trike was introduced at the University of Freiburg in the summer term 2012 as being the underlying hardware environment of the so-called Mobile Hardware Lab [7, 11], which is a mandatary practical course for all undergraduate students. For many of them, it is the rst hands-on experience with real hardware. At the beginning of the term, small groups were formed with three students in each group. For the duration of the lab, one S-Trike is lent out to each group. During the semester, the groups are required to solve ten dierent exercise sheets, which can be done at home or at the university, but in particular at each groups own pace. The solutions to the exercises are uploaded via a web interface, downloaded, corrected and graded by a tutor, and the corrections are nally re-uploaded to the website, where the group can access them immediately. A weekly, but optional lecture covers the basics of microcontroller programming and hardware synthesis using VHDL required to complete the experiments. These lectures are especially dedicated to students without any prior knowledge and have been recorded, so that

the students can watch them as often as needed. Furthermore, students are encouraged to ask their tutor in case of problems. The rst exercises introduce the microcontroller and the FPGA, followed by connecting and using the dierent sensors, buttons, LCD, speaker, and other modules on the experimentation board. Afterwards, the motors are introduced with exercises similar to the experiments described in Sections 3.1 and 3.2. As the grand challenge of the hardware lab, the last exercise sheet introduces a small competition: A time race through a circular course with about 4m diameter made out of cardboard boxes. Each S-Trike must stay within 20cm of the outer wall of the race track. In comparison to the preceding exercise sheets, the students received no guidance in how to solve the given problem. So, it was up to the students, whether they use the FPGA and/or the microcontroller to come up with a competitive solution. During the competition we have seen a lot of dierent approaches carried out by the students, ranging from more simple solutions using the microcontroller only to highly ecient robot controllers based on a combination of the FPGA and the microcontroller. Moreover, some student groups did not use all three ultrasonic sensors, but only the one oriented to the outer wall of the race track: In this case the remaining ultrasonic sensor can be activated more often and by this allows driving at a higher speed (due to the fact that two out of the three sensors are deactivated, one does not have to take care about potential echoes from other sensors sound waves; see Section 3.2). Altough the S-Trike robots form the underlying hardware environment of our Mobile Hardware Lab, they are available for other student projects (e.g. bachelor and master theses), too. One example for such a project has been presented in Section 3.3, which was originally meant to be a short test of the Bluetooth module and nally ended up in a solution for a fast, secure, and low-latency connection between a mobile phone and the S-Trike robot. Besides such an application, the Bluetooth module also oers the opportunity to let several S-Trikes act as a team by dynamically exchanging information between them.

a great success, there are several directions for future work. As one example, the Arduino Pro Mini features only 13 digital I/O pins, too few for some usage scenarios (the Bluetooth controller described in Section 3.3 requires 12 out of the 13 pins). To resolve this limitation, the Arduino could be replaced by a larger version, or even by a custom designed microcontroller board. Finally, the great results of the students in the grand challenge competition and in this years hardware lab in general is also a strong indicator for the success of the S-Trike project.

References
[1] Altera. Quartus II. http://www.altera.com. [2] R. Balogh. Laboratory exercises with Acrob robot. In 2nd International Conference on Robotics in Education, pages 4146, 2011. [3] D. Brandt, J.C. Larsen, D.J. Christensen, R.F.M. Garcia, D. Shaikh, U.P. Schultz, and K. Stoy. Flexible, FPGA-based Electronics for Modular Robots. In IROS Workshop on Self-Recongurable Robots, Systems and Applications, 2008. [4] R. Connaughton and M. Modlin. A Modular and Extendable Robotics Platform for Education. In 39th IEEE International Conference on Frontiers in Education, pages 791794, 2009. [5] Devantech. SRF05 - Ultra-Sonic Ranger Technical Specication. [6] A. Diosi. Mappino - Open Source Robot for Learning about Laser Scan Matching. In 2nd International Conference on Robotics in Education, pages 109116, 2011. [7] A. Hett and T. Schubert. A Hardware Lab in a Pocket. In World Conference on E-Learning in Corporate, Government, Healthcare, and Higher Education, pages 525528, 2003. [8] Lego. Mindstorms Robotic Platform. mindstorms.lego.com. [9] Parallax. Stingray robot chassis. parallax.com. http://

http://www.

Conclusion and Future Work

This paper presented the S-Trike robot which is based on a Parallax Stingray robot chassis, an FPGA and a microcontroller as control units and multiple different sensors. The combination of an FPGA and a microcontroller oers a lot more possibilities in the area of microprocessor programming, FPGA-based hardware synthesis, hardware/software co-design, and embedded systems than either one of the two could provide on its own. Such a broad eld of applications is far beyond a single course like the Mobile Hardware Lab for which S-Trike has been originally designed and will hopefully spawn many additional projects in the future. Although the rst deployment of 50 S-Trikes was

[10] The Arduino project. http://arduino.cc. [11] T. Schubert and B. Becker. A Hardware Lab Anywhere At Any Time. Journal of Systemics, Cybernetics and Informatics, 2(6):1316, 2004. [12] Sparkfun. Arduino Pro Mini. sparkfun.com. https://www.

[13] Terasic. DE0-nano development and education board. http://www.terasic.com.tw. [14] G. Vitale. FPGAs Enable Flexible Platform for High School Robotics. Xcell Journal, (79):2833, 2012.