Arduino based I/O-system for rapid prototyping of robotic systems

Alexander Entinger1

Abstract— This paper presents a possible solution for thedifficult balancing act between abstraction and controllabil-ity developers face when designing a complex autonomoussystem. The problem can be tackled by creating dedicatedmicrocontroller based I/O-systems for achieving controllabilityof sensors and actors. Abstraction is provided by the use ofa C++ software framework which hides the communicationwith the microcontroller based I/O-systems and the concreteimplementation from the developer. Verification is achieved forthe complete system using unit testing methods known fromstandard software development.

I. INTRODUCTION

During the development of a complex autonomous systemtwo opposing design criteria have to be taken into consider-ation. An autonomous system should not only be able to runabstract and often ressource consuming algorithms as f.i. pathplanning, object recognition, etc., it should additionally beable to interface with various sensors and actuators requiredfor interaction with its surroundings. A typical approachtaken by system design engineers to solve this problem ispartitioning the system into two sub systems:

1) One or multiple embedded computers, often runninga UNIX derived operating system , e.g. Ubuntu, areused to run complex algorithms which do not need tointeract directly with the hardware. Algorithms can bewritten and evaluated in high level languages as f.i.C++, Python, Octave, etc.

2) Direct access of actuators and sensors is done by sep-arate microcontroller based I/O-systems. Since directaccess to the I/O-peripherals is necessary, low levelprogramming languages such as C and Assembly haveto be used.

This approach combines the advantages of both sub systems.The embedded computer operates on a high abstraction leveland can therefore take advantage of powerful commands. Ad-ditionally preexisting libraries , e.g. path planning libraries,can be integrated in the system control software to enhancefurther its capabilities. The microcontroller based I/O-systemoperates on a low abstraction level and is therefore able tointerface efficiently with actuators and sensors. This paperpresents a possible solution for a microcontroller based I/O-system. The focus is on providing a solution which can beeasily integrated into preexisting systems while keeping costsat a minimum at the same time.

The structure of this paper is as follows: After the intro-duction in Sec. I a general overview of the microcontroller

1Alexander Entinger is founder and chief executive officer ofLXRobotics GmbH Altenbergerstrasse 69, 4040 Linz, Austriaalexander.entinger@lxrobotics.com

baed I/O system and its capabilities is given in Sec. II. Theconcrete implementation is described in Sec. III. As shownin Sec. IV complete verification of both microcontroller I/O-system and C++ framework can be achieved by end-to-endverification using unit tests. In Sec. V the performance of themicrocontroller based I/O system is measured and possibleuse cases and applications are discussed. Conclusions aredrawn in Sec. VI.

II. OVERVIEW

An Arduino Uno board was chosen as the microcontrollerbased I/O-system. The reasons behind that choice are givenin Sec. III. Although there have been previous researchprojects involving the Arduino in context with robotics [1]there has been no research regarding the usage of the Arduinoas a tool for rapid prototyping. The Arduino communicateswith the embedded computer using a serial over usb connec-tion. Within the embedded computer the libary libarduinoiohides the communication protocol from the user and providesabstract functions to access the I/O peripherals of the mi-crocontroller. A graphical overview over the microcontrollerbased I/O system is shown in Fig. 1. The libary libarduinoio

main.cpp

C++ Project

libarduinoio

Executable

Embedded Computer

Arduino Uno n

Arduino Uno 1

Fig. 1. Overview over the modular microcontroller based I/O-system

in combination with customized firmware running on theArduino board provides the following functionality:

• A maximum of 6 analog inputs with a resolution of 10bits.

• A maximum of 12 digital inputs, with the possibility ofenabling or disabling a pullup resistors for each input.Additionally to the current pin logic level the microcon-troller based I/O system can detect the occurence of arising/falling edge since the last readout of the pin state.

• A maximum of 12 digital outputs.• A maximum of 2 hardware puls width modulation

(pwm) outputs. The pulse width can be set between a

duration of 1 and 2 ms with a resolution of 1 µs. Theperiod of the pwm signal is 20 ms and therefore ideallysuited to control common servo motors.

• A maximum of 6 software pwm outputs. The pulsewidth can be set between a duration of 1 and 2 mswith a resolution of 100 µs. The software pwm periodis equivalent to the hardware pwm period.

• The I2C-Bridge allows direct control of I2C baseddevices from the control software of the embeddedcomputer.

• A maximum of 2 counters for external events on twodistinguished pins. The counter can be configured toincrement on either a high-to-low or a low-to-hightransition.

• A hardware reset can be triggered using a softwarecommand.

• 16-Bit Board-ID to clearly identify the connected mi-crocontroller based I/O-system in a multi board envi-ronment.

• Retrieval of the chip temperature measured by theonchip temperature sensor. Since the chip does notheat up significantly during operation it can be usedto determine the environmental temperature.

III. IMPLEMENTATIONAt the beginning of this section the protocol used for com-

munication between the embedded computer and the Arduinoboard is documented. Afterwards the reasons for selectingthe Arduino as the microcontroller I/O-system as well as abrief overview over the tasks of the customized microcon-troller firmware are given. Finally the C++ framework whichenables the developer to access directly microcontroller I/O-functionality via abstract commands is described.

A. Communication protocol

The protocol used for communication between the em-bedded computer and the microcontroller I/O system is anextended tag-value-checksum protocol. The basic structureof the protocol is shown in Fig. 2. The symbols shown in

CT DT D0 ... Dn CS

1 Byte

Fig. 2. Basic protocol structure

Fig. 2 have the following meaning:• CT ⇒ Class Tag: This symbol describes to what

command class the following descriptor tag has to beassigned. In total six difference command classes doexist:

1) MISCELLEANOUS ⇒ This class contains allcommands which do not fit in any other class ,e.g. the hardware reset command.

2) GPIO ⇒ This class contains all commands tomanage the general purpose digital inputs/outputs.

3) ANALOG ⇒ This class contains all commands toaccess the analog inputs.

4) I2C⇒ This class contains all commands to accessthe I2C-Bridge functionality.

5) PWM ⇒ This class contains all commands tocontrol the soft- and hardware pwm outputs.

6) COUNTER ⇒ This class controls all commandsto access the two event counters.

• DT ⇒ Descriptor Tag: The descriptor tag providesa more detailed description of the command to beexecuted. Three types of descriptor tags are used:

1) A configuration tag implies that the data bytesfollowing the DT are used to configure the I/Ofunctionality of the command class specified bythe CT. A GPIO CT in combination with a con-figuration DT configures a certain digital pin aseither an input or an output.

2) A write tag implies a write command to the I/Ofunctionality of the command class specified bythe CT. A GPIO CT in combination with a writeDT can be used to set a digital output to a highor low level.

3) A read tag implies a read command to the I/Ofunctionality of the command class specified bythe CT. A GPIO CT in combination with a readDT can be used to read the logic level at a digitalinput pin.

• D0...Dn ⇒ Each command is further parameterisedwith up to n data bytes. The significance of the indi-vidual data byte is derived from the combination of CTand DT.

• CS⇒ Checksum: The checksum is calculated as shownin Eq. (1) using the logical XOR operation.

CS = CT ⊕DT ⊕D0 ⊕ ...⊕Dn (1)

The communication between the embedded computer and themicrocontroller I/O-system is implemented as a synchronousclient-server-system. The client (embedded computer) trans-mits a request to the server (microcontroller I/O-system)and waits for the response. A representative example for arequest-response pair is the retrieval of the Board-ID numberas shown in Table I and Table II.

TABLE IID REQUEST

CT 0x01DT 0x02CS 0x03 (CT ⊕DT )

TABLE IIID RESPONSE

CT 0x01DT 0x02D0 ID High ByteD1 ID Low ByteCS CT ⊕DT ⊕D0⊕D1

B. Microcontroller I/O-System

The selection of suitable hardware for the microcontrollerI/O-system was a crucial step for the development of themodular microcontroller based I/O-system. Criteria for theselection have been: availability, costs, support and extend-ability. The Arduino Uno microcontroller platform fullfillsall these requirements: It is widely used by professionalsand amateurs and can be purchased from multiple vendors.Because of its huge success it is safe to assume that theplatform will be available at least for the next couple ofyears. The typical Arduino Uno board can be bought forapproximately 22 e - depending on the vendor. Supportis provided by a continously growing online community.Most of the microcontroller pins are routed to standardizedpin headers. There are many extension boards commonlyknown as shields which connect to the standardized headersto provide additional functionality such as motor control, lcddisplay, etc. Furthermore the platform is completely openwhich means that both software and hardware are availableunder open source licences and can be modified to meetpersonal demands. For these reasons the Arduino has alreadybeen used in other scientific research projects as f.i. in [2].

The Arduino board is based on the Atmel ATMega328Pmicrocontroller which can be characterised as an 8 bit RISCprocessor. The board can be either supplied via USB orfrom an external power source. A Java based IntegratedDevelopment Environment (IDE) can be used for writingso called sketches in the Processing programming language.Virgin Arduinos come with a bootloader which allows directdownload of compiled sketches from the Arduino IDE tothe board. Alternatively, the processor can be programmedusing the 6-pin ISP-header (In-System-Programming) and anAtmel ISP mkII progamming device in combination with theAVR Studio IDE. The latter approach was chosen since itoffers greater flexibility in programme design as the ArduinoIDE which was developed with simplicity in mind.

Fig. 3. Sequence diagram of the customized microcontroller firmware

For the Arduino to serve as the microcontroller I/O-systemwith the functionality described in Sec. II a customizedfirmware has to be developed. The task of the firmware canbe broken down into three main parts :

1) After power up or a reset initialisiation of the micro-controller and its subcomponents is performed.

2) Receiving and parsing of the commands according tothe protocol. Upon the arrival of new data over theserial interface they are first stored in a FIFO. Oncethe main thread is ready to execute new commandsthe data are taken from the FIFO and processed bythe parser. The parser is implemented as a finite statemachine (FSM) and consists of one main and six subparsers. There is one sub parser for each commandclass. After decoding the class tag the main parserdecides which sub parser is responsible for furtherdecoding the command.

3) Execution of the commands and generation of answersaccording to the protocol. The selected sub parseris responsible for performing those actions. The subparser is implemented as FSM, too. The concretecommand to be executed is determined by the subparser after evaluating the DT and optional data bytes.

A sequence diagram of the firmware is shown in Fig. 3.The three main parts initialisation, parsing and execution arecleary identifyable.

C. C++ Framework

A C++ framework is used to represent the microcontrollerI/O-system within the embedded computer. Its main task isthe abstraction of the communication with the Arduino boardfrom the developer. Furthermore high level functions fordirect access to the I/O functionality of the microcontrollerbased I/O-system is provided. A representative example foraccessing the digital output pin D2 is shown in Listing 1.

Listing 1. Accessing the digital output pin D2 using the C++ framework

boost::shared_ptr<arduinoio::gpioOutputPin> oD2 =io.createGpioOutputPin(arduinoio::D2, false);

bool const success = oD2->setPinValue(true));

bool const pin_value = oD2->getPinValue();

The Arduino provides a total of 14 digital general purpose(D0 to D13) and 6 analog input (A0 to A5) pins. Of the14 digital pins only 12 can be used for the microcontrollerI/O-system because D0 and D1 are responsible for commu-nication with the embedded computer. Another constraint isthat not every I/O functionality specified in Sec. II can beused with an arbitrary pin of the microcontroller I/O-system.A mapping of I/O functionality to the microcontroller pin isprovided in Table III.

TABLE IIIMAPPING BETWEEN FUNCTIONALITY AND MICROCONTROLLER PINS

I/O Functionality PinsDigital Input D2 - D13

Digital Output D2 - D13Analog Input A0 - A5

Software-PWM-Output D2 - D7Hardware-PWM-Output D9, D10

I2C-Bridge SDA = A4, SCL = A5Counter D2, D3

IV. VERIFICATIONUnit tests are a method for software verification frequently

encountered in the world of software development and areused best to verify self-contained software modules. How-ever, the tight coupling between the C++ framework and themicrocontroller firmware circumvents an individual moduletest. A solution to this problem is to interpret the combinationof framework and firmware as one big module and test itusing its exposed interfaces. This approach shall be termedend-to-end verification. For the process to work an additionaltest dependent circuitry has to be added to the I/O pinsof the Arduino board. As test framework Google’s gtestlibrary is used to describe the test cases within the embeddedcomputer. Because testing the digital input/output pins provesto be quite easy, it will be used to illustrate the process ofend-to-end verification. As preparation the hardware pin D2has to be connected with D3, D4 with D5, ... , D12 with D13.In the test software all even pins are initialized as digitaloutputs while all odd pins are initialized as digital inputs. Arandom generator is used to generate signal patterns on thedigital outputs which are in turn read by the digital inputs andcompared within the test software. If the value written to theoutput does not match the value read by the correspondinginput an error has been identified and is reported by the testenvironment. To ensure maximum test coverage up to 1000random patterns are written to each pin.

While testing the digital I/O functionality shows no diffi-culty, verification for most other I/O functionalities is con-siderably harder to achieve. As an example the process forverifiying the analog input functionality shall be described.Since the Arduino microcontroller provides no direct option

2R 2R 2R

RUout

VCC

Bit 0(LSB)

Bit 1(MSB)

Fig. 4. R2R resistor network

for generating analog signals a R2R resistor network is usedto generate different voltage levels to be read by the analoginputs. An example for an R2R network using two digitalpins is illustrated in Fig. 4. The voltage generated at theoutput of the network can be calculated as stated in Eq. (2).

Uout = (B1 ∗ 21 +B0 ∗ 20) ∗ VLSB

VLSB =VCC

22(2)

This R2R network can be used to generate four differentvoltage levels. The Arduino has a total of six analog inputs,therefore twelve digital outputs are required to operate sixindependent R2R networks with a resolution of 4. Again arandom generator is used to provide randomly varying signal

patterns at the output pins. The voltage is measured by theanalog inputs and compared with the internally calculatedvoltage level. It is important to note that the quantificationerror eq as well as resistor value variations ∆R have to betaken into consideration when comparing the measured valueUOut,M with the internally calculated value UOut,C . This canbe handled best by allowing a small deviation of UOut,M

when comparing with UOut,C .

V. APPLICATIONSA key characteristic for the definition of possible applica-

tions for the microcontroller based I/O-system is the averagetime consumed by each I/O command. Table IV displays theduration of selected I/O commands. Configuration commands

TABLE IVDURATION OF SELECTED COMMANDS

Command Duration in msRead ID 4.15532 ms

Read temperatur 5.08272 msRead all analog values 6.49595 ms

Write pin value 4.64086 msRead pin value 4.6447 ms

Read analog value 5.00152 msI2C Write - 1 Byte 4.88282 msI2C Write - 4 Byte 5.65578 msI2C Read - 1 Byte 6.25022 msI2C Read - 4 Byte 6.73164 ms

have not been measured since they usually occur only onceduring the microcontroller based I/O system uptime. Thecommand duration has been determined by measuring thetime passed from call until return of the selected C++ frame-work I/O-function. From the values shown in Table IV it canbe concluded that the main purpose of the microcontrollerbased I/O-system are rapid prototyping applications in whichthe command execution time is not of utmost importance.Representative use cases are the control of servos, measure-ment of battery voltage, toggling of status leds, etc. Themicrocontroller based I/O-system is not suited to conductI/O operations under real-time conditions , e.g. reading outof four analog sensor values with a sampling period of 10ms. Despite those limitations the microcontroller based I/O-system proves its value when it comes to developing a roboticplatform from scratch.

Fig. 5. Mobile robotic platform Beauty Queen

In [3] a model car was converted into a remote controlledplatform for simultaneous localization and mapping using

the microcontroller based I/O-system to control the servosand speed controllers of the original model car. A picture ofthe system architecture is shown in Fig. 5. The system is re-mote controlled using a PS3-controller which communicatesvia Bluetooth with an embedded computer running RobotOperating System (ROS). For a brief introduction in ROSsee [4]. Within the embedded computer the PS3-controllercommands are transformed into pwm values required forcontrolling the servos and speed controller of the modelcar by a combination of three ROS nodes as shown in Fig.6. The node ps3 joy communicates via Bluetooth with thePS3-controller and publishes the controller data, e.g. positionof the joysticks and status of the buttons, to an ROS topicwhich is subscribed by ps3 teleop where the controller dataare transformed into abstract steering commands. Publishingdata to and subscribing data from an ROS topic is a commonprocedure to exchange data between nodes in ROS. Thesesteering commands are then used by the arduino uno 1 nodeto calculate concrete pwm values for the servos and speedcontroller. The pwm values are generated by the actor systemwhich is implemented as the microcontroller based I/Osystem described in this paper.

/arduino uno 1 node

/arduino uno 2 node

actor system

RT sensor system

IMU

wheel encoder

speed controller

/odometry node

/gmapping

/ps3 teleop node

/ps3 joy

/kinectKinect sensor

PS3-controller

Software

Hardware

(Arduino I/O-System)

steering servo,gearbox servo

Fig. 6. Beauty Queen system architecture

During the system architecture design phase it was plannedthat the real time sensor system should be implementedusing the exact same microcontroller based I/O system asthe actor system does. However, real time requirementsregarding sampling interval of the sensor data from theInertial Measurement Unit (IMU) and the wheel encoderscould not be met when using the microcontroller basedI/O system. Therefore a separate firmware was developedwhich samples the sensor data within the desired time limitand transmits it to the embedded computer where the ar-duino uno 2 node is responsible for signal conditioning. Thepreprocessed sensor data are then used by the odometry nodeto estimate the current position and orientation. The data ofthe odometry node are fused using the algorithm gmappingpresented in [5] with the data of the Microsoft Kinect sensorto form a digital representation of the robot’s environment.A typical map recorded by the system of a round course ina single family home is shown in Fig. 7.

Fig. 7. Digital map of a circular course in a single family home

VI. CONCLUSION

The microcontroller based I/O system proves to be a usefultool for using rapid prototyping techniques to build a roboticsystem. However, the long duration of a single commandlimits its application to cases where real time requirementshave not to be met. Therefore future efforts will focuson reducing the command duration time and extending themicrocontrolled based I/O system capabilities by migratingthe microcontroller I/O system to a more powerful hardwareplatform

REFERENCES

[1] Araujo, A.; Portugal, D.; Couceiro, M.S.; Rocha, R.P., ”IntegratingArduino-based educational mobile robots in ROS,” Autonomous RobotSystems (Robotica), 2013 13th International Conference on , vol., no.,pp.1,6, 24-24 April 2013 doi: 10.1109/Robotica.2013.6623520

[2] Costanzo, A., ”An arduino based system provided with GPS/GPRSshield for real time monitoring of traffic flows,” Application of Informa-tion and Communication Technologies (AICT), 2013 7th InternationalConference on , vol., no., pp.1,5, 23-25 Oct. 2013 doi: 10.1109/I-CAICT.2013.6722710

[3] A. Entinger, Mobile Robotik auf Basis des Robot Operating System:Prototyp-Entwicklung einer universellen Plattform fur Roboter mitKartografierungs- und Lokalisierungsfunktion, 2013.

[4] ROS: an open-source Robot Operating System Quigley, Morgan., Con-ley, Ken., Gerkey, Brian P.., Faust, Josh., Foote, Tully., Leibs, Jeremy.,Wheeler, Rob., and Ng, Andrew Y. ICRA Workshop on Open SourceSoftware, (2009)

[5] Grisetti, G.; Stachniss, C.; Burgard, W., ”Improved Techniques forGrid Mapping With Rao-Blackwellized Particle Filters,” Robotics,IEEE Transactions on , vol.23, no.1, pp.34,46, Feb. 2007 doi:10.1109/TRO.2006.889486