Swarming robots are becoming more common. Amazon has been using them for
several years to help workers fill orders
by automatically retrieving products
from warehouse inventory.
More recently, China has started
using them to sort packages to speed
deliveries. In the future, self-driving
cars will communicate with each other
using swarm technologies to improve
traffic flow and help prevent
As you would expect, many robot
hobbyists want to experiment with
this new technology. The problem, of
course, is that it can be expensive to
build one robot with reasonable
capabilities — building a swarm of
robots for experimentation can be
daunting for nearly any hobbyist.
One solution to this dilemma is to
utilize simulation software. I wanted
to use RobotBASIC (a free language
RobotBASIC’s simulated robot has all
the features needed (a camera for
detecting colors, perimeter sensors for
avoiding objects, a ranger to measure
the distance to objects, a simple GPS
for determining the robot’s location, a
compass that indicates the current
heading, and much, much more).
Unfortunately, though, RobotBASIC
was written to control only one
simulated robot at a time.
It is relatively easy, though, to
create multiple robots in RobotBASIC
by time-sharing them sequentially —
that is, showing all the robots but only
controlling one of them at a time.
The major goal of this article was
to create a template program that
makes it easy (and free) for hobbyists
to experiment with swarming robots.
A simple example application was also
prepared to demonstrate how easy
the program is to use.
One of the most important
capabilities of a swarm is the ability of
the robots to communicate with each
other. In a real world situation, the
robots might send messages to each
other using the Internet or perhaps RF
or infrared signals.
The actual medium used is really
irrelevant because the information
exchanged would just end up in
memory no matter how it was
transmitted. For that reason, the
simulation program simply stores the
information to be shared in an array
that can be accessed and modified by
any of the robots in the swarm.
For the demonstration program,
there will be four blue patrolling
robots in a swarm and one red
intruder robot as shown in Figure 1.
The intruder’s goal is to find its way to
one of the two safe zones located on
the left and right sides of the screen.
As mentioned earlier, the robot’s
movements will be time-shared with
each robot taking a turn in sequential
order. In order to give the intruder a
better chance to succeed, it will be
able to move a maximum of 75 pixels
on each move, but patrolling robots
will be limited to 50 pixels when
pursuing the red bot.
Providing such an advantage is
important because it increases the
need for a swarm.
Each of the blue robots will
initially patrol an assigned area by
moving in the five-sided pattern
shown in the figure (they must be
spread out because they have to
defend both goals from a variety of
directions). Half of the robots patrol in
in a clockwise movement; the others,
As they patrol, the blue bots will
“look” for the intruder, but their vision
is limited to a scan distance of 130
pixels. Increasing this distance
improves the chances the intruder will
be detected; decreasing it improves
the odds for the intruder.
Note also that there are many
green obstacles (perhaps shrubbery)
that the intruder can hide behind so
as not to be seen, or to make it
harder for patrolling robots to
approach and apprehend. It is also
worth mentioning that the patrolling
robots in this example only look in a
generally forward direction.
This means it is possible for the
When your application is best handled by a group of robots,
they may have to work together in a swarm to solve the
problem. The simulation program discussed here makes it
easy to experiment with your own swarm.
44 SERVO 10.2017