Integration of RC Vehicles in a Robotic Arena

Nuno G. P. Martinsnuno.martins@tecnico.ulisboa.pt

Instituto Superior Tecnico, Lisboa, Portugal

November 2016

Abstract

This work is integrated in a group effort to produce an architecture capable of being used by students, fora practical implementation of attitude and position control models, whether it be for a single or a multipleagent environment. Integrated solutions that allow for the use of commercially available Radio Control(RC) vehicles under a new concept of Robotic Arena, in GPS denied environments, were developed.This architecture was designed with focus on replicability, versatility and reliability while aiming for alow-cost solution. Two different approaches were taken, one based in an Arduino, and another based inRaspberry Pi. These different approaches were developed to accomplish the same purposes, but with thepotential to provide alternative capabilities. Once the pre-requirements of the system were established,additional hardware was integrated so as to respond to the needs and develop individual solutions. Someof the capabilities that must be ensured are: the communication with the vehicle, the interaction withthe vehicle’s actuators and recalling information about the vehicle’s attitude using suitable sensors. Inthe end, all these individual components were integrated in a command system, creating two differentapproaches to handle with the vehicle and include them in the global system. A Simulink model capableof integrating the control blocks, to be produced by the students, was created to allow for interaction withthe vehicle and its systems. This work results in two fully usable independent architectures, ready to bereplicated and used by students in practical Control Classes.Keywords: Integrated Architecture, Robotic Arena, GPS-denied Environments, Remote Communication,RC Vehicles.

1. Introduction

Nowadays with the scientific progress in the mostdifferent fields like control, artificial intelligence androbotics, the importance of multi-agent environmentsbecomes a reality that’s increasingly compelling.These environments have proved to be very versa-tile. Applications are varied with cooperation be-tween agents being used to perform tasks that can-not be performed by a single agent or to speed upexecution time and improve performance. Indepen-dently of the agent’s goal, an important part of itsorganization within a populated environment is theself-awareness of their location and the awareness ofthe other agents’ locations. To accomplish this inGPS denied environments, a variety of sophisticatedsystems are available on the market but require sig-nificant investments. These solutions are generallyassociated to the use of Robotic Arenas and advancedoptical motion capture systems, which are already inuse in state-of-art robotics research centres. An al-ternative approach to produce a new generation ofRobotic Arenas is required, to extend the utility notonly to the researchers, but to the students as well.

2. Overall Vision

The purpose of this work is to develop an architec-ture that allows for the integration of commerciallyavailable RF vehicles in a Robotic Arena. The over-all concept of this architecture is based on the ideaof using a computer running a Simulink environmentto remotely control and command one, or multipleground vehicles. This computer must receive as in-put the position of the vehicle provided by a local-ization system (the proprietary localization systemADIS is in development to be used for this purpose).The computer must be able to wirelessly transmitthe actuation commands to the vehicle’s actuatorsand receive the information provided by the set ofsuitable sensors to be installed on-board the vehicle.This concept asks for the installation of some kind ofhardware in the vehicle, in order to promote the inter-action with the vehicle’s actuators, to handle with theon-board installed sensors and to perform the com-munications itself. The developed architecture willbe referred to as Command System.

Besides all the features already mentioned, theCommand System was designed based on some morepre-requirements:

1

Actuators

Position

Information

User

Interface

Sensors

Hardware

Figure 1: Overall Concept of the developed Architecture.

1. The vehicles must be integrated in the archi-tecture without having their original structurechanged;

2. The architecture should be modular and easilyreplicable;

3. The architecture should allow flexibility in anumber of vehicles to be commanded;

4. Working frequency above 30Hz. This corre-sponds to the working frequency of ADIS. Thecommand system should not degrade the overallsystem’s performance;

5. Keep costs reasonably low throughout the wholeplatform.

3. The RC ModelThe model chosen to integrate the architected systemwas the LaTrax SST, built by Traxxas. It is a 1/18scale model of a 4WD SST race truck [1]. The SSThas an electrical motor powered rechargeable battery.The electrical motor integrates a brake system that isa very useful feature. Capable of reaching a top speedof 12 meters per second and to perform aggressive ac-celerations, this car is a very good model to accom-plish some of the more complex move sequence, likedrifts, spins and j-turns. The high-quality construc-tion materials, and the robustness of the structuremakes this model very resistant to potential impactsand crashes. The modularity of the LaTrax SST en-sures the possibility of replacing any damaged part,without a loss of the whole vehicle. Despite all thesefeatures, the cost is very reasonable when comparedwith similar models. For all of this, the LaTrax SSTis a great model to use in a laboratory and to performthe required mission.

3.1. Vehicle Setup

To be possible to remotely control the car, it is neces-sary to know how its actuators work. The first thingthat is important to understand is how the originalsetup is conceived. For this, a list of the original vehi-cle’s components is presented, and a schematic helpsto understand the vehicle’s setup (see figure 2).

List of components:

• Brushless throttle motor;

• Brushless motor’s Electronic SpeedController (ESC);

• Servo direction motor;

• 6 cell 2/3A NiMH battery;

• RF receiver.

ThrottleBrushless Motor

RF Receiver

NiMH

Battery

6-cell 2/3A

Servo Direction Motor

ESC

Figure 2: Original vehicle setup.

The connections with the RF receiver are ensured bycables with three wires. These three wires have acolour code that help to understand their function.

• The black wire is ground.

• The red wire is the voltage (ESC: 5V output;Servo: 5V input).

• The white (dashed black in figure 2) wire is thecontrol signal.

Once the RF receiver’s outputs are directly connectedto the actuator’s white wires, if these output signalsare known, it is possible to emulate them to actuatethe motors.

3.2. Vehicle Actuation

According to the manufacturer, the control pin’s out-put from RF receivers provide a Pulse-Width Modu-lated (PWM) signal, which contains the informationtransmitted from the transceiver by Radio Frequency.Each channel outputs a PWM wave to actuate onedifferent motor. An oscilloscope allows the visual-ization of the output signal of one of the receiver’s

2

Figure 3: Original PWM signal on the RF receiver’s output, no actuation required

Table 1: PWM signals’ parameters.

Minimum value Mean value Meanvalue

Actuation Required 100% reverse 0% 100%

High Pulse Width 93 µs 1487 µs 1979 µs

Duty Cycle 10% 15% 20%

Period 9840 µs

Frequency 101.6Hz

channels, when there is no actuation required on ra-dio transceiver (figure 3).The vertical dashed bars on figure 3 mark the lim-its of a maximum and minimum High Pulse Width,when 100% actuation is required and 100% reverseactuation is required in these specific channels. Us-ing the oscilloscope tools, it is possible to characterizethe output PWM wave. The PicoScope software al-lows for the determination of important parametersthat help in this characterization. These parameterswere determined for each one of the three mentionedstates and registered in table 1.After studying the output of the two receiver chan-nels, it is clear that the PWM signal presents thesame behaviour in both. The actuation of the ve-hicle can be done by generating two different PWMsignals, one for each actuator. Once the receiver’soutputs are totally known, it is possible to emulatethem. To guarantee that no interference that causesan undesired behaviour of the vehicle happens, thisemulation of signals must be ensured by a specifichardware that produces hardware PWM signals.

3.3. Communication with the Vehicle

As an RC car, the LaTrax SST scale model isequipped with a RF system that guarantees the com-munication between the user and the vehicle. Despitethis being a very reliable technology, it is not usablein this architecture, because their functionalities areout of the scope of this work. Therefore, an alter-native is needed to establish a new communication’ssystem. Since the ADIS infrastructure is being de-signed to use a Wi-Fi network to broadcast the infor-mation about the vehicle position, it seems a logicalmove to use and potentiate this available resource. Toperform vehicle control through a wireless communi-

cation, it should be guaranteed that the frequency ofcommunication is good enough. The communicationitself represents the bottleneck of the system’s workfrequency. Therefore, it is extremely important tochoose the proper protocol for the transport layer ofthe IP network. It must be assured that the commu-nication’s frequency is above the pre-required valueof 30Hz.Since the communication speed is the most valuedfeature, the implemented communication protocolwill be the User Datagram Protocol (UDP), insteadof the typically used Transmission Control Protocol(TCP). TCP’s protocol reliability is higher due to itsability to prevent the loss of transmission data andensuring the correct order of packet reception, butit is also quite slower than the UDP protocol. How-ever, it is important to understand that the speedperformance of UDP is achieved at the expense ofnot having the same reliability as TCP.

3.4. Vehicle Instrumentation

An important part of the developed architecture isthe instrumentation of the vehicle. The ADIS systemwill provide information about the spatial locationof the vehicles, but this information is not enoughto know about its spatial orientation. An InertialMeasurement Unit (IMU) is the proper instrument tocollect information about the vehicle’s attitude. TheIMU used was the 10 degree of freedom (DOF) GY-80 model, which integrates the set of sensors shownin table 2. Note that an additional IMU DOF isprovided by the BMP080 sensor pressure not used inthis work.The data of all these sensors can be combined to pro-vide a more reliable information about the vehicle’sattitude. The GY-80 supports Inter-integrated cir-

3

Table 2: GY-80 IMU’s sensors. LsB means Less Significant Bit.

Sensor Model DOFDigital Output

ResolutionPhysical Quantity Units Used Range Scale Factor

Accelerometer ADXL345 [2] 3 11 bits Specific Force g-force [g] ±4g 3.9 mg/LsbGyroscope L3G4200D [3] 3 16 bits Angular Rate degree per second [dps] ±2000 dps 70 dps/Lsb

Magnetometer HMC5883L [4] 3 12 bits Earth’s Magnetic Field Gauss [G] ±1.3G 0.92 mG/Lsb

cuit (I2C), a multi-master serial bus, to configure allthe sensors and collect their raw data measurements.To choose the appropriate range for each sensor, asimple test was designed: a preliminary test must beperformed using the measurements ranges defined bydefault. The car must be driven manually using a RFcontroller, pushing the actuators to their limits, andforcing the car to perform the most aggressive ma-noeuvres. In this way, it is possible to guarantee thatthe sensors will be submitted to the worst possiblescenario. The collected sensor data can be plottedover time, to see if the sensors’ measurements satu-rate and if so, the sensors ranges must be adjusted.Then, the tests must be repeated, until a satisfac-tory result is found. As result, it is possible to getthe ideal measurement range to use for each sensor.These values are shown in table 2.

4. Architecture DevelopmentTo approach the problem of the development of an in-tegrated architecture that accomplishes all the estab-lished pre-requirements, appropriate hardware mustbe used. The hardware’s features must include hard-ware PWM generation and two different communi-cation protocols: UDP to communicate with a re-mote PC and (I2C) to communicate with the IMU.It was decided to produce two different implementa-tions, based on two different approaches. Each one ofthe approaches, based in different types of hardware,was designed to accomplish the same objectives, butboth present different prospects of future develop-ment. The differences between the two approacheswill be discussed in the upcoming sections.

4.1. Solution based on Arduino UNO

To generate the hardware PWM waves in Arduino,one of the timers of the Arduino’s microcontrollermust be allocated to this functionality. For this, theopen source TimerOne library provides a collectionof routines that allow for a simple configuration ofTimer1, and offers a way to generate these kind ofsignals. However, this library is not provided by theArduino IDE, it is available in [5] and must be man-ually installed. This library is limited as it is onlycapable of generating the desired signals in pins 9and 10. Nevertheless, this is enough for the scopeof this work. The Arduino Uno board does not sup-port Wi-Fi communication. As so, a Wi-Fi shield isrequired. The shield used was the TinySine WIFIshield [6]. This equipment provides a way to com-municate to a local network by IP address, but the

communication between the shield and the Arduinomust be guaranteed through Software Serial commu-nication. For this purpose, the Arduino IDE providesthe SoftwareSerial library. The maximum baud ratesupported by the library is 115200 bps, according tothe official documentation [7]. This shield must bemanually configured. As a result of this work, a usermanual that explains this has been written. The Ar-duino IDE wire library allows for the access of all ofthe IMU sensors. By writing in specific sensors’ regis-ters, it is possible to choose the measurement rangesand other configurations. By reading other registers,it is possible to collect information about the sensors’measurements. The value of each DOF, of each sensoris outputted by two registers, one referent to the LessSignificant Bit and another to the Highest SignificantBit. This last value must be 8 bits shifted left, and theresult must suffer a logical disjunction with the LsBvalue. The resultant binary value must be convertedinto an integer, and multiplied by a scale factor togive a value with physical meaning. The solution isintegrated, and boxed in a 3D printed case, to conferdurability to the implementation, and presented tothe users as a single component that is easily pluggedinto the vehicle. The final architecture provided fromthis approach is represented in figure 4.

WiFi Bee

Arduino

GY-80IMU

GY-80IMU

System’sBattery

5

1 2 3

4

6

7

Figure 4: Arduino Based Solution final setup

Figure 4 illustrates the following steps:

1. A computer, running a Simulink solution, mustbe integrated in the same IP network as the Wi-Fi shield.

4

2. The computer is able to send UDP commandto a target IP. The Dynamic Host ConfigurationProtocol (DHCP) of the Wi-Fi shield must bedeactivated, and their IP must be set.

3. The UDP command message contains informa-tion about the PWM actuation signals. Thismessage is received by the Wi-Fi Shield andpassed to the Arduino trough Software SerialCommunication.

4. In the Arduino loop, this message will be re-ceived and if it is correct, the PWM commands’information will be given as input to the actua-tors, through the wire connections.

5. After the actuation, the Arduino sends I2C com-mands to each IMU sensor asking for measure-ments, and listens to the sensors’ measurementsfrom the I2C port.

6. The sensors’ data is converted into a decimalbase, and rearranged as a string. This stringis passed to the Wi-Fi shield using the Software-Serial port.

7. The shield sends the sensors’ raw measurementsto a target IP. The target of this informationmust correctly be defined by the user in theshield’s configuration.

8. The sequence of actions will be repeated in theloop as the vehicle is shut down.

4.2. Solution based on Raspberry Pi

The Raspberry Pi is a small sized computer and, assuch, it runs a full-blown operational system. There-fore, as opposed to what happens in the Arduino, it ispossible to choose what programming language to useto implement the individual solutions. For the pur-poses of this work, the Python language was used,due to its extensive libraries and tool boxes. Thepigpio library provides a way to generate hardwarePWM waves. This is an open source library writ-ten in C that relies on a Python module that allowsfor the control of the General Purpose Input Out-puts (GPIO) pins of the Raspberry. This resourceand its respective documentation are available in [8].The Raspberry Pi3 hardware already has Wi-Fi tech-nology incorporated, so no supplementary hardwarepieces are needed to implement UDP communication.To be able to implement this protocol, the socket li-brary must be used. This is a regular Python library,installed by default. To send and receive messages,two different sockets must be created, and the re-ception socket must be attached to the RaspberryPi’s IP and the local receiving port. To deal withthe GY-80 IMU implementation, there is an opensource library available [9]. This library can retrievethe IMU’s measurements, convert them into physicalunits and process them to get additional information.For this work’s purposes, some modifications to the

original library are needed. As there is a need tokeep the system universal to potentiate the most di-versified uses, it was defined that the output of theinstrumentation subsystem must be the sensors’ rawdata. It will allow the user to process data in the mostconvenient way to attend to their own purposes. Asin the Arduino solution, the solution is integrated,and boxed in a 3D printed case, to confer durabil-ity to the implementation, and is presented to usersas a single component that is easily plugged into thevehicle. The final architecture obtained through thisapproach is represented in figure 5.

GY-80IMU

GY-80IMIMIM

System’sBattery

5

1

2

3

4

66

Raspb

erry

Pi

66 Pi

Figure 5: Raspberry Pi Based Solution final setup

Figure 5 illustrates the following steps:

1. A computer running a Simulink solution must beconnected to the same IP network as the Rasp-berry Pi.

2. The computer is able to send UDP command toa target IP. The user must guarantee that theRaspberry Pi’s IP is defined to be static.

3. The UDP command message contains informa-tion about the PWM actuation signals. Themessages are received in the input socket, fromwhere they must be read. These command val-ues must be scaled after being received.

4. The Raspberry Pi actuates each one of the com-mands just by redefining the duty cycle for eachone of the pigpio classes.

5. An I2C interface is used to communicate witheach one of the IMU’s sensors and collect theirmeasurements. This functionality is imple-mented by the IMU setup library.

6. The sensors’ data is converted into a decimalbase, and rearranged as a string. This stringis written in the output socket, to be communi-cated to a target IP.

5

4.3. Simulink and User Interaction

The requirements of the system predict the use of aSimulink environment to provide to the user a possi-bility to interact with the system. As so, a Simulinkmodel was designed, to facilitate the system’s usabil-ity. The Simulink implementation will be divided in3 main blocks: The user interface, the setup blockand the communications block 6. The user interfaceallows for an easy use of the whole system. It out-puts the commands in a +/-1 range, where 0 in noactuation required, 1 is maximum actuation requiredand -1 is full reverse actuation required. This inter-action can be done just by inputting the values witha keyboard, by using a joystick or by using an in-teractive dash board panel. It is in this block thatthe users can integrate their own controller block, aslong as they always respect the output scale. Thesetup block is the one responsible for converting the-1 to 1 range from the user’s interface to a range ca-pable of being communicated to the communicationblock. The setup block also provides a graphical wayfor the user to choose the desired solution (Arduinoor Raspberry), and how to interact with the system(giving all the available options in the user interface).Based on the user’s choices, the setup block decideswhat scale change to apply to the user interface’s out-put, and defines the correct IP target, transmittingit to the communication block. As for the communi-cation, the UDP send block is provided by Simulinkand is available within the DSP system toolbox. Thisblock is easy to configure and use. The UDP block isonly capable of sending unsigned 8 bit integers. Thisrepresents a limitation in the commands allowed forcommunication, and requires a scale change processin the setup block. Figure 6 illustrates this process.

User Interface

Setup Block UDP Block

Remote IP

Remote Port

ControllerBlock

ADIS SystemPosition

IMU Raw Data

Figure 6: Insertion of the Controller in the Loop, using theSimulink environment.

5. Results of the Implementation

5.1. Results of the individual solutions

To validate the quality of the hardware PWM sig-nal generated in each solution, an oscilloscope was

used to visualize and determine the parameters ofthe output signals. The procedure is the same asin section 3.2. The results can be seen in table 3.The first consideration about the results is that inboth solutions the original wave presents a slightlydifferent behaviour. Both implementations were de-signed to produce a 10000 µs period wave. The re-sults are very similar to the intended ones, and inthe both cases the adopted solution provides a fullyusable method to actuate the motors.To validate the UDP communication systems, a sim-ilar test was performed for both solutions. This testconsists in communicating a sizeable message, alwaysin the same format, but numbered by order of com-munication, from the integrated solution to a remotePC. In the PC, the messages were received during acertain period and saved in MATLAB. Once the testwas finished, the messages received were processedto determine the communication frequency and thepercentage of lost messages. The results are summa-rized in table 4. In the raspberry Pi test, a delaywas inserted on the script to limit the maximum al-lowed frequency to 50 Hz. This decision was takenbecause, without this imposed limitation, the highcommunication frequency increases the percentage oflost messages. In the tests that were performed withthis limitation fixed at 100Hz, the percentage of lostmessages is close to 5%. The Arduino maximum al-lowed frequency occurs for the 115220 bps baud rateof the Soft Serial communication (results in table 4).As such, the 50Hz limit value was chosen to get simi-lar results in both solutions and to allow for the com-parison of both architectures. Analysing the resultsin the table 4 it is possible to see that the worst-case scenario occurs when the Raspberry Pi reachesa percentage of lost messages above 2.5%. However,this is within the requirements which means that thissystem is operational to be used.To validate the IMU measurements, two differenttests were performed with the IMU on-board the ve-hicle. In test 1, the car was at rest during 60 sec-onds. In test 2, the car was commanded to performcircular movements, always in the same direction, ata constant speed and with a constant radius, over20 seconds. During this time, the system was usedto collect data from the IMU and send it to the re-mote PC, where the data was processed and plottedover time. In test 1, it is expected that the actionof gravity on the car can be easily identified in theaccelerometer’s measurements. Since the vehicle wasstopped, gravity is the only force that affects the sen-sors and must be sensed in the z-axis, with a valueclose to 1g. See figure 7. The expected values for thegyroscope must be near 0 dps in all three axes as thevehicle as no angular rate (see figure 8). Finally, themagnetometer’s readings must be constant in time,since the relative position of the car to Earth’s mag-netic field does not change (figure 9).

6

Table 3: Results of hardware PWM waves generation

Original PWM Arduino PWM Raspberry Pi PWMFrequency 101.6 Hz 99.96 Hz 101 HzCycle Time 9846 µs 10000 µs 9900 µsDuty Cycle 15.21% 15.16% 15.76%High Pulse Width 1505 µs 1526 µs 1563 µs

Table 4: UDP communication results

Raspberry Pi Arduino (115200 Baud rate)

Frequency Percentage Lost Messages Frequency Percentage Lost Messages

10 seconds 48.8 Hz 1.02% 52.9 Hz 0.38 %1 minute 48.9 Hz 0.99% 52.8 Hz 0.5 %5 minute 48.7 Hz 1.49% 52.5 Hz 0.65 %

10 minute 48.2 Hz 2.61% 52.5 Hz 0.94 %

0 10 20 30 40 50 60Data sampling time [seconds]

-1.5

-1

-0.5

0

0.5

Spec

ific

For

ce [

g]

XX axis YY axis ZZ axis

Figure 7: Test 1: Accelerometer

0 10 20 30 40 50 60data sampling time [seconds]

-20

-10

0

10

20

Angular Rate [dps]

XX axis YY axis ZZ axis

Figure 8: Test 1: Gyroscope

0 10 20 30 40 50 60data sampling time [seconds]

-0.5

0

0.5

Magnetic Flux Density[G]

XX axis YY axis ZZ axis

Figure 9: Test 1: Magnetometer

The results of test 2 are displayed in figure 10 and 11,for the gyroscope and magnetometer, respectively.In the magnetometer’s readings, the x and y mea-surements present a sinusoidal behaviour. Becausethe vehicle performs circular moves, the sensor’s po-

0 2 4 6 8 10 12 14 16 18data sampling time [seconds]

-100

0

100

200

Angu

lar

Rate

[dp

s]

XX axis YY axis ZZ axis

Figure 10: Test 2: Gyroscope

0 2 4 6 8 10 12 14 16 18data sampling time [seconds]

-0.5

0

0.5

Magn

etic

Flu

x De

nsit

y[G]

XX axis YY axis ZZ axis

Figure 11: Test 2: Magnetometer

sition relatively to the Earth’s magnetic field is peri-odically repeated and, as such, the measured valueswill be periodically repeated too (one period corre-sponds to one complete lap).As for the gyroscope, because the vehicle has alwaysthe same orientation in the z plane (assuming noground inclination), it is expected that z measure-ments should be constant. This is verified as themeasurements in the z-axis vary a lot less than theother axes’ measurements. The gyroscope’s measure-ments also allow for the identification of the circularmovement, but there is no way to guarantee with acomplete degree of confidence that the IMU is per-fectly horizontal when placed in the vehicle. As thevehicle performed circular movements on a constantz plane (the ground), it is expected that the angular

7

Table 5: Comparison of the work frequencies of both solutions.

ArduinoOperation’s Frequency

Raspberry PiOperation’s Frequency

10 seconds 32.20 Hz 33.40 Hz30 seconds 32.56 Hz 33.70 Hz1 minute 32.95 Hz 33.18 Hz

10 minutes 32.33 Hz 33.38 Hz

rate measured in the z-axis would be larger than thatof the remaining axes, and it is. The mean value ofthe z-axis angular rate was determined as 129.4510dps, from the data presented in figure 10. Anothermethod to perform a rough calculation of the meanangular rate about the z axis is to determine thenumber of completed laps by observation of figure 11.Each lap is equal to modifying the angular position by360 degrees, and it is possible to see that the angularposition varied a total 7 × 360 degrees in 20 seconds(the vehicle performed 7 laps). So, a good estimate

for the angular rate is (7×360)20 = 126 dps, which is

very close to the mean value of the gyroscope mea-surements. In this way it is possible to validate theuse of all the three sensors in the system. However, itis possible to identify some noise mainly in the graph-ics related to the test 2, where the motor is working.Despite this, the data from these sensors are perfectlyusable, but requires filtering. The system’s users willneed to deal with that, according to their intentions.

5.2. Results of the Overall Architecture

With both architectures fully developed, it is impor-tant to compare them and analyse their performance.Several tests allow for the determination of the sys-tem’s work frequency. This is presented in tabl 5.The frequency values in table 5 already include theIMU raw data processing in the remote PC.The first comment is about the work frequency. Itis possible to see that the requirements are accom-plished as the work frequency is always above the 32Hz in all the performed tests (30 Hz was the pre-required value). The results from the Raspberry Pibased solution are marginally better than the Ar-duino Based solution. Detailed tests reveal thatthe processes that receive the UDP commands arethe most delayed processes in the Arduino architec-ture (limited by the Software Serial communication),while in the Raspberry architecture, the most delayedprocess is the access to the IMU sensors. These pro-cesses have margin for improvements, although thereis no benefit in improving the work frequency, be-cause at high frequencies the UDP communicationlosses increase considerably.With respect to hardware capabilities, some consid-erations must be performed. Due to the fact thatthe Raspberry Pi already supports WiFi features,no additional modules are required like in the Ar-

duino approach. It makes the setup of the Raspberryapproach easier, and the solution itself lighter andsmaller.The processing capabilities of the Raspberry Pi arebetter, however, to accomplish the purpose of thiswork, the Arduino microcontroller performance isconsidered to be enough. This specific difference be-tween the two approaches is directly related to theoption of developing the two alternative solutions.A bigger processing capability allows for a differentimplementation possibility. By integrating the con-troller in the Raspberry Pi’s internal script, insteadof a Simulink running on a remote PC, it is possiblemake the vehicle independent of the remote PC. Itrepresents an increase of the system’s autonomy.The number of channels where hardware PWM canbe generated is significant larger in Raspberry Pi,where all the 13 GPIO pins provide this feature,against the 2 digital pins (9 and 10) on the Arduinosolution. With 2 different waves it is possible actu-ate 2 different motors, and it is enough for the vehi-cle used, but can represent a limitation, if there areprospects to use the system to integrate more com-plex vehicles.The Raspberry Pi, being a computer, requires the useof computer peripherals, specifically a screen mustbe used for initial configuration and OS installation.It is possible to use a remote desktop software toremotely get access to the Raspberry’s OS, throughanother computer or a smartphone. The Raspberryalso requires more input current, which means lessautonomy if equal batteries are used in the two solu-tions.The costs of developing each solution are very closeand can not be considered to be a tiebreaking factor.

6. ConclusionsAs a result of this work, there are two independentarchitectures that allow for an integration of com-mercially available RF vehicles in a new concept ofRobotic Arena. Despite the fact that each archi-tecture was aimed at the same purposes and wasdeveloped to accomplish the same pre-requirements,both present different growth prospects. An Arduinobased approach aims for a more user friendly solu-tion but a Raspberry Pi based approach allows theuser to remove the remote PC from the equation andprovides the vehicle with greater autonomy.During the development stages of this work, a pre-

8

liminary version of the architecture developed wasused by a pair of students during practical OptimalControl classes, to design a position controller thatcommands the vehicle to perform a pre-establishedroute. It was an integral part of their final assess-ment and was the ultimate proof of concept and avalidation of the systems’ utility.

References[1] Traxxas Way. LaTrax SST Owner’s Manual, MODEL

76044-1. Traxxas Way, McKinney, Texas 75070, 2015.

[2] Analog Devices. Digital accelerometer adxl345, 2015. orig-inal document from Analog Devices.

[3] STMicroelectronics. L3g4200d mems motion sensor: ultra-stable three-axis digital output gyroscope, 2010. originalPreliminary document from STMicroelectronics.

[4] Honeywell. 3-axis digital compass ic hmc5883l, 2013. orig-inal document from Honeywell.

[5] Arduino official website. https://www.arduino.cc/. Re-trieved on February 2016.

[6] Tinysine Electronics. TinySine WIFI Shield User Manual,version 1.0. Tinysine Electronics, 2013.

[7] SoftwareSerial library’s official documentation. https:

//www.arduino.cc/en/Reference/SoftwareSerial. Re-trieved on March 2016.

[8] pigpio library. http://abyz.co.uk/rpi/pigpi. Retrievedon june 2016.

[9] Open source python library to IMU-GY80. https://

github.com/peterjc/longsight/blob/master/gy80.pyo.Retrieved on june 2016.

9