S-Trike_A Mobile Robot Platform for Higher Education

8/13/2019 S-Trike_A Mobile Robot Platform for Higher Education

1/6

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 introducesS-Trike, a mobile robot forstudent education at university level. Build around arobot chassis, our S-Trike equipped with an FPGA, amicrocontroller, and multiple sensors, offers studentsa large amount of diversified possibilities: A turn-ratesensor can be used to turn the robot a certain amountof degrees, three ultrasonic sensors allow it to navigatearound obstacles, and a Bluetooth module can be used

to connect it to a mobile phone, just to name only a fewexamples. One of the main advantages of our approachis that the various components are not hard-wired toeach other. Instead, the students have to take careabout the entire design flow, starting from connectingsensors and actuators to the FPGA and/or the micro-controller using jumper wires, and then implementingappropriate functions to receive sensor data, to processthe data, and finally to control the actuators. The pos-itive feedback we received from students after introduc-ing a total of 50 S-Trike robots during the summer term2012 clearly demonstrates the success of our approach.

1 IntroductionAt universities, mobile robots are a promising way

to get (undergraduate) students hooked on many as-pects of computer science, e.g. in the area of embed-ded systems engineering. There are many robotic sys-tems available, offering an easy to learn introductioninto the world of computers and programming. Mostproducts are based on a microcontroller as its controlunit [2, 4, 6, 8]. Mobile robots controlled by micro-controllers are often easy to program, even without adeeper understanding of the underlying hardware.

As an alternative to microcontrollers, so-calledField Programmable Gate Arrays (FPGAs) have be-

come more and more popular in both, industry andacademia within the last years. FPGAs are integratedcircuits designed to be configured by the user after man-ufacturing and contain programmable logic componentscalled logic blocks. A hierarchy of reconfigurable in-terconnects allows the blocks to be wired together indifferent configurations. The logic blocks can be con-figured to perform complex combinational functions, ormerely simple logic gates like AND and XOR. In mostFPGAs, the logic blocks also include memory elements,

which may be simple flip-flops or even complete blocksof RAM. Usually, FPGAs are programmed/configuredusing hardware description languages like VHDL or Ver-ilog, both of which differ substantially from softwareprogramming languages and require at least a basic un-derstanding of the underlying hardware. Compared tothe number of microprocesser-based robots the numberof mobile robots using FPGAs available on the marketis far less [3, 14].

This paper presents S-Trike, a mobile robot plat-form for higher education at university level, which wasfirst introduced to students during the summer term2012. Utilizing both, an FPGA and a microcontroller,it offers a much broader range of experiments than clas-sical educational mobile robots like for example the well-known Lego Mindstorms sytem [8]. The main advan-tages of our approach are flexibility and high perfor-mance at an affordable price:

Flexibility, because none of the sensors or ac-tuators are fixed in hardware, but can be con-nected to either the FPGA or the microcontrollerby using jumper wires. This architecture allows usto start with simple experiments, using the easy-

to-understand microcontroller only (fits perfectlyfor students without any prior knowledge), thenswitching to the more complex but also more pow-erful FPGA as the robots control unit, and finallyend up with more sophisticated experiments inte-grating both the FPGA and the microcontroller to-gether. In the last case, the students have to imple-ment at least a simple communication protocol tobe able to exchange data between the FPGA andthe microcontroller.

High performance at an affordable price.While S-Trikes microcontroller provides enoughcapabilities for quite a number of applications

(wrt. clock frequency, I/O pins, and memory), theFPGA is even more powerful (50 MHz clock fre-quency, about 80 I/O-Pins, 32 MB memory), mak-ing it the first choice when developing complextasks. Furthermore, compared to simple microcon-trollers FPGAs allow different tasks to be executedin parallel, providing real concurrency. By usingas many standard components as possible, we havebeen able to keep the price of a single S-Trike robotat about 420 euro.


2/6

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

2 Hardware

As can be seen in Figure 1 the S-Trike is buildaround the Parallax Stingray robot chassis [9]. A to-tal of five custom circuit boards are placed on and inthe chassis: One largePrinted Circuit Board (PCB) isused for motor control (placed within the chassis), asecond one is used as the experimentation board (ontop of the chassis), and three small PCBs contain theultrasonic sensors (mounted at the front of the robot).Apart from these PCBs, all sensors and controllers arestandard components and used as they are.

Figure 1: A fully equipped S-Trike robot. Three ultra-sonic sensors are attached to the front, while the exper-imentation board is mounted on top of the chassis. A7.2V battery pack, two DC motors (one for each wheel)and the motor control board are located within the chas-sis. Including sensors, the robot has a length of about36cm and a width of 28cm (from wheel to wheel).

Since S-Trikes main purpose is student education,additional safety measures have been integrated intoboth main circuit boards: The motor voltage can belowered from 7.2V (battery pack voltage) to 5.0V, whichresults in a slower robot. Additionally, there exists nodirect connection from the battery to the experimenta-tion board. As a result, the total power available onthe board on top of the robot is limited by a 3.3V volt-age regulator. Furthermore, all connectors are reversepolarity protected. For power control, a large and easy

to access power switch has been added to the back ofthe chassis. It is integrated directly into the positivepower line from the battery. In addition to the twomain circuit boards described in Sections 2.1 and 2.2,three ultrasonic sensors are mounted at the front of therobot. They are able to detect obstacles within a rangeof four meters [5].

The entire hardware has been designed in a mod-

ular fashion: All major components are plugged intoone of the two large PCBs and can be removed if theyare not needed. The experimentation board featuresfour additional servo connectors, in case the robot isextended or the board is mounted onto another chassiswhich uses servos.

The overall schematic of our S-Trike is shown inFigure 2, further demonstrating the modularity of ourapproach. Around the two controllers (namely theFPGA and the microcontroller) the various sensors andactuators have been arranged in such a way, that theycan be attached to both the FPGA and the microcon-troller. 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 isto provide an appropriate interface so that the newmodule can be connected to the controllers with jumperwires.

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

2.1 Motor Control Board

The motor control board, located within the chas-sis, serves two main purposes: It contains voltage reg-ulators, which supply 3.3V and 5.0V to all sensors and

the experimentation board. Additionally, it containsthe transistors for full forward and backward rotationof the two motors. These transistors form a typicalH-bridgewhich can be used to easily rotate a DC mo-tor backwards and forwards. The motor speed is thenregulated by Pulse Width Modulation (PWM) on thecorresponding control signal.

Additionally, a hall effect based current sensor anda voltage divider are integrated onto the motor controlboard. The voltage divider allows reading the battery


3/6

voltage through one of the 3.3V analog to digital (A/D)converters on the FPGA or on the microcontroller bydividing the battery voltage by three1.

Finally, the three ultrasonic sensors are connectedto the motor control board, too, while a single 16 leadribbon cable connects the experimentation with the mo-tor control board.

2.2 Experimentation BoardThe experimentation board (see Figure 3) ismounted on top of the chassis. Its main components area microcontroller, an FPGA, an LCD, a Bluetooth mod-ule, a turn rate sensor, several push-buttons, a speaker,and an array of LEDs. All active components are con-nected to the required supply voltage on the board.However, to use a specific component, the remainingconnections (i.e. the control signals) have to be placedby hand, using wires to connect the female socketsnext to each module. In the middle of the experimenta-tion board a breadboard has been integrated to be ableto handle additional electronic parts, further increasingthe flexibility of our approach.

Figure 3: Experimentation board.

2.3 Controllers

The microcontroller and the FPGA (also referredto as the controllers) are the most important com-

1A six cell NiMH battery pack with a nominal cell voltageof 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 voltagedivider, which is within the range of an 3.3V A/D converter.

ponents of our S-Trike. For the microcontroller wemake use of an Arduino Pro Mini based on the AT-mega328 microcontroller [12]. The popularity of theArduino project spawned numerous projects, resultingin libraries for servo and DC motor control, for writingtext on an LCD, and for sound output, to name justa few [10]. Combined with a high-level programminglanguage similar to C++, it allows students to execute

their first projects within minutes. To program the mi-crocontroller, a small USB to serial converter can beattached to the experimentation board. The Arduino-IDE then compiles and transmits the programs directlyto the chips flash memory.

An Altera Cyclone IV FPGA mounted on a Tera-sic DE0-Nano experimentation board forms the basis forall FPGA related experiments [13]. In addition to thesensors on the experimentation board given in Figure 3,the FPGA board itself consists of eight LEDs, two push-buttons, and a 3-axis accelerometer (all of them aretherefore only available to the FPGA). The DE0-nanoalso features an integrated USB-Port for programmingand debugging purposes. To program the FPGA, a free

version of the Quartus II IDE can be downloaded fromthe Altera website [1]. Compared to the Arduino micro-controller, the Cyclone IV FPGA provides significantlymore I/O pins, more on-chip memory, and more com-puting power, making it the first choice when imple-menting complex tasks, while the microcontroller per-fectly fits for first experiments in the area of mobilerobot programming.

3 Usage Scenarios & Student Projects

This section highlights some of the S-Trike projectsthe students have to deal with at the University of

Freiburg. Obviously, these examples introduce just afraction of the possibilities our robot offers. They do,however, form the basis for more elaborate scenariosand tasks that more advanced students might think of.The overall structure of the set of experiments the stu-dents have to execute, is set up in a way, that it stronglysupports modularity by means of code re-use: Modulesto read specific sensors or to drive the motors have tobe written only once and can be reused for future ex-periments.

Each of the following projects implements modulesfor new sensors while reusing already available modulesfrom the previous examples.

3.1 Turn Rate Sensor Based Driving

The analog turn rate sensor calculates the currentheading of the robot, where the sensors output voltageis proportional to the turn rate. Without movement, is centered at half of the supply voltage Vcc. Turn-ing the sensor results in a higher or lower . There-fore, the heading H can be calculated by integration:

H=

t

0

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


4/6

implemented on the microcontroller, requiring only afew lines of code:

// s e n so r i s a tt ac he d t o a na lo g p or t A0v o i d loop () {

c t = m i l l i s ( ) ; / / c u r r e n t t im eH += (analogRead(A0) Vcc/2 ) ( c t ot ) ;o t = c t ; // t i me o f l a s t m ea su re me nt

}

To turn the robot the two motors have to rotateat different speeds. This is achieved by Pulse WidthModulation (PWM). Although it is possible to createPWM signals on the microcontroller, the FPGA offersa more precise control of an output signal. Therefore,one might decide that the motor controller should berealized in hardware on the FPGA.

With the microcontroller calculating the headingand the FPGA controlling the motors, some form ofcommunication between the two controllers has to beestablished. The Arduino web site offers a ready to useserial protocol. So, only on the FPGA side a serial data

receiver has to be implemented, receiving the headingsent by the microcontroller.

Finally, to test the developed modules, a smallrobot controller which drives the robot in the shape ofa square, has been added to the FPGA. The controllerimplements a simple finite state machine, using the turnrate sensor to measure the 90 degree turns.

This small example incorporates all major designsteps of a classical embedded system: There are sen-sors (in this case the turn rate sensor), which are con-nected to analog/digital converters (integrated into themicrocontroller), generating digital signals. The dig-ital signals are processed by the microcontroller andthe FPGA, and converted back to analog signals viaPWM to control the actuators (the two motors). Fur-thermore, the division of tasks to hardware and softwarecan be seen as a simple example ofhardware/softwareco-design.

The project utilizes around 15% of the total mi-crocontroller memory and around 3% of the logic blocksavailable on the FPGA. While both controllers still havecomputing power available, one could also extend theroutines or use them within other applications.

3.2 Ultrasonic Sensor Based Driving

The three ultrasonic sensors on the forefront of the

chassis offer a broad field-of-view in front of the S-Trike. Obviously, one of the main application areas ofsuch sensors is obstacle detecting, either while drivingfrom point A to point B, or to stay within a given coursemarked by a barrier.

The ultrasonic sensors each use their own IC togenerate the sound pulses. To activate one of them,a single high pulse of 10s duration has to be sent tothe sensor. The sensor then sends out sound waves andpulls the line to high. As soon as an echo has been

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

Figure 4: Signal on the data line of a S-Trike ultrasonicsensor.

Although an Arduino library for this kind of ul-trasonic sensor interface is available, direct digital linemanipulation is much simpler and cheaper in terms ofresource utilization on the FPGA. Since all three ultra-sonic sensors are located at the front of the vehicle, theycannot be used at the same time (because each sensorcould receive multiple echoes from the different sensorssound waves). Instead, they have to be activated oneafter another. As a result, each sensor value can berequested about three times per second.

With both the motor controllers (Section 3.1) andthe sensor reader realized on the FPGA, the robot con-troller can be easily implemented there, too. However,it is also possible to use the Arduinos serial transmis-sion capabilities to receive the ultrasonic sensor datafrom the FPGA, process the sensor data on the micro-controller, and send some sort of motor signal back tothe FPGA.

As a side remark, FPGA softcores2 offer a thirdoption: The sensor data and the motor speed valuescan be written directly into a shared memory locationwhich is available to the software running on the soft-core processor. This allows the design of the robot con-troller in a high-level programming language, while the

sensor values and control signals still can be accessed inhardware without any transmission overhead.

Turning back to our example, a simple robot con-troller could turn the S-Trike slightly to the left, if theright sensor detects an obstacle at a certain distance(and vice versa), and initiate a sharp turn into anydirection 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 straightlines.

If the robot controller as sketched above is imple-mented on the microcontroller, it uses about 20% ofits total available memory and about 3% of the logic

blocks on the FPGA, which in this scenario is responsi-ble for managing the motors and reading the ultrasonicsensors. Clearly, the controller can be much more ad-vanced, before being limited by hardware constraints.Starting from the simple robot controller, more ad-vanced tasks could include drive around an obstacleand continue driving in the same direction as before,

2The programmable hardware of FPGAs allows the implemen-tation of a microprocessor which then can be programmed in ahigh-level language.


5/6

or find a number of obstacles (e.g. tennis balls), andpush them out of a given area.

3.3 Mobile Phone as Remote Control

As the final example, we explain how the Blue-tooth module can be used to connect the S-Trike robotto a mobile phone. The Bluetooth module offers a sim-ple serial interface which can be easily accessed by the

Arduino microntroller or the FPGA. In normal opera-tion mode, the module accepts all incoming connectionswith the correct PIN.

Obviously, the Bluetooth module requires anotherBluetooth enabled device. In the scenario discussedhere, an Android 4.0 mobile phone is used to control theS-Trike robot, facilitating either the inbuilt accelerome-ter of the phone or touch buttons (see Figure 5). Addi-tionally, the ultrasonic sensor data, the battery voltage,and the total current consumption (calculated by inte-grating the output of the current sensor) is transmittedback to the phone.

Figure 5: Experimental user interface to control the S-Trike by a Bluetooth connection. The bars above the

robot represent the current ultrasonic sensor values.

Figure 6: The hardware architecture used to control theS-Trike with a mobile phone.

The development of the Android application willbe skipped here. Hence, the rest of this section fo-

cuses on the hardware implementation on the S-Trikeas displayed in Figure 6: The FPGA reads the ultra-sonic sensor values the same way as described in Sec-tion 3.2. The sensor data is then transmitted to themicrocontroller via a serial connection. The microcon-troller collects the data from the FPGA, the batteryvoltage, and the current sensor data and relays themto the Bluetooth module which transmits them to the

mobile phone. The mobile phone calculates the speedof the two motors from the current user input and sendsthem back to the S-Trike.

To achieve a RC-car like transmission performance,the current motor speed has to be transmitted by themobile phone as often as possible. However, high re-fresh rates result in a higher workload on the microcon-troller. In addition, the data transmission bandwidth islimited by the serial connection between the Bluetoothmodule and the Arduino microcontroller. Experimentshave shown that the signal can be transmitted every60ms without any negative impact. The telemetry in-formation is not that time critical and therefore onlysubmitted five times per second.

Driving the robot by a mobile phone is not onlya good example for many different components of theS-Trike working together, but also a lot of fun. Fur-thermore, it sparks the interest of both students andthe public, as presentations have shown.

Although this experiment is limited by the micro-controller, which cannot handle more calculations, theFPGA is almost dormant (only 2% of the logic blocksare utilized). By shifting some of the calculations fromthe microcontroller to the FPGA, both could handleadditional tasks like automatic collision detection forexample.

4 S-Trike in EducationThe S-Trike was introduced at the University of

Freiburg in the summer term 2012 as being the underly-ing hardware environment of the so-calledMobile Hard-ware Lab [7, 11], which is a mandatary practical coursefor all undergraduate students. For many of them, it isthe first hands-on experience with real hardware.

At the beginning of the term, small groups wereformed with three students in each group. For the du-ration of the lab, one S-Trike is lent out to each group.During the semester, the groups are required to solveten different exercise sheets, which can be done at homeor at the university, but in particular at each groups

own pace. The solutions to the exercises are uploadedvia a web interface, downloaded, corrected and gradedby a tutor, and the corrections are finally re-uploadedto the website, where the group can access them imme-diately.

A weekly, but optional lecture covers the basicsof microcontroller programming and hardware synthe-sis using VHDL required to complete the experiments.These lectures are especially dedicated to students with-out any prior knowledge and have been recorded, so that


6/6

Documents

S-Trike_A Mobile Robot Platform for Higher Education