Kenshow Large

13016784

UFMFNF-15-3

PROBABILISTIC ROBOTICS

AUTONOMOUS CLEANER ROBOT

Introduction
Throughout this project report, I hope to show my understanding of PlayerStage,
accompanied with MATLAB, and their combined use to simulate real-world
Robotic projects and systems that include the implementation of mobile robots,
various types of proximity sensing, and simulated real-world noise to accurately
predict the actions and reactions of the robot system.
For this project specifically, I will report as if hired by Tyson Incorporated
who specialise in floor cleaning machines to modify and improve their existing
mobile warehouse cleaning robot to allow for automated operation.
In order for my autonomous modifications of their robot to be successful when
implemented in the real world, I will have to consider real world problems such
as cost, computational power and any sensor noise due to sensor accuracy and
other factors that may cause errors in both the topology and sensors of the
robot.

Requirements Analysis
In order for Tyson Inc. to improve on their current solution of running the mobile
robot on a pre-programmed path, the company has conducted several
investigations in order to find improvements, of which they have chosen four
main points that they feel are of most value. In this section I will cover each of
the 4 improvement suggestions, with solutions and issues in each.
Suggested improvement [1]
The platform should be able to move freely around the warehouse without the
need of a pre-programmed path or remote control.
This suggestion dismisses the current solution Tyson Inc. has put in place,
and summarises the main attribute of an autonomous mobile robot the lack of
a driver or hard programmed path. Currently, the robot has only a single front
proximity sensor which is not sufficient enough to be able to fully read the
surrounding environment effectively. This means that implementing additional
sensors onto my robot would be necessary.
This suggestion could be implemented using a very simple reactive robot
algorithm that detects and avoids walls and other collisions. We can use a
reactive program due to the fact that knowing its exact location in the
environment is not specifically listed as being necessary for this suggestion. A
purely reactive algorithm would likely prove to be highly inefficient, with many
gaps and repeated pass-overs. As well as this, it would not be able to navigate
automatically back to its charging dock as it never knows its current location or
the charger location, and so would randomly travel until no battery remains.
Suggested improvement [2]
The robot should send regular reports (via radio) of its current pose in the
environment.

Kenshow Large

13016784

UFMFNF-15-3

For this suggestion, the robots knowledge of its own location is needed.
This information exceeds the knowledge gained from simple sensor readings,
and must incorporate a map and method of localisation.
We could assume the robot has perfect sensors, motors, and has a consistent
and known starting point on the map. If all this were true, we could use the
perfect topology of the motors to calculate the current location geometrically
with no issue. However, this would be close to impossible to achieve, or will at
minimum be very costly to install such accurate sensors.
A better and more practical solution would be to make use of landmarks. This
could be done through the use of natural landmarks, or through artificial
landmarks. However, since the warehouse map is linear and repetitive (see
section: Proof of concept), this would make the use of natural landmarks difficult.
Therefore, my choice would be to install artificial landmarks. Adding artificial
landmarks to an environment is usually very easy, cheap, and can be made
temporary if desired.
A third option could be the use of a Particle Filter. This involves projecting
a high number of particles onto the map, each particle representing a possible
robot pose. As the robot moves detecting walls, the particles will condense
around what the algorithm estimates is the most likely robot location. Again,
considering our map regularity, I feel that this approach is not appropriate, since
I predict that it would take a considerable length of time for the robot to deduce
its location to report.
Suggested improvement [3]
The platform should be able to generate its own map of a new warehouse, such
that there is no need to upload a new map for each building it will operate in.
This improvement would make the robot considerably more versatile in its
implementation, as it will not need to have a map of its environment given to it.
However, considerations would have to be made in order to correctly store its
self-generated map. If there was not enough on-board storage due to the
warehouse or environment size being unknown, it could potentially fail to
complete storing the map. However, if all mappings were successful and
accurate, it could easily use this newly generated map of its environment to
successfully navigate around. Map generation in this way is possible assuming
that the environment is static and unchanging.
One method of environmental mapping is through Occupancy Grid mapping. This
method is good as it allows for optimisation and since our map is repetitive, we
can choose a location based mapping algorithm. This means it does not rely on
feature detection, is non-parametric, and needs little processing power as it uses
raw sensory data with little to no processing power necessary. However, if there
is any motor inaccuracies it can cause large correspondence problems which can
make the map full of errors.
Suggested improvement [4]
The platform should still be able to re-establish a good estimate of its location if
it were to be switched off, moved to another part of the warehouse, and
switched back on.
This suggestion brings up the common problem of trying to solve the
Kidnapped Robot issue. This is, as stated, when a robot is blindly kidnapped

Kenshow Large

13016784

UFMFNF-15-3

from its surroundings, then moved to another location and its surroundings
revealed once again.
A common solution to this issue would be the particle filter, as it covers the
whole map with possible poses and becomes more accurate as it gathers more
information about its new surroundings. However, as stated before this may take
a while since our map is very repetitive.
Another possibility would be purely with the use of fiducial detectors. If the robot
has access to the full map, upon detecting a fiducial the robot should be able to
deduce its location to a decent degree.
Simultaneous Localisation and Mapping (SLAM) is used to allow the robot to
create a map of its unknown environment, while keep track of where the robot is
within the generating map. Some core algorithms to help solve this include the
Extended Kalman Filter and the Particle Filter. In essence, the EKF uses landmark
detection combined with odometry data in an attempt to keep track of where it is
in relation to the previously detected landmarks until the next landmark is found.

Proof of concept
Plotting environment specifications:

The given size specifications of the current ED-208 robot used to clean the
warehouse is shown above. Since my plan was to modify the current solution in
PlayerStage, I will have to create a plot close or similar to the specifications
given in order to create an accurate simulation.
Shown below is robot I plotted and planned out in PlayerStage. I tried to be
accurate in my plot, without using an unnecessary amount of time concentrating
on getting the look precisely correct on specific parts that I felt were not
necessary to be 100% accurate (such as the black box on top of the base and the
shape of the front hose).

Kenshow Large

13016784

UFMFNF-15-3

A schematic of the warehouse that the robot will be working in was also
provided in order to be able to accurately plot the map and environment that the
ED-208 will be driven in. Mapping this maps scale accurately is quite important
in order to get the distancing between the shelves in the environment correct for
the robot.

In order to map the scale of the warehouse accurately, it was necessary to

be pixel perfect. Using simple graphics software, I could create a scale of the
map that is highly accurate to the measurements given. By using the
measurement system:

(200.1 m)

1 px=0.1 meter

where

spaces between each of the 10px

px=pixel , I could create 20px

(100.1m)

wide shelves.

Some measurements were not given, such as the exits and entrances, the
distance from the end of the shelves to the walls, and the length of the corridors
between the shelves, I worked off of the fact that 2 meter spacing was a
consistent measurement. I thus created the gaps between the shelving and the
walls to be 2 meters (on both the west wall and the north and south walls), the
gap between the horizontal shelves and the east-most vertical shelf to be 2
meters, and all exits and entrances to be 2 meters wide each also. Overall this
4

Kenshow Large

13016784

meant that my vertical shelves were

horizontal shelving being

[3026]

[20( 24 ) ]

UFMFNF-15-3

meters long, with my

meters long. By using these measurements,

and by estimating where the exact south exit/entrance position should be, I
created the below map that looks like a very good representation in comparison
to the original that was given for specification. In order for PlayerStage to
recognise this maps format, I made sure to make it a binary image.

As you can tell there is no charging station plotted on this map. This is
because I plan on implementing landscapes which will include the charging
station as a landmark.
After putting the .png of my created map into PlayerStage, turning it blue,
then giving it a third dimension, the following was the result.

Simulate existing:
Now that I have plotted out both the mobile robot and the warehouse
environment, I can use various PlayerStage methods and a MATLAB client to help
simulate the robot.

Kenshow Large

13016784

UFMFNF-15-3

In the above screenshot I am using playerv in PlayerStage in order to

create a controller for my robot. By turning on footprints in the PlayerStage
window, I can show where the robot has been previously. As you can see from
the screenshot I am controlling it to drive in an anti-clockwise rotation.

Here we can see a combination of MATLAB and playerv being used to remotely
control the robot in the simulation, and plot the position data (with no noise)
respectively.
Demonstrate improvements
In this section I will show how I implemented the solutions I found for each of the
suggested improvements from my requirements analysis section.
1.
6

Kenshow Large

13016784

UFMFNF-15-3

In order to do any form obstacle avoidance autonomously, the robot needed

more sensors. I decided on adding two more front facing sensors, each at a wide
angle from the front to cover the sides as shown below.

By writing an algorithm that randomly generates an angle to wonder at while the

robot is clear to drive forwards, I created a wandering robot which acts as a
reactive robot when detecting walls. However, when I ran this algorithm and
plotted the odometry data with no noise, you can see that it is a very inefficient
way of covering ground.

2.
Using the wander algorithm I wrote for the robot to wander around the
warehouse map, I ran it multiple times to see the difference between the results.
They are shown below.

As you can see, it never successfully manages to explore all corridors of

the warehouse. The second attempt only made it to its 5 th right corridor, skipping
the 4th. However, this is successfully reporting back where the in the map the
robot is on a regular basis.
The Fiducials in my map are there in order to be able to distinguish where the
robot it when it sees it. Each fiducial has a bearing and an individual ID/ name
that the robot recognises when seen by the fiducial detector mounted on the
robot. By knowing the pose of each fiducial the robot can then calculate its
current position. Fiducials in simulation will also allow for the robot to make a
decent attempt at recovering position.

Kenshow Large

13016784

UFMFNF-15-3

It is generally up to the designer and the owner of the system to decide

how many fiducials they want to be in their system, as the more fiducials there
are in the map, the better the chances of the robot being able to accurately fix
its sensor errors when needing to report back its current location.

Above I have created a small environment to show how my robot detects

fiducials visually in MATLAB.
Now that my fiducials have been plotted, with each assigned an ID/name, I can
now go on to implementing noise into my system.
Although the below plots are three totally different outcomes of my algorithm
due to its random wander procedure, the plots show how the velocity noise
effects my overall location plot accuracy.

[From left to right : pure odometry only plot ; odometry with 0 noise ; pure odometry and
noise plot ]

Kenshow Large

13016784

UFMFNF-15-3

3.
By writing an additional piece of code, I am able to use the sensor data to plot an
occupancy grid map of the warehouse, without the actual map I created for the
first solutions being provided. This shows that by using a noiseless system to
create a map of an unknown space is possible using Occupancy Grid mapping.
Below is the result I achieved. Since this map was made using ideal
sensors and no noise, I omitted some of the noise that was generated in some of
the corridors.

Due to the fact that my wander algorithm was not refined to explore the whole
warehouse properly, this result has been created
In practice, if this map was created, my robot could then use the accumulative
data of the fiducials, the newly created map, and filter algorithm in order to
report a highly accurate and consistently correcting location of the robots pose.

Conclusion
Throughout this report, the solutions that I have provided have all been
successful to their own degree. I feel that the solutions I provided in writing
would all have a high level of success to solve the suggestions that was given by
Tyson Inc.
In implementing my ideas for the solutions I feel that, given more time, I
would have been able to implement a proper SLAM algorithm to efficiently and
effectively explore and map the whole of the warehouse.
In simulation, the solutions I managed to code worked well and gave me results
that I wanted and was expecting. However, in reality I feel that there are many
factors that we have not been able to address in the simulation. These factors
may include the on-board rubbish storage capability, dust or cause the sensors
to fail, the weight of the robot or correspondence issues with map plotting.
In terms of the warehouse and the environment, there are lots of assumptions
that I have made that may not be true when actually implementing the robot.
These assumptions are that the environment is completely static, enclosed, with
no humans or other robots about that may cause collisions or other error
readings. The robot must be able to navigate the floor surface effectively
(without slip) as if we are reading the topology of the wheel motor sensors a slip
of the wheels on the surface of the warehouse floor would cause the bearing
estimate to have greater error.
I feel that SLAM would be the greatest challenge as people are still tackling the
issue today. There are lots of parameters and assumptions that simulation
9

Kenshow Large

13016784

UFMFNF-15-3

programs make when running code and so even if it does work in simulation, it
does not mean that it will work as well, or as consistently, as it does in code.
Throughout my report and design though processes, I have kept careful
consideration of keeping processing and costs down, without compromising too
much for the noise or sensor accuracy. By keeping sensor numbers down to a
limit by only looking forwards and slightly out to the sides, I could maximise the
view area without adding even more sensors. I also imitated the sensor that was
already installed onto the robot, to allow for consistency when programming and
wiring the new improvements onto the robot.

10