You are on page 1of 7

Proceedings of MUSME 2005, the International Symposium

on Multibody Systems and Mechatronics

Uberlandia (Brazil), 6-9 March 2005
Paper n. XX-MUSME05

Approaches for low-cost robotic prototypes

Mauricio J. Xavier de Souza, Bruno H. Leonardo F. Pacheco, Vinicius Moreira,

Mulina, Wanderson R. Miranda, Anderson M. Cardoso, Alessandro Angeruzzi
Márcio Taschelmayer, Flávio Seara, J.B. School of Computer Engineering –
Destro-Filho. Adriano A. Pereira Federal Univerisity of Uberlandia
Control Systems Laboratory – LASEC
School of Electronic Engineering –
Federal University of Uberlandia

Keywords: color-recognition, robotic arm, robotics, prototype.

In this paper we report the development of low-cost robots. In the first part, we describe the implementation of a
robotic arm for the recognition of object colours, classification and manipulation of those objects accordingly. A
servomotor geared robotic arm was built over a platform, on which a color video camera was also positioned,
connected to a frame-grabber in the computer that hosts the software for the system, in charge of analyzing the
data and deciding the movements that should be carried out by the arm. On the platform, wooden balls of
different colors, were positioned randomly. Plastic tubes, also of different colors were positioned in fixed
positions. In the second part, we describe a simple prototype of a robot-soccer player

Figure 1 – The Dalton Robot

Brain-machine interfaces and biological robots may be considered trends to current research on robotics, which
funds the implementation of new therapeutical procedures for several frontier problems in the medical sciences,
particularly rehabilitation and prostheses. However, the development of such complex strategies require a joint
multidisciplinary work involving scientists of different backgrounds, but especially a well-established infra-
structure on robotics. In this paper we report our first results to set up such infra-structure based on simple,
costless and flexible robots, so that to face budget limitations and to propose pedagogical strategies to be used in
undergraduate courses on robotics.



The implementation of the robotic-arm included building the arm itself, the platform over which it was built,
along with the video camera, and the circuitry involved in updating the robot position accordingly to the
computer’s decision, as seen on the next pictures.

Figure 4 – Circuitry of
the robot

Figure 2 – The robotic arm Figure 3 – Top view of the platform

The building of the arm was accomplished using Hitec RS-422 servomotors and aluminum links from Robix
didactic kits. Some adaptations were required to elongate the first link of the arm, in order for the two links (one
real link and a virtual one, as it will be seen ahead) to be the same size.
The platform was built using wood, including the support for the video camera, which later proved to be a bad
choice, since the support would bend, misplacing the camera’s positioning.
The circuitry included a level translator for adapting tension levels between the microcontroller and the
computer, and the peripherals required for the microcontroller itself. For the level translator, regular bc-337
transistors were used. A 7-segment display was also included for debugging purposes.

2.2.1. Acquisition
The recognition system is composed of a color video camera and a video capture card (BT878 chipset).
To establish the communication with the video capture card and to acquire the image, DirectX 9 (SDK) libraries
were used, specifically the DirectShow libraries. The entire project was developed using Microsoft’s Visual C++
IDE. The image is obtained continuously by the software, and a static capture is taken when the robot’s arm is
not interfering in the image.

2.2.2. Pre-processing
Each static image taken during the acquisition has its internal representation as a bitmap.
The search for the balls in the image is based in color match. To improve the recognition efficiency, we perform
a search in a sub-sample of the image, accordingly to the Nyquist-Shannon theorem. This theorem states that, for
a reasonable sampling of a signal, one should use the double of the maximum frequency found in that signal. For
example, if the highest frequency of a signal is 1kHz, then this signal must be sampled at 2kHz minimum.
Using this idea, and calling D the average diameter of the balls, just one pixel at each D/2 pixels were analyzed.
If this pixel is of one of the colors in the project, then the Sobel algorithm was used. This assures that every ball
within the average diameter considered will be found, and reduce the number of analyzed pixels. This sub-
sample is obtained “on-the-fly”.
After finding one pixel of a ball, the borders of this balls are detected by the Sobel edge-detection indicators, also
calculated “on-the-fly”. The Sobel Edge Detector uses a simple convolution kernel to create a series of gradient
magnitudes. Applying convolution K to pixel group p can be represented as:
1 1
N ( x, y ) = ∑ ∑ K ( j, k ) p( x − j, y − k )
k = −1 j = −1

So the Sobel Edge Detector uses two convolution kernels, one to detect changes in vertical contrast (hx) and
another to detect horizontal contrast (hy).
 − 1 0 1 − 1 − 2 − 1
 − 2 0 2 ,  0 
hx 
=  hy  0
= 0
 − 1 0 1   1 2 1 

Figure 5 – Sobel Edge Detection algorithm example: the original
image, the horizontal detection and the vertical detection

2.2.3. Recognition
After image acquisition in the pre-processing, to every presumed ball we have a group of points in its borders in
diametrically opposed pairs. The center of the ball is easily found with a 1 pixel approximate error.
Each ball will go through a new color match step, were just the system cataloged colors will be actually
recognized (and every other color will be ignored).

Figure 6 – Right hand side view: the robot in action

2.2.4. Coordinates translation

After the ball’s recognition, the software only knows the center position of each one of then, and its color.
As the physical robot is modeled under real world coordinates, a translation between the ball’s position in pixels
and its correspondent positions in centimeters in the real world is needed.
The values of the position of the robots origin and the scale are configurable.
Calling XO the origin of the arm, XP the pixel value of the X coordinate of the ball and XR the X value in
centimeters of the ball, we have:
XR = (2)
Where Factor is the scaling factor between the real world coordinates and the pixels. In our project, its value was
6.65, since 233 pixels of the image where used to represent 35 centimeters of the real world. The same equation
was used for the Y coordinates.
A spherical distortion in the camera’s image jeopardized the reliability of the coordinates’ translation, and the
immediate solution adopted was reducing the working area of the robot to sizes of acceptable errors.

2.2.5. Control
The angles that should be performed by the arm were calculated through trigonometrical equations of inverse
kinematics, from the real positions of the center of the balls. As the arm has three possible movements (shoulder,
elbow and wrist, in Figure 7a), the most immediate representation would be a three degrees of liberty robot, as
shown in Figure 7b, but considering the last link of the arm as a fixed joint, that should be positioned parallel to
the platform in order for the robot to capture a ball, we can simplify the scheme to a two degrees of liberty robot,
as shown in Figure 7c. Using this simplification and observing that the two links of the robot (one “real” link,
between the shoulder and the elbow, and another “virtual one between the elbow and the claw) are of the same
size, we have an isosceles triangle, whose base is variable but is known (the distance of the origin of the arm and
the ball), and two fixed equal sides (the links). Now it’s easy, using trigonometrical equations, to determine the
two angles that should be performed by the arm.

Figure 7a - Top view of the arm Figure 7b – Representation of the arm Figure 7c – Simplification of the arm as
as a 3DL robot a 2DL robot

There’s also a definite order to catch the balls, giving the Dalton robot a deterministic and predictable behavior,
which helped during the development in the error detection and correction steps.

The communication between the robot and the host PC was established using the serial port of the computer. A
communication protocol was defined, including error detection parameters. Just two bytes (at best) are needed to
determine the movement of each of the robot’s joint.
As four simultaneous pulses are needed, with frequencies of 50Hz, to maintain the position of the
servomechanisms utilized in the arm, we’ve decided to use a PIC microcontroller. The utilization of the
servomechanisms, which gives a better movement precision and easier control when the end point is known,
requires the generation of a 50Hz pulse for each motor, whereas an update of the motor position is needed or not.
In the absence of pulses for a long period of time (bigger than some 50Hz cycles) can cause the loose of
tightness of the joint or even cause unexpected movements. The generation of the pulses directly in the host
computer would bring up problems, considering the real-time requirements of the system. Thought, we’ve
decided to use a microcontroller to generate the pulses, while the computer would be responsible to update the
positions as necessary.

Figure 8 – Pulses generated by the microcontroller. The minimum pulse width of 0.9ms moves the
servomechanism to its minimum counter-clockwise position, while the maximum 2.1ms pulse moves it
to the maximum clockwise position. After generating the fourth pulse, the microcontroller checks for
serial data available and makes any changes needed for the next pulse cycle.

In order to generate the four pulses in continuous mode, the microcontroller would receive data from the
computer, using the established serial protocol. This one supposes the first byte indicates what would be the next
motor to have its position changed. After that, a second byte, indicating the absolute position to where that
previous defined motor would move. The microcontroller echoed every received byte, avoiding communication
For the microcontroller being able to receive the data coming from the computer through the serial port, an
amplitude conversion should be performed, as the RS-232 protocol, used by the computer, works in the -12/12V
band, and the TTL protocol, used by the microcontroller, works in the 0/5V band. Many integrated circuits could
perform this operation; however, an analog circuit was built, since it’s easy to assemble.



In robot soccer, there is not a standard norm that establishes a protocol for the data transmission linking the
control computer to the robots. There is just a recommendation regarding electromagnetic interference, so that
the local norm is respected. Consequently, there are several possibilities for the implemenmtation of the data
transmission, which have been carefully analysed and tested.
In our first approach, we tried tree types of transmission: infrared (IF), ultrasound and radiofrequency (RF)
transmission. Although IR transmission presents low cost and its implementation is very simple, the transmitter
must be physically directed to the receiver, thus making it unfeasible since there are 4 players in the robot soccer
team. Electrical noise and voices of people nearby the soccer field represent the major disturbances imposed on
ultrasound transmission system. In this case, it should be also considered that the echoes of the transmitted
signals may be perceived by the robots, thus leading them to repeat a previous control instruction. For RF
transmission, although the implementation costs are higher, all the problems associated with IR and ultrasound
systems could be managed in a simple way, since there are several standard modules devoted to this kind of data
transmission. Notice also that these modules are small, so that fit quite well to the reduced size imposed by the
robot soccer norm on the players. In addition, most of the teams in the literature make use of RF transmission,
which was finally chosen as the data exchange technique for our team.
Our RF circuit operates with acarrier frequency of 315 MHz, maximum data transmission rate up to 2 kHz, so
that the nearest practical transmission frequency is 1200 bps (bits per second). The receiver and the transmitting
circuits are shown respectively at Figure 9 and Figure 10.
The major problem associated with RF circuits are noise, leading to a changement in the transmission protocol,
so that most of time the receiver circuitry processes data, even if it is not connected to a specific command.

Figure 9 - Receiver circuit

Figure 10 - Transmitting circuit

3.1.1. The transmitting circuit

This circuit (Figure 11) is composed of the RF transmitting module, a rectifying diode in order to process the
signal incoming from the serial port of the computer and an antenna.

3.1.2. The receiver

The size of the receiver (Figure 12) was greatly reduced by the module. In the following, data are processed by a
PIC16F84A-10 (Microchip Inc.) circuit, which is programmed by means of C language, in order to activate

Figure 11 - Final transmitter module

Figure 12 - Final receiver module


The prototype robot was developed to the first tests of the robot’s behavior and movements. Although it has not
been tested with the team control software, its behavior is reasonable with manual control software, attesting that
such approach enables the development of the other robot-players.
The prototype presents two independent DC motors: Consequently, it can moves easily and it is able to turn on
its own center, for example, when the motors are told to run in opposite directions.

3.2.1. Motors

In order to build the prototype, we made use of DC motors from old CD-ROM drivers, operating with 6Vdc,
mechanical reductions to slow down final speed and increase torque. Despite of the reduced size of the motors,
they provide a reasonable torque. Notice that other motors were tested and evaluated, however they did not
perform well in terms of size, torque or electrical tension requeriments.

3.2.2. Power supply

Five 1.2V Panasonic rechargeable batteries, with 1.2Ah charge, were used. The project allows batteries changes
without any additional change to be made, as long as the size of the batteries remain the same.

3.2.3. Chassis

The chassis were built using fiberglass, which offers a good resistence to impact and little aditional weight to the
prototype. Any adittional weight would reduce the prototype speed and increase power consumption. The motors
are attached to the base of the chassis, the batteries are in a second plane, and the eletronic circuitry in a third

3.2.4. Motors driving

To drive the motors, a Texas Instruments quad half H-bridge chip, SN754410NE, was used. This chip can
operate with 4.5V to 68Vdc supply voltage to the motors, at one Ampere of current source, and a separate logic
voltage supply. As we need a full H-bridge per motor, the two motors used for the prototype can be driven using
only one chip. A onboard heat dissipation layout had to be used, since operating power dissipation can lead to
high temperatures.

3.2.5. Control

The control of the transmitted signals and the speed of the motors is made with a Microchip PIC16F84A
microcontroller. A system using Microchip PIC12F675 is being developed, to take advantage of its small size
and reduced price.


The microcontroller software analyzes the received byte as follows:

• The first two bits (MSB) indicate the robot that is being addressed, so that each robot just analyzes
bytes sent to it;

• The next three bits indicate the driving of the first motor. The first bit indicates de direction that the
motor should move, and the other two indicate the speed of the motor;
• The last three bits follow the same rules to indicate direction and speed for the second motor.
With this protocol, four robots and eight speed levels (including a “stop” level) for each motor can be controlled.

Figure 13 – Data format


In terms of the Dalton robotic arm, the major conclusions follow. By using a selectable color detection band, the
occurrence of false-positive and false-negative recognitions could be minimized. The use of the red, green and
blue colors, over a black platform, each one represented as a different channel in computer color bitmaps, also
helped minimizing recognition mistakes. A white ball was also used during the tests to detect false-positive
recognitions and, with the detection band configured accordingly, no mistakes of the system were detected.
As a result from the first project, the research group is now working to develop a complete robot-soccer team,
which is described in the second project. The complete image-recognition module developed for the Dalton
robot is being used, as the robot-soccer team relies on color recognition for identifying the ball, the players and
the limits of the playing field. Also, the communication between the players and the host computer in the robot-
soccer is made through radio-frequency, which was previously tested at Dalton’s Robot platform and proved to
be trusty.
In the second project tests, we could analyze the performance of the RF module used for our prototype. First of
all, being a simple model, the module was very susceptible to transmition noise. If the delay between each
transmission was bigger than 20 milliseconds, the RF receiver would interpret noise as incoming data. This
problem was solved re-sending the last valid byte every 15 milliseconds, so that the robots wouldn’t act in a
unpredictable way, still preventing the RF receiver to accept noise as data.
The distance between the RF emitter and the receiver, in order to keep noise under acceptable levels, is just
around three meters. Above that, the noise started to jeopardize the communications. However, this distance
could be extended by one meter if there were no obstacles in the way.
The noise generated by the motors also implicated in some aditional adaptations to the prototype. One
independent power supply had to be used to the eletronic components to solve this problem.
Finally, the prototype has served to our expectations on building a low cost soccer play robot, as we used
materials we already had or found materials that would be useless anywhere else. Surely, in order to achieve a
competitive robot, we still have to develop the idea of a better RF link, with better noise immunity.

The development of the systems – the Dalton Robot and the prototype of the robot-soccer player – would not be
possible without the support from the Department of Biomedical and Automatic Control Engineering; as well as
the Research Funding Agency of Uberlandia (FAU), which provided the budget for all material required for this
project. We also acknowledge companies as Texas Instruments, who provided us with free samples of electronic
components; and Panasonic, who gently supplied us with the battery packs.

on September 9, 2004;
Shannon_sampling_theorem, on September 9, 2004.