XXX-X-XXXX-XXXX-XXXXX.00 20XX IEEE Terrestrial Drone Creation from Rover, Robotic Arm [602264]

XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE Terrestrial Drone Creation from Rover, Robotic Arm
and Raspberry PI

Roland Szabo
Applied Electornics Department
Faculty of ETcIT
Polithenica University Timisoara
Timisoara, Romania
[anonimizat]

Abstract—This paper presents the creation steps and
components of a terrestrial drone. The drone is cre ated from a
rover, a robotic arm and a Raspberry PI. The rover and
robotic arm are from Lynxmotion. The rover has four motors
and the robotic arm has five motors which needs to be
controlled. The "brain" of the whole system is a Ra spberry PI.
The rover has an "eye" too, it has a web camera to have the
possibility to drive it on places where it cannot b e seen by the
operator. The rover has "ears"and "mouth" too be ab le to
hear and speak. The operator can speak and it can b e heard by
the persons near the rover and the operator can hea r the noises
around the rover. The rover has a microphone built in the
webcam and a separate speaker on audio interface. T he rover
can be controlled by an operator via Wi-Fi using a Linux
machine. The computer needs to have also a speaker and a
microphone connected to it, in order to be able to transport
voice though the wireless interface, to be able to speak and
hear with the rover. The rover it's controlled with a Python
application using the arrows from the keyboard and the
robotic arm is controlled with the computer's mouse . The
image from the video camera from the rover is sent back on
wireless interface and shown in a windows to the op erator in
order to be able to drive the rover.
Keywords— embedded; robotic arm; rover; terrestrial
drone; wireless.
I. INTRODUCTION
Robotic systems are quite popular in our days' [1]. In the
last years even more popular became the drones, mos tly
quad copter type of drones, but not only. The drone s have
the advantage that they are robotic systems, buy wi th a
touch of human intervention. The popularity of the drones
and the frequent usage of them came from adding a c amera
to the robotic system [4]. The video camera is very popular
in today's social media oriented world, cameras can be
found on smart devices, like smart phones, tablets, smart
watches. Putting a camera to a robotic system made possible
of taking pictures [5] very hard to achieve before, because a
flying drone can take pictures from the sky and a t errestrial
drone can take pictures in places where a human can not fit
in or it would be too dangerous to go in.
The concept of the drone came from merging a video
camera with a robotic system [6] which can be contr olled by
an operator from a PC, smart phone, tablet or even a smart
watch. II. PROBLEM FORMULATION
The concept of creating a drone in our laboratory w as an
old plan, but it needed to wait until some technolo gies
appeared in the industry [2], in order to have an
accomplishment. It needed to appear some embedded
devices like Raspberry PI, power banks for powering the
system, small Bluetooth speakers with battery power and
other technologies, which became popular in the con sumer
market in the last years [3]. In the laboratory the re were the
main components for creating the terrestrial drone, it just
needed to be assembled. There was the rover and the robotic
arm [7] from Lynxmotion and also the Raspberry PI s mall
computer, which could act as the "brain" of the who le
system. the Raspberry PI was a key component of the
system, because if we go back only ten years ago, a complex
robotic system, which needs video processing, can h ave for
the "brain" a small 10 inch laptop, which could be quite big
in some specific applications.
III. PROBLEM SOLUTION
All the main components were present in the laborat ory,
like the rover and the robotic arm from Lynxmotion and the
Raspberry PI for the brain, only some small compone nts
needed to be acquired, like the power bank, the Blu etooth
speaker with battery, web camera, USB to serial con verter
and the USB Wi-Fi adapter.
The biggest challenge was powering the system [8],
because it had nine motors (four motors on the rove r and
five motors on the robotic arm) which needed to be driven
and an embedded computer [9], [10] which needed to be
ran.
For the "brain", it was chosen the Raspberry PI 2 m odel,
because of more considerations. It was needed a sys tem with
more than two USB ports, because of the big number of
peripherals. Adding a USB HUB would consume more
power and space and an externally powered USB HUB
would require an additional battery, this way the R aspberry
PI 1 was out of the question, not to talk about the small
frequency of 700 MHz single core. It was not used t he
Raspberry PI 3, due to more facts, one that in that time of
creation of the drone it did not appeared, but even as an
upgrade would not been a good solution. The reasons are
more, the Raspberry PI 3 has a bigger power consump tion,
than Raspberry PI 2 ,the same number of USB ports, but
only slightly bigger processing power (1200 MHz qua d core

for the Raspberry PI 3 and 900 MHz quad core for th e
Raspberry PI 2), which did not influenced too much the
rover construction. The Raspberry PI 3 had some adv antage
by having Wi-Fi and Bluetooth on board, but using a n SMD
shared antenna for the two wireless interfaces made its
range distance small, so and external USB Wi-Fi don gle
with external wireless antenna can significantly in crease
reach distance, which is critical for a drone mostl y in the
case where there are no wireless repeaters on the W i-Fi
network in the path where the rover is driven.
On Fig. 1 can be seen the block diagram of the terr estrial
drone. It can be seen that the brain of the system is a
Raspberry PI 2 which has connected an A+ 10000 mAh
power bank to keep it alive for a long time. The po wer bank
has a blue LED ant it's glued under the rover, so t he car has
a blue light under it, so the battery it's not only functional,
but makes the rover look better. There is a speaker
connected on the audio interface. The speaker is a Bluetooth
speaker with battery. The speaker was a good choice ,
because it had it's own battery and amplifier. It w as used on
the audio interface, not on Bluetooth, because the distance
from the Raspberry PI 2 it's small and the connecti on setup
was easier this way, not to mention that the Raspbe rry PI 2
does not have a Bluetooth interface built on board. The
Raspberry PI 2 has four USB ports. In one port is p lugged
the TP-LINK TL-WN722N USB Wi-Fi dongle, in other th e
Digitus DA-70156 USB to serial adapter, in other is the
Logitech c270 webcam and one it left free for a sec ond
Logitech c270 webcam. One problem with the USB port s,
which had to be solved, was that the USB ports are crowded
quite closel,y and to be able to plug in the USB ad apters which are quite big, it was needed a USB extension cord.
Not all extension cords have a good quality, becaus e most of
them can only extend the 5 V power supply from the USB
port and not the data communication. Data communica tion
is crucial, because there is Wi-Fi data communicati on,
webcam image transfer and serial data communication . It
was used the one shipped with the Digitus DA-70156 USB
to serial adapter. It was used a USB to serial adap ter, and
not the UART interface from the Raspberry PI 2, fro m more
reasons. One of it that is more compact and robust, because
it is in a case, not some wires connected to the Ra spberry PI
2, which on a moving car can break. The Raspberry P I 2 has
an UART interface which needs a MAX 3232 level shif ter,
which would be an extra circuit with no case, the U SB to
serial adapter had all of it inside a case. Finally we have the
serial connection to the Lynxmotion 4WD1 Rover and
AL5B robotic arm. The serial connection is with the help of
a Pmod RS232, because the AL5B robotic arm had the SSC-
32 servo control board, which can control up to 32 servo
motors, more than enough for the nine motors needed to be
controlled. The serial interface on the SCC-32 boar d has the
ST202EC serial transceiver, which cannot be control led by
low power devices like the Raspberry PI, only with PC, but
if the circuit is rerouted and instead of the seria l interface it's
placed a Pmod RS232 from Digilent, which has the
ADM3232E serial transceiver, the serial communicati on can
be done even which low power devices like the Raspb erry
PI. The serial communication of the drone is done w ith the
SSC-32 board, but for the four motors on the rover there is
motor driver called Sabertooth. The rover needed a 12 V
power supply and the robotic arm 6 V power supply.

Fig. 1. Block diagram of the terrestrial drone system.
This was solved by connecting eight pieces of 1.5 V
batteries to the rover and four pieces of 1.5 V bat teries to the
robotic arm, so a total of twelve 1.5 V batteries i nside the rover's body. There can be used also rechargeable, batteries,
but it was not the best solution, because that kind of batteries
have 1.2 V, this way more pieces of batteries were Wi-Fi microUSB USB
USB USB RS-232 Peripheral
PC Lynxmotion 4WD1
Rover + AL5B
Robotic Arm Pmod
RS232
A+ 10000 mAh
Power Bank Digitus DA-70156
USB to Serial Logitech
c270
Webcam
TP-LINK TL-
WN722N USB
Wi-Fi Raspberry PI 2
Audio
Speaker

needed(fifteen pieces), more cables were attached, to achieve
the same voltage, this way the battery resistance g rew and the
system ended up to be worse than with normal batter ies. The
better solution with rechargeable batteries were th e batteries
from Lynxmotion, which were designed especially for these
robots. Finally the system had twelve 1.5 V batteri es (12 V + 6
V), one 5 V power bank and 3.7 V built-in battery f or the
speaker, in other words the battery usage was big, but also the
system was complex, nine motors to drive, webcam wi th
microphone, USB to serial dongle, Wi-Fi adapter, sp eaker
with amplifier and the Raspberry PI 2 small compute r.
On Fig. 2 it can be seen the user interface of the first
implementation in Python, which could preview the w ebcam's
image and control the rover. The webcam's image is
previewed with OpenCV and the interface was done us ing the
Qt GUI (graphical user interface). The GUI has only control
for the rover to left, right, forward and backward.
The communication was done via Wi-Fi, so a router w as
also used. The computer connected to the Raspberry PI via a
router. The audio was transferred via Wi-Fi also. T he speaker
is mono, but if there were place two Logitech c270 webcams
on the drone the heard noise, could be in stereo, b ecause each
webcam has a built-in microphone.
Fig. 2. Rover control application on Raspberry PI with Open CV camera
preview
On Fig. 3 it can be seen the GUI of the drone contr ol
application in Python using the Tk GUI elements.
The application can preview the camera image of the rover
and can control the rover to left, right, forward a nd backward
and can control each motor of the robotic arm. The control of
the rover is done by keyboard and the robotic arm i s moved
with mouse, the sliders show only the position of t he motor.

Fig. 3. Drone control application on Raspberry PI with Tk g raphical user interface
The SSC-32 servo control board receives a number
between 500 and 2500 in order to know how much to m ove.
These numbers encode the width of the PWM generated to the
motors by the SSC-32 servo control board. The servo motors from the robotic arm are blocked mechanically so th ey can
move only between 0ș and 180ș.
On the equations there was computed a relation betw een
the numbers sent to the robot and the angle movemen t of the
servomotors.

/g2009= ∆/g2033
180°−0°= 2500 −500
180°−0°=
=11 ,/g46661/g4667 /g1870/g1867/g1854/g1867/g1872/g1861/g1855 /g1874/g1853/g1864/g1873/g1857/g1871 (1)
Using the equation (1) it can be computed the equat ion (2).
1°~11,(1) /g1870/g1867/g1854/g1867/g1872/g1861/g1855 /g1874/g1853/g1864/g1873/g1857/g1871 (2)
The numbers were concatenated in the #5P1500S1000\r
form and were sent to the robot as SCPI (Standard C ommands
for Programmable Instruments) commands via serial i nterface.
Here the number after # is the number of servomotor , the
number after P is the movement position (PWM width) and
the number after S is the timing, 1000 means the mo vement is
done in 1000 ms and \r is carriage return.
On Fig. 4. it can be seen the assembled drone, whic h was
driven in the laboratory.

Fig. 4. The assembled drone in the laboratory IV. CONCLUSION
As it was presented, a terrestrial drone was create d, with
various parts. The drone has video camera feed-back , but also
bidirectional sound. The drone has a rover part and a robotic
arm part. The drone can be used to handle different objects
where a human operator can not fit in or it too dan gerous to go
in. The system is driven by a Raspberry PI 2 comput er. The
drone is quite complex, due to the fact that bidire ctional sound
was added to it.
The biggest challenge was the battery management, w hich
was solved quite well, but further improvements can be also
made.
Further enhancements could be to increase the numbe r of
cameras for better visibility.
The most interesting upgrade could be to change the rover
with a CH3-R hexapod, and place the robotic arm on the
hexapod. This way the hexapod can get even in rocky places
which are harder or impossible to be reached by a r over.
REFERENCES
[1] Wong Guan Hao, Yap Yee Leck, Lim Chot Hun, “6-DOF P C-Based
Robotic Arm (PC-ROBOARM) with efficient trajectory planning and
speed control,” ICOM 2011 – 4th International Confe rence On
Mechatronics, Kuala Lumpur, Malaysia, May 17-19, 20 11, pp. 1-7.
[2] Woosung Yang, Ji-Hun Bae, Yonghwan Oh, Nak Young Ch ong, Bum-
Jae You, Sang-Rok Oh, “CPG based self-adapting mult i-DOF robotic
arm control,” IROS 2010 – IEEE/RSJ International Co nference on
International Conference on Intelligent Robots and Systems, Taipei,
Taiwan, October 18-22, 2010, pp. 4236-4243.
[3] E. Oyama, T. Maeda, J. Q. Gan, E. M. Rosales, K. F. MacDorman, S.
Tachi, A. Agah, “Inverse kinematics learning for ro botic arms with
fewer degrees of freedom by modular neural network systems,” IROS
2005 – IEEE/RSJ International Conference on Interna tional Conference
on Intelligent Robots and Systems, August 2-6, 2005 , pp. 1791-1798.
[4] N. Ahuja, U. S. Banerjee, V. A. Darbhe, T. N. Mapar a, A. D. Matkar,
R.K. Nirmal, S. Balagopalan, “Computer controlled r obotic arm,” 16th
IEEE Symposium on Computer-Based Medical Systems, N ew York,
NY, USA, June 26-27, 2003, pp. 361-366.
[5] M. H. Liyanage, N. Krouglicof, R. Gosine, “Design a nd control of a
high performance SCARA type robotic arm with rotary hydraulic
actuators,” CCECE’09 – Canadian Conference on Elect rical and
Computer Engineering, St. John's, NL, USA, May 3-6, 2009, pp. 827-
832.
[6] M. Mariappan, T. Ganesan, M. Iftikhar, V. Ramu, B. Khoo, “A design
methodology of a flexible robotic arm vision system for OTOROB,”
ICMET 2010 – 2nd International Conference on Mechan ical and
Electrical Technology, Singapore, September 10-12, 2010, pp. 161-164.
[7] Guo-Shing Huang, Xi-Sheng Chen, Chung-Liang Chang, “Development
of dual robotic arm system based on binocular visio n,” CACS 2013 –
International Automatic Control Conference, Nantou, Taiwan,
December 2-4, 2013, pp. 97-102.
[8] M. Seelinger, E. Gonzalez-Galvan, M. Robinson, S. S kaar, “Towards a
robotic plasma spraying operation using vision,” IE EE Robotics &
Automation Magazine, vol. 5, issue 4, 1998, pp. 33- 38, 49.
[9] R. Kelly, R. Carelli, O. Nasisi, B. Kuchen, F. Reye s, “Stable visual
servoing of camera-in-hand robotic systems,” IEEE/A SME Transactions
on Mechatronics, vol. 5, issue 1, 2000, pp. 39-48.
[10] V. Lippiello, F. Ruggiero, B. Siciliano, L. Villani , “Visual Grasp
Planning for Unknown Objects Using a Multifingered Robotic Hand”,
IEEE/ASME Transactions on Mechatronics, vol. 18, is sue 3, 2013, pp.
1050-1059.