Technical Documentation
Autonomous Mine Sweeper
LiTH
2015-12-07
Technical Documentation
Editor: Oscar Hörberg
Version 1.0
Status
Reviewed
Approved
TSRT10
Oscar Hörberg
Hanna Nyqvist
2015-12-07
2015-xx-xx
Ross Haj
[email protected]
L IPs
Page 1
LiTH
2015-12-07
Autonomous Mine Sweeper
PROJECT IDENTITY
2015/HT, Ross Haj
Linköping University, Dept. of Electrical Engineering (ISY)
Group members
Name
Axel Halldin
Oscar Hörberg
Sofie Griph
Robert Svensk
Samuel Örn
Henrik Fåhraeus
Jonas Hyllengren
Responsibility
Project Leader (PL)
Head of Documentation (DOC)
Head of Design
Head of Software
Head of Hardware
Head of Tests
Head of Sensor Fusion
Phone
070-3035052
076-1308547
070-9413964
070-6343977
070-3724874
073-7270416
073-0858131
Email
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
Email list for the whole group: [email protected]
Web site: http://www.isy.liu.se/edu/projekt/tsrt10/2015/bandvagn/
Customer: Saab Bofors Dynamics, Linköping
Customer contact: Torbjörn Crona, [email protected]
Course leader: Daniel Axehill, 013-284042, [email protected]
Client: Hanna Nyqvist, 013-281 353, [email protected]
Tutors: Martin Lindfors, 013-281365, [email protected]
Björn Johansson, [email protected]
Carl Nordheim, [email protected]
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page I
Autonomous Mine Sweeper
LiTH
2015-12-07
Contents
Document history
1
2
3
IV
Introduction
1
1.1
1
Project history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Overview
2
2.1
System flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.1
Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.2
Sensor Diagnosis and Signal Processing (SDSP) . . . . . . . . . . . .
3
2.1.3
Positioning and Mapping . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.4
Base Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.5
Hand Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Base station
6
3.1
Main GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.1.1
Sensor status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.2
Control of Balrog . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.3
Obstacle Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1.4
Current location of Balrog . . . . . . . . . . . . . . . . . . . . . . . .
8
3.2
Load predefined Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.3
Sensor Plot GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.3.1
Sensor Plots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.3.2
Sensor Toggle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.4
4
Hand controller
11
5
Balrog
12
5.1
Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
5.1.1
GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
5.1.2
IMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
5.1.3
Odometers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
5.1.4
Ultrasonic sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
5.1.5
Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
5.1.6
Implementation and flow in subsystem . . . . . . . . . . . . . . . . . .
20
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page II
Autonomous Mine Sweeper
5.1.7
5.2
5.3
5.4
5.5
LiTH
2015-12-07
Dependencies to other systems . . . . . . . . . . . . . . . . . . . . . .
20
Hardware problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
5.2.1
The LIDAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.2.2
The ARM processor . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.2.2.1
Recommendation for future developers . . . . . . . . . . . .
22
Sensor Diagnosis and Signal Processing (SDSP) . . . . . . . . . . . . . . . . .
23
5.3.1
Sensor modelling and signal pre-processing . . . . . . . . . . . . . . .
23
5.3.2
Sensor Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.3.2.1
Outlier rejection . . . . . . . . . . . . . . . . . . . . . . . .
27
5.3.2.2
Sensor Reliability . . . . . . . . . . . . . . . . . . . . . . .
28
5.3.3
Data available from SDSP . . . . . . . . . . . . . . . . . . . . . . . .
28
5.3.4
Implementation and flow in subsystem . . . . . . . . . . . . . . . . . .
28
Positioning and Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.4.1
Pre-filter Processing . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.4.2
Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.4.2.1
Motion Model . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.4.2.2
Measurement Model . . . . . . . . . . . . . . . . . . . . . .
33
5.4.3
Implementation and flow in subsystem . . . . . . . . . . . . . . . . . .
35
5.4.4
Dependencies to other subsystems . . . . . . . . . . . . . . . . . . . .
35
Implementation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.5.1
Shared data structure . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.5.2
Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
A Appendix: Sensor Characteristics
38
B Appendix: Message Id’s
40
References
42
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page III
LiTH
2015-12-07
Autonomous Mine Sweeper
Document history
Version
0.1
0.2
TSRT10
Oscar Hörberg
Date
2015-12-10
2015-12-14
Changes
First draft
Second draft
Ross Haj
[email protected]
Sign
all
all
Reviewed
all
all
L IPs
Page IV
Autonomous Mine Sweeper
1
LiTH
2015-12-07
Introduction
The Autonomous Mine Sweeper project is an ongoing project with the long term goal to construct a prototype of an autonomous mine sweeping crawler. The project is a collaboration
between Saab Bofors Dynamics and Linköping University. The history of the project is described in the subsection below.
The purpose of this document is to give a detailed description of the subsystems that have been
modified and developed during this year’s project. For a thorough description of previously implemented subsystems, see the previous years’ "Technical Documentation" [7]. The document
shall give the client and customer a thorough description of the system. It shall also give an
overview of what future projects need to do and what they can focus on for the project to reach
its long term goal.
1.1
Project history
The history below is composed from earlier documentation and this year’s experiences.
The project was started in the spring of 2009 with the student group O’hara’s. O’hara’s main
focus were specification, control programs, network communication and navigation techniques
In autumn 2009 the group Carpe Locus continued where O’hara’s had left and developed remote
control of the crawler and automatic control for the propulsion. The crawler was also equipped
with GPS.
The next autumn (2010) the group 8Yare continued by mounting an industrial computer on the
crawler and ported the old code to the new computer. The crawler was also mounted with stereo
cameras (model Bumblebee 2).
In 2011 group iMAP focused on using the camera and the crawlers sensors to create a 3D map
of the operating area.
In 2012 Minenmarker choose not to continue the work with the 3D map. Instead they developed
the mine sweeping functionality and improved the crawlers positioning. The main goal of the
project in 2012 was to verify that the entire area had been searched and that all the mines were
found. Minenmarker also named the robot Balrog.
In 2013 the group Ostende Abscondita continued to improve the positioning and search algorithm. They also integrated a wireless hand controller for manual control of Balrog.
In 2014, the project group Invenire Periculosa’s main goals were to continue to develop Balrog’s positioning. Balrog was equipped with a 360°laser sensor and a more powerful industrial
computer.
This year, 2015, the main goal has been to improve the positioning of Balrog. To make this task
easier a better IMU-unit, also including a barometer, has been mounted on Balrog. Furthermore
a few problems in the filter and base station from the last years has been solved. A whole new
subsystem has been implemented and is named Sensor Diagnosis and Signal Processing or
short SDSP, details in Section 5.3. The motion model in the filter has been expanded and new
sensor models has been added to improve the performance of the filter.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 1
LiTH
2015-12-07
Autonomous Mine Sweeper
2
System Overview
The mine sweeping system is divided in three main subsystems, the Base Station, the Hand
Controller and Balrog. Balrog is a small crawler that consists of different subsystems. Each
subsystem performs specific tasks and includes hardware, software or both. For a schematic
overview of the system see figure 1. The arrows show the communication flow in the system.
Sensors
Balrog
Hand Controller
IMU
Wireless link
Laser scanner
GPS
Ultrasonic
Barometer (in IMU)
Sensor Diagnosis and
Signal Processing
Signal pre-processing
Propulsion
Sensor diagnosis
ARM processor
Electric Motor
Positioning and
Mapping
Mine detection
Obstacle detection
External Communication API
Odometer
Control
GUI
Wireless link
Description
Information Flow
Hardware
Software
Component
Navigation filter
Map/Mapping
Base Station
Route planning
Figure 1: Illustration of the system and its subsystems. The communication flow in the system
is illustrated by arrows.
This year’s project has focused on the subsystems "Sensors", "Sensor Diagnosis and Signal
Processing" and "Positioning and Mapping". The design goal was to keep as much as possible
from last year, and therefore the other subsystems have not been changed unless it was necessary
for the system to work well. The Base Station was modified to meet the requirements in the
"Requirement Specification" [5] and some more work was made to get a working system.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 2
Autonomous Mine Sweeper
2.1
LiTH
2015-12-07
System flow
In this section the system flow will be described and the focus will be according to the design
goal mentioned above. In other words, the data that is passed between the subsystems Route
Planning, Control and Propulsion or between them and other subsystems has been kept the
same as in last year’s project if possible. Therefore, only the subsystems where the data flow
has been changed considerably are described below. To understand the flow between the other
subsystems, see the "Technical Documentation" from last year [7].
2.1.1
Sensors
In the Sensors subsystem raw sensor data is stored and time stamped. This data is then available for the Sensor Diagnosis and Signal Processing subsystem. Most of this was already implemented from last year, but the code that log IMU data was modified to fit the new IMU
sensor that also includes a barometer. The raw sensor data is sent to the Base Station for debug
purposes.
2.1.2
Sensor Diagnosis and Signal Processing (SDSP)
This subsystem receives raw and timestamped sensor data and pre-processes it. Its purpose is
to provide the navigation filter with high quality data. The system runs marginally faster than
the filter, meaning fresh data is always available for the filter. Each processed sensor sample is
stored together with the time stamp from the corresponding raw sensor data, a flag that tells if
the sensor is reliable/unreliable, a flag that marks if the data is an outlier or not and a flag that
tells if the data has been read by the navigation filter in a data structure, see figure 2. The data
structure of pre-processed sensor data is used by the Positioning and Mapping subsystem and
sent to the Base Station.
From Positioning and Mapping the SDSP subsystem receives information needed in the sensor
diagnosis. The SDSP subsystem can also receive commands from the Base Station telling the
SDSP subsystem to treat a sensor as reliable/unreliable.
Sensor 1
Processed Timestamp
sample
Flag:
outlier/inlier
Sensor N
Processed Timestamp
sample
Flag:
outlier/inlier
Flag:
reliable/unreliable
Flag:
reliable/unreliable
Flag:
read/unread
Flag:
read/unread
Figure 2: Schematic of a package of processed sensor data written by SDSP. Packages is stored
in a shared data structure. The filter uses the latest package as input.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 3
Autonomous Mine Sweeper
2.1.3
LiTH
2015-12-07
Positioning and Mapping
The Positioning and Mapping subsystem use the pre-processed data from the Sensor Diagnosis
and Signal Processing subsystem as input to the navigation filter, obstacle detection, mine detection and mapping (if there is no predefined map). In this year’s project the mine detection
has not been covered and no changes has been made to that algorithm.
This subsystem is in charge of all maps that are used in the mine sweeping system. Only the
predefined obstacle map was of intereset this year and is therefore the only map existing on
Balrog. This map is shared between the basestation and Positioning and Mapping.
2.1.4
Base Station
The Base Station and Balrog have been modified so that the Base Station can receive the following data from Balrog:
• Raw sensor data with time stamp (from Sensors)
• Pre-processed sensor data with time stamp and flag (from Sensor Diagnosis and Signal
Processing)
• Estimated states (from Positioning and Mapping)
• Maps: obstacle map
The Base Station and Balrog have been modified so that the Base Station can send the following
data to Balrog:
• Control commands to make it move (to Control)
• Set sensors unreliable/reliable (to Sensor Diagnosis and Signal Processing)
• Predefined obstacle map (to Positioning and Mapping)
All data sent between the base station and Balrog will be encapsulated as shown in Table 1
according to existing implementation [7, sect. 4.1]. There are some new messages being passed
between the base station and Balrog and the id of those messages can be seen in Table 2 and
Table 3.
The payload of the new message sent for controlling sensor toggle on Balrog consists of an array with one element for each sensor.
Each element has one of
three values, SENSOR_TOGGLE_ALWAYS_USE, SENSOR_TOGGLE_AUTOMATIC_USE or
SENSOR_TOGGLE_NEVER_USE defined in the new data class SensorToggle.
2.1.5
Hand Controller
The hand controller is the first way of controlling Balrog in manual mode. Further details on
how it communicates and what commands that are available are explained in Section 4.
TSRT10
Oscar Hörberg
Ross Haj
minroj[email protected]
L IPs
Page 4
Autonomous Mine Sweeper
ID
uint16_t id
Payload length
uint16_t len
LiTH
2015-12-07
Payload
char payload[len]
Table 1: Data format for a message between Balrog and the base station
ID
NETWORK_MESSAGE_
<sensor>_SAMPLE_SDSP
NETWORK_MESSAGE_OBSTACLE_MAP
Description
Sends the buffer of processed sensor data from SDSP periodically.
One message for each sensor, <sensor> is replaced with the name of
the sensor, for exact naming of each
messages se Appendix B.
Sends the obstacle map as an array
from Balrog periodically.
Table 2: New messages sent from Balrog to base station
ID
NETWORK_MESSAGE_OBSTACLE_MAP
NETWORK_MESSAGE_LINE_MAP
NETWORK_MESSAGE_SENSOR_TOGGLE
Description
Sends the predifinied map structure
as an array, see [7] for more details.
Sends the predifined map as all the
lines in the map, coordinates for
start- and end-point.
Sends information whether the sensors should always be used, never
used or automatic used
Table 3: New messages sent from the base station to Balrog
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 5
Autonomous Mine Sweeper
3
LiTH
2015-12-07
Base station
The base station is a laptop communicating with Balrog via WiFi. The purpose of the base
station is to make it possible for the operator to control, tune, debug and see the activity on
Balrog. To do this the base station application uses a GUI and it is the functionality of this GUI
that is explained in this section.
To display activity on Balrog things as sensor values, calculated position, speed of the motors
are represented to the operator in different ways. Some more detail about different functions of
the basestation can be found below.
In this chapter some internal data classes are mentioned, if extensive explanation of how each
data class works is left out further description can be found in Technical Documentation 2014,
[7].
The communication between the base station and Balrog connected to each feature in the GUI
will be explained in more detail in Section 3.4.
3.1
Main GUI
For the most part the main GUI has been kept as it was in the beginning of this year’s project.
The minor changes are a new element in the status bar and two new options in the file menu
(input map and plot gui). Details about the changes are described in the subsections below. The
new design of the main GUI can be seen in Figure 3.
Functionallity in the main GUI in use and working are:
• Display sensor status
• Control by arrow keys
• Set top speed, both keys (’w’,’s’) and vertical slider (visual in GUI) can be used
• See location of Balrog
• See the full obstacle map
Due to a problem with the propulsion system it isn’t possible to control Balrog in practise right
now, for more detail about this problem read Section 5.2.2. As soon as that is resolved it is
possible to operate Balrog via the base station.
Functionality in the GUI not mentioned above isn’t implemented on Balrog and neither are the
messages needed in the communication for said feature, for example waypoint handling and
automatic search.
For more detail about each part see respective subsection below.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 6
Autonomous Mine Sweeper
LiTH
2015-12-07
Figure 3: Current layout of the main GUI
3.1.1
Sensor status
As mentioned above the status bar of the old GUI has been expanded with one new feature. It
is now possible to see the status of each sensor on Balrog.
A sensor can be flagged as Empty, reliable or unreliable. If a sensor is flagged as Empty the
processed data array connected to that particular sensor is empty on the base station. This occurs
when Balrog hasn’t collected enough samples from the sensor so that the SDSP subsystem can
start filling the array with processed data. When a sensor is flagged reliable one of two things
has happened. Either the operator controlling Balrog has requested that the sensor values always
shall be used from the GUI or the SDSP has analysed the raw data from the sensor and flagged
it as reliable. The implementation is the same if a sensor is flagged as unreliable.
More details about the decision whether a sensor is unreliable or reliable can be found in Section 5.3.2 and more about manual sensor toggle can be found in Section 3.3.2.
3.1.2
Control of Balrog
With a working propulsion system the Balrog can be controlled by the arrow keys on the base
station. It works by key press-events that triggers a function in the base station application.
The function sends the requested motor speeds to Balrog and the ARM communicator thread
on Balrog then makes the tracks move. For future development this chain will probably change
as the propulsion system needs a rework due to malfunctioning ARM processor. If the same
concept of sending motor speeds to Balrog is kept then it shouldn’t be needed to change the
way a key press is handled on the base station.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 7
Autonomous Mine Sweeper
LiTH
2015-12-07
Figure 4: Structure of the file containing the predefined map
3.1.3
Obstacle Map
To display the current environment in which Balrog operates the base station the data class
ObstacleMap is used. How the class works is described in Technical Documentation 2014,
[7]. The three different states of a grid in the obstacle map is drawn as; UNEXPLORED_TILE
and EMPTY_TILE is painted white and OBSTACLE_TILE painted black.
The line representation in the predefined map will be translated to an obstacle map containing
grids with a, by the user, chosen resolution. More information about that in Section 3.2 below.
3.1.4
Current location of Balrog
The location of Balrog can be seen in the same section of the GUI as the obstacle map. The
location is drawn by using the state data sent from the filter subsystem on Balrog and the uncertainty of this position, also contained in the state data, is drawn as an ellipse around the location
of Balrog.
3.2
Load predefined Map
There is a new feature in the file menu of the main GUI for loading a predefined map. The
predefined map needs to be defined as seen in Figure 4 for the parser creating the internal map
to work.
As of now the application creates two representations of the map and sends them to Balrog. Both
an ObstacleMap and a DataCollection object containing all the lines in the map. The
reason to create both is that different parts of the system is interested in different representations
of the map. It also makes it possible to use either representation in future implementations on
the system.
These internal maps are meant to be used by the filter and controller in Balrog when a predefined map is available. The controller subsystem was not considered this year so there is no
implementation using the available map for route planning and similar algorithms. The use
of the predefined map in the filter is partly implemented but not all the way. Since problems
occurred late in the project and focus shifted to simulations the last part of this implementation was left out. The thing left to do is to implement the read of the predefined map in the
PositioningAndMapping subsystem. The filter will then use the map loaded on to Balrog.
The feature of loading a predefined map is based on two classes, MapParserGUI
and MapParser. The MapParserGUI class is called from a UserInterface object in
the bases station application and in turn the MapParserGUI calls the MapParser doing the
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 8
Autonomous Mine Sweeper
LiTH
2015-12-07
Figure 5: Design of the new sensor plot GUI.
actual parsing. This way it is possible to implement other ways of reading a predefined map
and the only thing that needs to be changed is the parser function in the class MapParser.
The standard file that defines the map is located in SOURCE_DIR/basestation/map.txt
but it is possible to input any absolute path to a file where a map is defined according to the
structure in Figure 4.
3.3
Sensor Plot GUI
The sensor plot GUI is new for this year and responsible for displaying all sensor values to the
operator in real time. This part of the GUI is also responsible for manual sensor toggle. The
design of the sensor plot part of the GUI can be seen in Figure 5. Each part of the plot GUI is
described in more detail below.
3.3.1
Sensor Plots
For each sensor both raw and processed data is plotted in the same plot. Raw sensor data as a
blue line and processed sensor data as a green line.
It is possible to choose which component (i.e x,y,z) of each the sensor that should be displayed
by pressing the corresponding radio button. All content of the current plot will then be updated.
At the moment just one component can be displayed at a time.
3.3.2
Sensor Toggle
To change the status of a sensor the operator presses one of the radio buttons in the bottom
part of the sensor plot GUI. When the operator presses the button a message is sent to Balrog
containing all the current values of each sensor toggle and actions are taken accordingly in the
SDSP subsystem on Balrog.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 9
Autonomous Mine Sweeper
3.4
LiTH
2015-12-07
Communication
The basics of the communication between Balrog and the base staion are explained in Technical
Documentation 2014, [7]. The different messages passed between the two systems can be seen
in Table 4.
The Balrog side of the communication uses message ids connected to the data classes implemented and corresponding communication layer to send and receive messages.
The base station on the other hand uses a combination of data class communication layers
connected to message ids and its own communication class NetworkBaseStation to send
and receive messages. Which method chosen on the base station side depends on what type of
message that is sent.
This year’s project group has tried to go towards the Balrog sides way of handling messages on
the base station as well and it should be the long term goal to do this system wide. The reason
is that it becomes a uniform way of message handling and almost no duplicated code is needed.
The main parts of implementing new messages to be sent between the systems are now:
• Naming the new message and giving it an id in MessageIds.
• Creating a Comlayer on Balrog if it doesn’t already exists.
• Making sure the Balorg send the new message in it’s communication thread.
• Adding a case for parsing the new message in the receive on the base station
• Adding a function for sending the new message from the base station to Balrog.
• Connecting the event in the GUI that should send the new message.
In some way the steps for implementing a new message above also represent how a message is
handled on the current system. This process becomes some what time consuming and the steps
could be cut in half if both systems would be based on the same ground of communication.
There is a need for at total rework of the communication part of the GUI both a structural and
functional.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 10
LiTH
2015-12-07
Autonomous Mine Sweeper
ID
Description
NETWORK_MESSAGE_OBSTACLE_MAP
Sends the predefined map structure
NETWORK_MESSAGE_SENSOR_TOGGLE Sends information whether the sensors should always be used, never
used or automatic used
NETWORK_MESSAGE_<sensor>_SDSP Sends the buffer of processed sensor data from SDSP periodically.
One message for each sensor, <sensor> is replaced by the name of the
sensor. See Appendix B for exact
naming.
NETWORK_MESSAGE_<sensor>
Sends the buffer of sensor data
from the sensor samplers periodically. One message for each sensor,
<sensor> is replaced by the name of
the sensor. See Appendix B for exact naming.
NETWORK_MESSAGE_STATE_DATA
Sends the current state data from
the filter.
NETWORK_MESSAGE_MOTOR_SPEED
Sends motorspeeds between the
basestation and Balrog, both left
and right.
NETWORK_MESSAGE_LINE_MAP
Sends a line representation of the
predefined map to Balrog.
Table 4: Messages sent between the basestation and Balrog, a combination of Table 2 and 3
along with alredy implemented messages.
4
Hand controller
The hand controller is used to operate Balrog in manual mode. The controller is an Xbox 360
controller communicating over the 2.4 GHz band with a dongle connected via USB to Balrog.
The HandController class handles the communication with the hand controller. It follows
the same structure as the other runable classes. When input from the controller is read using
the C libraries linux/input.h and linux/joystick.h the appropriate action is taken.
Currently nothing else than driving Balrog is implemented, meaning that the only thing the
HandController class modifies outside its own private members is the MotorSpeed data
structure, which later is sent to Balrog to determine the speeds of the tracks.
For information about the buttons and their functions, check this year’s User Manual [8]
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 11
LiTH
2015-12-07
Autonomous Mine Sweeper
5
Balrog
This section will describe the subsystems on which this year’s project has been focused on,
namely Sensors, Sensor Diagnosis and Signal Processing (SDSP) and Positioning and Mapping.
5.1
Sensors
Balrog is equipped with a number of sensors, which are used to collect data about Balrog and
its environment. All sensors but the odometers and the ultrasonic range sensors are directly
connected to the main processing unit. The ultrasonic sensors are connected via an Arduino,
which handles sampling and settings. The odometers are connected to an ARM processor.
However, this processor stopped working in the final week of this project, see Section 5.2.2 for
more information.
This section will focus on explaining the new sensors for this year. See previous year’s Design
Specification and Technical Specification for more details on previously mounted sensors [6,
sec. 5.2, p. 215], [7]. Note that the laser sensor has been removed from previous year, since it
was broken. Also, the IMU has been replaced with a new one this year.
In Table 5 all sensors mounted on Balrog can be found.
Sensor
Gyroscopes
Accelerometers
Magnetometer
Barometer
Ultrasonic
sors
GPS
Measured physical quantity
Angle velocity,
heading
Velocity, acceleration
Heading, mine
detection
Altitude
sen-
Odometer
Distance (to object)
Position
Distance (travelled), speed
Output
Running in
deg/s
10 Hz
Standard
range
0-450 deg/s
m/s2
10 Hz
0-50 m/s2
au
(arbitrary
units, normalized
to earth field
strength)
Pa
10 Hz
0-80 µT
10 Hz
cm
10 Hz
WGS84 position,
number of satellites used, accuracy
mm, mm/s
1 Hz
300-1100
hPa
0-6 m (11
m max)
-
Event based (Not
running. ARM
broken.)
1.07mm
(max
resolution)
Table 5: Sensors that are mounted on Balrog
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 12
Autonomous Mine Sweeper
5.1.1
LiTH
2015-12-07
GPS
The GPS installed on Balrog is of the type Ublox-5. It is connected to one of the USB ports,
and has a separate antenna to receive the satellite signals.
The sensor output values according to the WGS84 standard. However, these coordinates are
converted to the RT90 standard in the software and logged to be used by other subsystems.
Sensor interface
All communication with the sensor is handled via USB. The power needed by the sensor is also
drawn from the USB port.
Communication
The communication with the GPS is one way; Balrog never sends any messages to the GPS
sensor. The GPS continuously sends samples in a stream. To retrieve them, the port the GPS is
connected to is opened and read.
Placement on Balrog
The GPS sensor is mounted inside Balrog (in the compartment under the main processing unit).
The antenna is mounted on top of Balrog’s metal plate in order to get as good reception as
possible.
Sensor model and performance
After testing the GPS, it was clear that the noise in the samples was not of White Gaussian type.
For a further explanation about how this was handled and modelled see Section 5.3.1
5.1.2
IMU
An IMU-unit, which also includes a barometer and a magnetometer, is mounted on Balrog. The
sensor is of type MTi 100 and is manufactured by Xsens. This is an upgrade from last year’s
Balrog. The MTi 100 contains the following sensors:
1. 3D accelerometer
2. 3D gyroscope
3. 3D magnetometer
4. Barometer
5. Temperature sensor
All facts about the sensor in this section are taken from The MTi User Manual [2], unless stated
otherwise.
See Figure 6 for a picture of the sensor.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 13
Autonomous Mine Sweeper
LiTH
2015-12-07
Sensor interface
The IMU is connected to the main processing unit via USB. The USB cable also provides power
to the IMU.
Communication
An SDK package is provided by Xsens. It contains the Xsens Device API which was used for
communication with the MTi 100. The API is written in C and compatible with Windows and
Linux systems, but the provided C++ wrapper has been used in this project. Important to note
is that the API works for all of Xsens’ sensors and not just MTi 100. This means some of the
functions in the API will not provide a meaningful return value, because they target a feature
that does not exist in the MTi 100.
Xsens also offers a complete specification of the low level communication [3].
On board processing
The MTi 100 has an on board processor which handles sampling of the sensors and has built
in signal processing software. The unit contains an internal 16 bit ADC to convert the analog
sensor values to digital. There is an option to get the raw, unprocessed (but digitalized) sensor
values as output. See the Output section for specifications of what outputs were used.
Placement on Balrog
The IMU is mounted so its center is on Balrog’s Z-axis, in order to minimize transient accelerations while rotating around the Z-axis.
The sensor is mounted upside down inside Balrog. The IMU and Balrog’s X-axis corresponds,
while there is a sign change in Y and Z-axis. This is compensated for in software, so the logged
values of the IMU corresponds to Balrog’s coordinate system. See Figure 6 for the IMU’s
coordinate system and Figure 7 for Balrog’s.
Coordinate system
The sensor fixed coordinate system is a right handed system, see Figure 6.
Used outputs
The inertial outputs used from the MTi 100 are preprocessed 3D linear acceleration, 3D rate of
turn (gyroscope) and 3D magnetic field data. All values are in a sensor-fixed coordinate system. The calibrated data has been going through Strapdown Integration and Inverse Strapdown
Integration. The output from the barometer was also used. Table 6 shows which outputs were
used and their corresponding unit.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 14
LiTH
2015-12-07
Autonomous Mine Sweeper
X
Z
Y
Figure 6: The MTi 100 and its default coordinate system
Vector
Acceleration
Angular velocity (rate of turn)
Magnetic field
Pressure
Unit
m/s2
rad/s
a.u.(arbitrary units, normalized to earth field strength)
Pa
Table 6: Used output from the MTi-100
API
The API for MTi-100 differs somewhat from the other sensor APIs. Unlike the other APIs it
is implemented in two blocks. The first block handles initializations. The second block is a
callback handler which handles the sampling of the sensor.
Application flow
The use of the IMU API differs a little compared to the other sensors’. Programatically, it does
not inherit from the same abstract base class (ASampler), this is due to the use of an event
based callback handler.
First, the initialization of the sensor is run (connection to the device, setting frequency and
which outputs are required from the sensor). In this step, a callback handler is added to the
sensor. Every time the sensor sends data, the callback handler is triggered. The callback handler
then checks what kind of data is received, timestamps it and logs it. See Figure 8 for a schematic
of the communication flow.
Sensor model and performance
After stationary testing of the MTi-100 it was clear that all sensor noise could be considered as
White Guassian Noise with the variances specified in Appendix A. See Section 5.3.1 for further
details and sensor model.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 15
LiTH
2015-12-07
Autonomous Mine Sweeper
X
Front
Z
Y
Back
Figure 7: Balrog’s coordinate system, seen from above
Hardware
MTi-100
Software
On board processing
Callback
handler
Init
Data log
Globally accessible
data structure
Software
subsystem
IMU API
User
Figure 8: Flow for the MTi-100, the arrows shows the direction of communication
5.1.3
Odometers
The odometers measure how much each track on Balrog moves, using 500 marks spaced 1.0744
mm. These sensors are event based and sends out pulses on two lines each time a mark is passed.
Which pulse comes first determines the direction. From this information it is also possible to
compute the speed of the tracks. For a more thorough explanation, see the design specification
of 2009 [4].
Since the ARM-processor that previously handled the sampling of the odometers has stopped
working, there is currently nothing that samples the odometers. See Section 5.2.2 for hints
about how to implement the ARM functionalities in the Arduino.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 16
LiTH
2015-12-07
Autonomous Mine Sweeper
Sensor interface
The communication with the odometers needs to be handled by some kind of microcontroller,
which then in turn has an interface towards the main processing unit of Balrog.
Currently, the ARM processor which previously was used for this purpose is broken, see Section
5.2.2.
Communication
Two wires are used for the communication with each odometer. When one of the evenly spaced
marks on the plate, which is mechanically coupled to the tracks, passes the sensor two pulses
are sent, one on each wire. In which order they come determines which direction the plate is
turning. For more details, see Section 5.2.2.1
Placement on Balrog
The odometers are mounted inside Balrog, next to the motors.
Sensor model and performance
The sensor has event based sampling and measurements were taken while rotating Balrog on
the spot in order to determine the variance of the sensor. The results can be found in Table 7
below. For further details and sensor model see Section 5.3.1
Variance ∆distance [mm]
Variance speed [mm/s]
Left track
3.6916 · 10−6
2.1725 · 10−4
Right track
1.0776 · 10−6
2.6475 · 10−4
Table 7: Variances of odometer samples
5.1.4
Ultrasonic sensors
Balrog is equipped with four ultrasonic sensors to measure distances and detect objects. They
are of type SRF10 and the specifications for the sensors can be found in [9]. The sensors got a
beam width of 72° [10].
Sensor interface
The ultrasonic sensors are connected to and controlled by a microcontroller, an Arduino Uno
Rev.3, through an I2C (Inter-Integrated Circuit) bus. The Arduino is, thanks to the I2C bus, able
to communicate to multiple sensors on the same physical wire.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 17
LiTH
2015-12-07
Autonomous Mine Sweeper
Communication
The Arduino uses Arduino’s Wire Library to communicate with the I2C devices [11]. Each
sensor has a unique address that specifies which sensor is to be read or written to at the moment,
see table 8. The SRF10 sensors uses eight bit addresses but the I2C protocol just handles seven
bits for the address when sending (the eight bit that is sent through I2C determines if the device
is being written to or read from). Therefore the lowest bit is manually dropped in the Arduino
code and the seven most significant bits are sent to the sensor where it reads as an eight bit
address. For example, for a sensor whose address in the data sheet is specified to 0xE0, 0x70 is
sent instead.
Direction
Forward
Position
Left
Right
Left
Right
7-bit Address
115
117
119
121
7-bit Adr (Hex)
0x73
0x75
0x77
0x79
8-bit Adr (Hex)
0xE6
0xEA
0xEE
0xF2
Table 8: I2C address for each ultrasonic sensor. The sensors got a 8-bit address but it is the
7-bit address which is sent through the I2C bus.
Placement on balrog
The sensors are mounted on Balrog as shown in figure 9 and the table 9 below. There are
two sensors pointing forwards and two sensors pointing sideways at each front corner, making
Balrog able to detect objects on its sides. The front sensors are angled 10 degrees each from
each other to reduce the risk that one "ping" will be detected in wrong sensor.
β
Figure 9: Layout of the positions of the ultrasonic sensors
Arduino - ultrasonic circuit
The sensors are connected in parallel as they are connected to the same I2C bus. A 470µF
capacitor in parallel with the range finders is used to smooth their power supply. Two set of
resistors, with a total resistance of 1.79kΩ each, are connected from the Arduino’s 5V pin to
the SDA (serial clock) and SCL (serial clock) pins. This is to pull those lines high.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 18
Sensor
(address)
115
117
119
121
Autonomous Mine Sweeper
Position x Position y Angle against
(cm)
(cm)
the −y-axis
(degrees)
+22
+18
+10
+22
−18
−10
+14
+22
+90
+14
−22
−90
LiTH
2015-12-07
Table 9: Positions of the ultrasonic sensors. The positions are counted from the origo at Balrog
in Balrog’s coordinate system.
Sensor operation
The ultrasonic sensors have four different internal registers which can be written to and read
from via the I2C bus. These are the command register, analogue gain register and range register
(which actually occupies two registers). A range measurement is started by sending a command
to the command register of a sensor and the result can be read from the range register when the
measurement is finished. By sending different commands the user can determine if the result
shall be given in inches, centimetres, or in micro-seconds. The sensors are currently set to give
the result in centimetres.
The maximum range can be set by writing to the range register. It determines the internal
timer, which says how long the sensor will listen for an echo. With a shorter ranging time the
ultrasonic sensor can make more measurements during the same time interval. The maximum
range is currently set to 280 cm.
The maximum analogue gain can be set by writing to the analogue gain register. A lower
value decreases the maximum gain of the "ping" from the sensor and the echoes from objects
further away will be more difficult to detect. This is good to do if the sensor has to make fast
range measurements without picking up a distant echo returning from the previous "ping". The
maximum analogue gain is currently set to 0x06.
Both the maximum range and the maximum analogue gain are set at the Arduino start up.
For further details, see the data sheet for the SRF10 sensors [9].
Sensor model and performance
After stationary testing at four distances against a wall with each of the SRF10 sensors, it
appeared that the noise could be approximated as white Gaussian noise for each distance but
also that the variance was increasing with the distance. Cause of this the biggest variance was
used for all sensors to make the choice simple. The variance was set to 0.073. See Section 5.3.1
for further details.
The ultrasonic sensor with 7-bit address 0x73 has approximately a linearly increasing error as
the range measurement increases. This error is about one centimetre less than the real range
value for each half meter and an offset is implemented for this in the Arduino code.
The Arduino does the range measurements for the sensors simultaneously, which means that
there is a risk that one sensor picks up the other’s echo and get a fake measurement. However,
this has been tested and did not shown any significant disturbance and should not be a problem
such as the sensors are mounted on Balrog.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 19
Autonomous Mine Sweeper
5.1.5
LiTH
2015-12-07
Arduino
The Arduino unit is an Arduino Uno Rev. 3 and is an open-source microcontroller board based
on the ATmega328P with and pre-installed bootloader, [12]. To write the code and program the
Arduino unit, Arduino’s own software was used.
Arduino interface
The Arduino is connected to Balrog’s main processing unit via USB. The USB cable also provides power to the Arduino.
Communication
The Arduino starts the ranging loop right after start up. After it gets the values from the sensors
it creates a string of the values. The string, which have a pre defined structure that the Arduino
API in Balrog’s main processing unit also know, is sent via the USB to the API. When the
API listens to the stream it gets the latest ranging values and a time stamp is set to the data.
Currently, the Arduino makes range measurement and sends data more often than the API is
listening at the steam which means some data will get lost.
5.1.6
Implementation and flow in subsystem
Each sensor subsystem includes the following:
1. The hardware (including eventual on board processing provided by the manufacturer)
2. An API which handles communication with the sensor
3. A log where all sensor data is stored
The task for the API is to handle all interaction with the sensor. This includes fetching sensor
data. The API can also set change internal sensor settings. All measurements that are fetched by
the API are timestamped and stored in a shared data structure available to the other subsystems
within Balrog.
See Figure 10 for a schematic of the flow.
5.1.7
Dependencies to other systems
Each sensor subsystem is independent. Thus every sensor subsystem can be run in its own
thread without any considerations.
5.2
Hardware problems
Unfortunately some hardware started to malfunction during the project and some was broken
from start. In this section the problems are explained, what was done to resolve them and
recommendations about what to do in the future.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 20
LiTH
2015-12-07
Autonomous Mine Sweeper
Hardware
Sensor
Software
On board processing
Globally accessible
data structure
API
Data log
User
Figure 10: Flow of a sensor subsystem. The arrows shows the communication.
5.2.1
The LIDAR
Previously a 360◦ rotating laser scanner (LIDAR) was mounted on top of Balrog to retrieve
distance measurements to objects surrounding Balrog. This sensor did not work the first time it
was tested.
The communication with the sensor works fine. A health status byte can be retrieved from
it, and it shows no signs of errors. However, sensor samples cannot be retrieved using the
manufacturers API. When sensor samples for a full revolution (this is the only way the API
enables the user to access samples) are requested a timeout error code is returned. This is
probably due to one of two factors:
• The laser sampler is broken, and thus no samples can be retrieved
• The angle measurement sensor is broken, and thus the sensor never gets that it has completed a full revolution
If there is an interest in determining the exact source of the problem, this can most likely be
done using low level communication.
5.2.2
The ARM processor
The ARM processor, which was used for controlling the tracks and sampling the odometers,
suddenly stopped communicating after a package intended to simplify the overloading of code
from PC to Balrog was installed. Most likely some update of Ubuntu on Balrog occurred, which
changed some kind of communication setting. It is unknown which package update caused the
problems and what the update changed.
The ARM works without trouble on Windows system, and also on a computer with Ubuntu
12.04. However, on all computers (4 different tested in total) with the latest update of Ubuntu
14.04, the communication is dead.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 21
Autonomous Mine Sweeper
5.2.2.1
LiTH
2015-12-07
Recommendation for future developers
Since the ARM is currently not working, Balrog cannot be driven and no odometer samples can
be retrieved. This year’s recommendation to future developers is to scrap the ARM processor
and implement the same functionality in the Arduino, which currently only is used for sampling
of the ultrasonic range sensors. There are a few reasons for why this option is better than
continuing to try to get the ARM to work again:
• When reading on forums it is evident that other people have had a lot of problems with
this particular ARM processor and Linux; the compatibility with Linux seems to be bad
• The ARM processor is old and outdated. So old that not even the technicians at ISY had
any hardware to program it. Working with such hardware is not safe, in case it needs to
be reflashed in the future.
The current functionality implemented in the ARM-processor is:
• Sampling of the odometers and by request sending the current speed and the travelled
distance since last request
• A PID-controller which takes a speed for each track as input and makes sure this speed is
held
• Communication with the main processing unit via USB, using a keyword based communication protocol
This, or similar, functionality should be implemented in the Arduino. Currently the ARMprocessor is not removed from Balrog, but mounted and connected as it was when it was working. For further information about how the propulsion and odometers work, consult the design
specification of 2009 [4].
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 22
Autonomous Mine Sweeper
5.3
LiTH
2015-12-07
Sensor Diagnosis and Signal Processing (SDSP)
The SDSP subsystem has be added by this year’s project in order to perform sensor modelling
and sensor diagnosis. The sections below describe how the SDSP subsystem works.
5.3.1
Sensor modelling and signal pre-processing
The purpose of the sensor modelling and signal pre-processing is to process the sensor data
and model the noise. If the noise is non-white Gaussian, an inverse filter has been modelled in
order to get a signal with white Gaussian noise (WGN). The navigation filter in Positioning and
Mapping will work better if the noise is WGN.
Typical for WGN is that the Power Spectral Density (PSD) is constant, the Auto-Correlation
Function (ACF) is a scaled unit impulse and that the Probability Density Function (PDF) is a
Gaussian distribution.
The sensors are considered to act according to the following model:
y =x+e
(1)
Where y is the measurement, x the quantity that should be measured and e is the measurement
noise (e ∼ N (0, σ 2 )).
Noise modelling
To get a noise model that describes reality as well as possible, multiple data sets have been
collected. The measurements were made during a few minutes (1-5 minutes).
The data sets from each sensor were examined using periodograms and autocorrelation functions, in order to see if the noise could be considered as white or non-white. To be able to
tell if the noise was Gaussian, different plot tools in MATLAB was used (histogram, ndist and
normplot). The variances of the WGN was estimated to get a good starting point for tuning the
navigation filter. The estimation was made by calculating the variance of the noise of each data
set and then taking the mean of all results. The noise variances can be found in Appendix A. All
sensors in the new IMU was considered to have WGN. One example is shown in figure 11 and
figure 12, where it is possible to see that the measurement noise of the accelerometer could be
approximated as WGN. The measurement noise of the odometer was also approximated to be
WGN.
The ultrasonic sensors were also considered to have WGN. This was not really obvious but
become clearer for longer distance measurements. The calculated variances for the ultrasonic
sensors were, as mentioned earlier in Section 5.1.4, increasing with the distance. The variances
between the sensors did not differ as much as they were differing between a short range measurement and a longer one. Because of this and to keep it simple, one and same value was used
for all four ultrasonic sensors. This value was the biggest of the calculated variances for all
sensors and distances. Using the largest variance was considered to be reasonable because the
performance of the sensor is then not overestimated. The ultrasonic sensor tests were performed
in microseconds to obtain higher resolution as if it has been in centimeter instead. The value
for the calculated variance was afterwards converted for fitting range measurements taken in
centimetre.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 23
Autonomous Mine Sweeper
(a) Autocorrelation function y coordinate, accelerometer
LiTH
2015-12-07
(b) Periodogram y coordinate, accelerometer
Figure 11: The accelerometer has approximately white noise
If the noise was non-white Gaussian, an inverse filter was found by system identification. This
was made by examining the noise using linear models in MATLAB’s System Identification
Toolbox [14]. For this modelling the data sets were divided into model data and validation data.
Of all sensors mounted on Balrog it was only the GPS that was considered to have non-white
Gaussian noise. A first order AR-model was considered to be good enough for inverse filtering
the signal. The coefficients can bee seen in Appendix A. The model had the following structure:
ewhite (n) = enon−white (n) + a1 ∗ enon−white (n − 1)
(2)
Figure 13 shows the ACF of the noise of the y coordinate before and after inverse filtering and
figure 14 shows raw and filtered measurement noise compared to each other.
The data sets were also analyzed in order to find an eventual bias in the sensor. It was only
possible to know if there was a bias for the sensors that measure something with a known
ground truth, for example a distance sensor. The sensor data were compensated for the bias
if it was considered necessary. Depending on how the sensor worked, the bias was estimated
off-line or on-line. If the bias seemed to be constant both when Balrog was moving and when
it was stationary, the bias was set off-line. Otherwise it was set on-line. Because the IMU
was mounted a bit obliquely an on-line bias compensation was made to get no acceleration
in x and y when Balrog was standing still on flat ground. For the other sensors in the IMU
and the odometer no bias compensation was made. For the ultrasonic sensor at address 115,
there was an approximately linearly increasing bias for increasing distance measurements. The
bias was not depending of first range measurements values and was, as mentioned in Section
5.1.4, off-line bias compensated in the Arduino code. For the other ultrasonic sensor no bias
compensations was needed.
Because of major difficulties in determining an exact input signal, which would be the ground
truth of what the sensor is measuring, especially for a dynamic input signal, the sensor modelling was made during a constant-but-unknown-input experiment (the ground truth was not
known). Therefore, the models do not describe the dynamics of the sensor. It will only describe
the stationary properties.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 24
Autonomous Mine Sweeper
LiTH
2015-12-07
Figure 12: A histogram of accelerometer measurement noise compared with a normal distribution
In cases where measurable noise contributors (disturbances) were able to be identified, the noise
should have been modelled based on these contributors. One example of such a contributor
is the electric propulsion motors that are likely to create disturbances in the magnetometer
measurements. Unfortunately, the ARM processor stopped working (and thus the propulsion)
and it was not possible to get a measurement with a noise contributor for the magnetometer.
Therefore, the magnetometer was not modelled the way it should have been. On the other hand,
it was modelled when Balrog was standing still and no electric motors were on. As mentioned
above the noise could be estimated as WGN and the variances is shown in Appendix A.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 25
Autonomous Mine Sweeper
(a) Before inverse filtering
LiTH
2015-12-07
(b) After inverse filtering
Figure 13: Comparison between GPS measurement noise before and after inverse filtering
(through a first order AR-model)
(a) y plotted against x
(b) y coordinate plotted against samples
Figure 14: Raw GPS measurement noise compared with inverse filtered noise
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 26
Autonomous Mine Sweeper
5.3.2
LiTH
2015-12-07
Sensor Diagnosis
The sensor diagnosis part of the SDSP subsystem has two major parts, sample outlier rejection
and detecting when a sensor is reliable/unreliable. The SDSP uses the result from the outlier
rejection to determine whether a sensor is reliable; if a reliable sensor receives enough consecutive outliers, the sensor is considered unreliable; likewise, if a unreliable sensor receives enough
consecutive non-outliers, the sensor is considered reliable.
The sensor diagnosis part of the SDSP subsystem does not alter the sample values, instead it’s
adding flags to data samples so the filter will know the status on both the sensor and the sample
itself.
5.3.2.1
Outlier rejection
The outlier rejection is made in different ways for different sensors, depending on whether the
sensor value is represented in the Position and Mapping Measurement Model. For all sensors
below, the sensor sample value is denoted ysensor .
Note: These tests are only implemented on working sensor’s SDSP. However, the outlier
rejection code can be more or less copy-pasted from other sensor’s SDSP for a fast implementation.
Measurement model sensors
For sensors represented in the measurement model, the outlier rejection is based on a design
parameter (threshold) σ for each sensor and the probability density function p(yk+1 |y1:k ) for
each sensor.
The filter used in Positioning and Mapping is a marginalized particle filter (see section 5.4).
Each particle given by that filter will contain the nonlinear states xn,i , the linear states xl,i , the
covariance P l,i and the weight wi . This information together with the general model structure
of the marginalized particle filter [15] gives that a measurement y is distributed as a Gaussian
mixture:
y ∼ p(yk+1 |y1:k ) ≈
N
X
n,i
l,i
n,i
l,i
n,i
i
T
wk+1|k
N (hk (xn,i
k+1|k )+Hk (xk+1|k )x̂k+1|k , Hk (xk+1|k )Pk+1|k Hk (xk+1|k ) +R)
i=1
(3)
Where R is the covariance of the measurement noise.
The filter provides the SDSP with y in (3), as well as y’s variance V . The sample is considered
as an non-outlier if
√
|ysensor − y| < V · N U M BER_OF _SIGM AS = σ · N U M BER_OF _SIGM AS (4)
√
where σ = V and N U M BER_OF _SIGM AS correspond to a confidence interval. The
default N U M BER_OF _SIGM AS is 2, which correspond to a 95.45 % confidence interval.
By changing the value of N U M BER_OF _SIGM AS, it will be possible to tune the test. All
sensor values that do not fullfill (4) will be treated as outliers.
Note: N U M BER_OF _SIGM AS is not tuned on Balrog.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 27
Autonomous Mine Sweeper
LiTH
2015-12-07
Non-Measurement model sensors
For remaining active sensors, a measurement estimate yest. is extrapolated from previous values
using a Lagrange polynomial of order N . Using a limit, L, a sensor value is considered as a
non-outlier if
|ysensor − yest. | < L
(5)
By varying N and L, (5) can be tuned individually for each sensor.
Note: The test is not tuned for any sensor.
5.3.2.2
Sensor Reliability
The sensor reliability test is the same test for all sensors. If a reliable sensor receives K consecutive outlier samples, the sensor is flagged as unreliable. If a unreliable sensor receives K
consecutive non-outlier samples, the sensor is flagged as reliable. K can be changed to tune the
test.
Note: Due to abstraction, K will be the same for each sensor’s SDSP. To change this,
overrule variables in inherited SDSP classes.
5.3.3
Data available from SDSP
The processed data available from the SDSP subsystem will have the same physical quantity
as given by the sensor converted to SI units. The purpose for this is mainly to make the filter
more modular. The only exception is the GPS, which converts from the sensor’s WGS84 format
(spherical coordinates) to RT90 (Cartesian coordinates with unit meters) as well as local coordnates which is a translated RT90 format. Ergo, the GPS is converted to a different standard
which uses SI units.
5.3.4
Implementation and flow in subsystem
The SDSP subsystem includes the following:
1. Filtering of non-Gaussian noise
2. Sensor diagnosis
3. Data from sensor subsystem
4. Data to filter
5. Data from filter
The SDSP filter the incoming GPS signal with it’s inverse noise model in order to get a more
white Gaussian noise. The GPS SDSP also creates a local coordinate and attaches this to the
sample. Neither the unit conversion nor the filtering is needed for remaining sensors because the
sensor subsystem delivers SI units and the sensor noise can be approximated as white during
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 28
Autonomous Mine Sweeper
LiTH
2015-12-07
10 minute runs. The processed data is then used by the sensor diagnosis to perform outlier
rejection and sensor reliability tests. The SDSP also adds a read/unread flag to the samples in
order to give the filter an easy way to check if there’s fresh data in the DataCollection.
The SDSP for each sensor is run on a separate thread, inheriting from the ARunnable class.
All SDSP classes also inherits from the abstract class ASDSP which contains it’s work thread,
SDSP flags, variables and virtual methods for the SDSP functionality. These virtual methods
should be overridden when a sensor’s SDSP needs to modify data or flags.
When the SDSP has processed and diagnosed the data, the data is stored in a
DataCollection object of type Processed<Sensor>Sample (insert sensor name
in <Sensor>). This data object inherits from the Sensor subsystem’s <Sensor>Sample
as well as the abstract class AProcessedSample. AProcessedSample contains the
flag functionality while the <Sensor>Sample contains the sensor value with it’s original data types. The consequence of this is that data from <Sensor>Sample and
Processed<Sensor>Sample can be accessed through the same variables and data types
and that the flags from all Processed<Sensor>Samples can be accessed through the same
variables across all sensors.
The base station has the possibility to set the reliable/unreliable-flag for any sensor to a fixed
state through public methods. This means that the sensor diagnosis will have the permission to
update the flag. The flag can also be unset so that the sensor diagnosis will be able to update
the flag. This will be implemented through a private flag which will or will not give the sensor
diagnosis updating authority.
See Figure 15 for a schematic of the flow. Note that all sensors are not used on Balrog at the
moment, these have no Sensor Diagnosis box, because outlier rejection is not performed.
Dependencies to other systems
The different inverse noise filtering, the outlier rejection and the sensor diagnosis can be executed independently from each other and can be run on the same thread as its corresponding
sensor. This means that every sensor filtering and diagnosis will independently fetch the latest
filter output available.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 29
Autonomous Mine Sweeper
LiTH
2015-12-07
Data from filter
Odometer
Data
Processed Odometer
Data
Sensor diagnosis
Ultrasonic
sensor data
Sensor diagnosis
Accelerometer
data
Gyroscope
Data
Processed
Accelerometer Data
Processed Barometer
Data
Barometer data
GPS Data
Processed Ultrasonic
Sensor Data
Convert to local
coordinate
Inverse noise
model filtering
Sensor diagnosis
Sensor diagnosis
Magnetometer
data
Processed GPS Data
Processed Gyroscope
Data
Processed
Magnetometer Data
Figure 15: Flow of the SDSP subsystem. The arrows shows the communication.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 30
Autonomous Mine Sweeper
5.4
LiTH
2015-12-07
Positioning and Mapping
The purpose of the positioning and mapping subsystem is to estimate Balrog’s position, orientation, velocity and angle velocity. A sketch of the positioning and mapping system can be seen
in Figure 16. The positioning and mapping subsystem was called the SLAM subsystem in the
2014 "Technical Documentation" [7].
Filter
Predefiend
Obstacle Map
Balrog States
Processed
Sensor Data
Figure 16: A sketch of the positioning and mapping system (arrows denote information flow)
The positioning and mapping system consists of:
• Pre-filter processing
• Filter
5.4.1
Pre-filter Processing
Not all sensors provide data that is suitable for direct use in the filter. Values from these sensors
are pre-processed to make them usable. Currently, almost all preprocessing is done in the SDSP
subsystem. Only the barometer data is preprocessed in positioning and mapping, and as the
barometer is not used by the filter, this has only been implemented for future use. The pressure
as measured with the barometer is used to calculate Balrog’s vertical velocity. This is done by
taking the slope of a first order linear regression on the barometer readings taken since last filter
iteration. This gives the change in pressure during the time since last filter iteration, which is
converted to a velocity by multiplication with a constant that depends on air pressure. For future
development, the barometer preprocessing might be moved to the SDSP subsystem as with the
other sensors, or, if the barometer is deemed unnecessary, entirely removed.
5.4.2
Filter
The filter is a marginalized particle filter [15]. The development of the filter was started in
2014. For a full description of the filter algorithm and its implementation (including the loop
parallelisation), see the technical documentation from the 2014 project [7]. Observe that the
numerical issues from last year have been solved.
To estimate Balrog’s states, the filter uses a motion model and a measurement model. The motion model contains information about the dynamics of Balrogs states, and the measurement
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 31
LiTH
2015-12-07
Autonomous Mine Sweeper
model contains information about how the relationship between the states and the measurements. The only sensor not handled by the measurement model is the accelerometer data, that
is regarded as input and used to calculate the predicted states. An obstacle map must be defined
in Balrog for the range sensors to work correctly. Balrog compares the range sensor readings
with this map to estimate its states. The given map is regarded as absolute and will not be
changed by Balrog. If no map is predefined, the range sensors must not be used by the filter.
The filter also calculates expected sensor readings with variances for the SDSP subsystem.
It is possible to run the filter offline by adding the subscript "-filteroffline" when starting the
Balrog executable. This should be possible both on the platform and on a PC. During offline
runs, the filter gets its sensor data from the .txt files specified in the measurement model instead
of from the SDSP subsystem. A Matlab script that simulates Balrog and generates these .txt
files has been implemented. Another Matlab script can compare the "true" states simulated
in Matlab with the estimated states from Balrogs log files. Further development of the offline
functionality is possible. The .txt files could be changed to look similar to Balrogs log files.
This would make it easy to test the filter on real sensor data. Also, a Simulink model of Balrog
could be implemented. This would probably make the simulation easier to understand and to
develop further.
5.4.2.1
Motion Model
A motion model is used by Balrog. The model is based on a coordinated turn 2D motion model
with polar velocity. The model also contains the roll and pitch of Balrog, as these states are
useful in modelling the accelerometer (but this is not implemented). The states at time k, xk are
given below:

xk
 yk 
 
ψk 
 

xk = 
φk 
 θk 
 
 vk 
ωk

(6)
where x is Balrog’s x coordinate, y is Balrog’s y coordinate, φ its roll, θ its pitch, ψ is its yaw,
v its velocity and ω its yaw angle velocity. The first three states, x, y and φ, are defined as
nonlinear in the filter, and the last four are linear. Currently, the states φ and θ (roll and pitch)
are parts of the model but they don’t effect the dynamics of the other states or the measurements.
The time-discrete dynamics of the model is given by:
 T2
cos(ψ)
xk + T vk cos(ψk )
2
 yk + T vk sin(ψk )   T 2 sin(ψ)

  2

 
ψk + T ωk
0

 



φk
=
0
+



θ
0
k

 

 
vk
T
ωk
0

xk+1
TSRT10
Oscar Hörberg

T2
cos(ψ)
0 0
2
T2


0 0
 2 sin(ψ)

0 0
0



u
+
T 0
0
k



0 T
0




0 0
T
0 0
0
Ross Haj
[email protected]
0
0
T2
2
0
0
0
T

0 0
0 0

0 0

T 0
 wk (7)
0 T

0 0
0 0
L IPs
Page 32
Autonomous Mine Sweeper
LiTH
2015-12-07
The vector uk contains the system inputs. u1k is Balrog’s acceleration (measured by the IMU), u2k
is the roll angle speed (measured by the gyroscope) and u3k is the pitch angle speed (measured by
the gyroscope). The vector wk contains the process noise. wk1 is the IMU acceleration noise, wk2
is the yaw angle acceleration (modelled as noise), wk3 is the noise in the roll speed measurement
and wk4 is the noise in the pitch speed measurement.
Currently, the accelerometer value u1k is taken without regard for gravity. This works when
running the filter offline, but will give erroneous values i practice, as Balrog will not be perfectly horizontal at all times. This is fixed if Balrogs pitch (θ) is taken into account. This can
2
be done by subtracting T θg from the velocity update, T2 cosψθg from the x position update
2
and T2 sinψθg from the y position update in the motion model dynamics. This has not been
implemented.
5.4.2.2
Measurement Model
As the SDSP subsystem handles the more complicated sensor modelling, only simple sensor
models is be needed. The sensor inputs are:

XGP S
 YGP S 


 ωgyroscope 
 vR +vL 


2

 vR −v
L


dv



yk = 
r
ultrasonic,1


rultrasonic,2 


rultrasonic,3 


rultrasonic,4 


rultrasonic,5 
rultrasonic,6

(8)
XGP S and YGP S are the GPS position measurements, ωgyroscope is the IMU angle velocity measurements, vR and vL are the odometer measurements, dv is the virtual length of Balrog defined
by the group and rultrasonic,k is the ultrasonic range measurement for sensor k. Only the sensor
readings that SDSP deems accurate is used in the filter, which means that yk might not contain
all of the readings stated above. They are connected to the states according to:


xk


yk




ω
k




vk




ω
k



h(xk ) = 
lultrasonic (1, xk , yk , ψk )
lultrasonic (2, xk , yk , ψk )


lultrasonic (3, xk , yk , ψk )


lultrasonic (4, xk , yk , ψk )


lultrasonic (5, xk , yk , ψk )
lultrasonic (6, xk , yk , ψk )
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
(9)
L IPs
Page 33
Autonomous Mine Sweeper
LiTH
2015-12-07
lultrasonic (k, xk , yk , ψk ) are functions that given Balrog’s position, yaw and obstacle map (predefined or dynamic) calculates the distance from Balrog’s position (as given by the state vector) to
the nearest wall in the direction of the measurement. Each k is associated with an angle at which
the sensor k is mounted. The range function lultrasonic () can be developed further to account for
the different position of Balrogs sensors (right now all sensors are expected to be positioned at
the IMU) and to handle when no obstacle is detected (eg. the sensor gives a maximal reading).
The lultrasonic,k (x) algorithm runs as follows:
• Shift the obstacle map to make Balrog’s position (x, y) = (0, 0)
• Rotate the obstacle map with the measurement angle, so that the measurement direction
becomes (1, 0).
• Discard all lines whose endpoints has negative x-coordinates (lines behind Balrog).
• Discard all lines whose endpoints has non-zero y-coordinates with the same sign (lines
above/below the measurement line).
• Calculate the intersection between the measurement line (0, 0) + (1, 0)t, t > 0 and all
remaining line segments. The answer is on the form (R, 0), where R is the distance to the
intersection. This distance is saved. For some lines no intersection is found, the algorithm
skips to the next line segment in that case.
• Return the smallest distance R found. If no R (e.g. no intersections) was found, return a
specific distance larger then the range of the ultrasonic sensor to indicate this.
The algorithm has been tested and works in practise, but is not optimized for speed. messuremnt
was taken might have been different due to movement of balrog. Hopefully, this is so small
theres no practical effect. Esp. for the ultrasonic sensors...
The possibility for the measurement model to also contain inputs from the barometer has been
implemented, but this is not used as it uses the vertical speed of Balrog, which is obtained by
multiplying the velocity with the pitch. If this is used, either the pitch or the velocity must be a
non-linear state for the MPF theory to apply.
The measurement model updates the read flag on Processed<Sensor>Sample (insert
sensor name instead of <Sensor>) when it reads a value. Currently this is done by adding a
new sensor data object to the shared buffer with the read flag set. This works, but is unintuitive,
makes the log files less clear and will probably cause problems down the road. As the the
read flag makes sure that the filter doesn’t read the same value twice, this needs to be solved.
A solution could be to implement a flag in the data collection object instead of in the sensor
sample.
each point has been visited is stored. New estimates of Balrog’s positions and their uncertainties
will be used to update the map. Old probabilities must be updated when new information arises.
The map will have a resolution of 10 cm. The probability map will be implemented according
to last years technical documentation [7]. quadratic room with an obstacle in one corner. Say
that Balrog sees an empty corner. Balrog might then be in either of the 3 empty corners and they
should be given the same probabilities (33and finds that the next corner is also empty. Then it
must be able to figure out that it didn’t start in the corner next to the object. If Balrog continues
to explore clockwise and finds that the next corner is also empty, it should know its possition.
How do we implement that? Maybe the filter will handle it...
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 34
Autonomous Mine Sweeper
5.4.3
LiTH
2015-12-07
Implementation and flow in subsystem
Information flows in to the positioning and mapping subsystem from the SDSP subsystem and
from the predefined map. The data is sent to the filter. It estimates Balrog’s states and predicts future sensor readings for the SDSP subsystem. An overview of the system was given in
Figure 16 earlier.
5.4.4
Dependencies to other subsystems
The Positioning and Mapping Subsystem is dependent on data from the SDSP subsystem. The
subsystem is dependent on that the predefined map is correct, and map errors should be as small
as possible. If no predefined map is available, the range sensors must not be used by the filter
(for example, by setting them as unreliable in the SDSP subsystem).
The positioning and mapping runnable creates a marginalized particle filter object and initializes
it with parameters such as Balrog’s starting position and the number of particles used. The
update_states() method of the filter object is then run regularly to estimate new states, and
this method is the basis of the positioning and mapping system. The marginalized particle
filter creates a measurement model object and a motion model object. The measurement model
contains methods for handling the measurements. The motion model object contains methods
for the handling of Balrogs dynamics.
The positioning and mapping subsystem was called the "SLAM subsytem" in previous years
documentation. It then also included routines for object detection and mine detection. The
object detection was based on a laser scanner (LIDAR) that was not used this year and on the
premise that no predefined map was available and was not relevant for this years work. The
mine detection subsystem was not in focus this year and has not been touched. Its performance
is unknown.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 35
Autonomous Mine Sweeper
5.5
LiTH
2015-12-07
Implementation Overview
This section presents the implementation of Balrog. In figure 17 all hardware, subsystems, data
classes and external systems are presented. Figure 17 shows which parts that communicate and
which shared data the subsystems need.
Figure 17: Overview of the system and how it communicates
5.5.1
Shared data structure
This year’s project have kept the design of shared data from last year [6]. The data is shared
between different subsystems by passing in a reference to the data when the subsystem is instantiated. All data manipulation (such as add and get) are implemented to be safe for concurrency,
race condition etc. This is done in the class DataCollection created last year.
All shared data structures inherits from ASerializable, meaning it is possible to serialize
and deserialize the object to and from a stream, making it possible to send them via the data
link. We have experienced some minor bugs in this implementation from last year and have
fixed the problems that we are aware of. The bugs came from typecasting uint to int or vice
versa and also from not sending " " to the stream, corrupting the fragmentation of the message.
There is a test though that is commented out in StatesTest.cpp called SerializeStates (notice the
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 36
Autonomous Mine Sweeper
LiTH
2015-12-07
s in the end as it is a similar to the test SerializeState). We haven’t put any effort in fixing this
as we haven’t used this feature in our implementation and the bug was noticed in a late stage of
the project where other tasks were prioritized.
5.5.2
Subsystems
Implementation of subsystems follows the design from last year [6]. Subsystems inherit from
the class ARunnable and are all completely isolated subsystems. As long as they are instantiated with the correct parameters (such as references to shared data structures and other subsystems), they are able to run independently of the other subsystems. This allows a high degree of
decoupling between subsystems and they can easily be tested and developed in parallel.
Each subsystem runs in its own thread. The thread instantiation is taken care of automatically
in the ARunnable class and is nothing we need to consider when using the objects. Usually
some of the shared data structures are passed as arguments to the constructor. A subsystem
might need to be able to read the shared data or even to manipulate it.
Subsystem Communication on balrog have been changed to run periodically from last year
when it was ran as often as possible. Last year’s implementation had a function that waited
for data from base station in order to send data to the base station. We don’t think this was
intentional because this resulted in the risk that no data was sent from balrog if no commands
were sent from the base station. When this function were changed, the base station was instead
flooded with data. This was the reason that the thread was changed to run periodically but this
can results in latencies of commands sent from the base station (nothing we experienced but the
risk is there). We recommend next year to instead run this thread as often as possible but check
whether the data are new to avoid sending multiple copies of the same data.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 37
LiTH
2015-12-07
Autonomous Mine Sweeper
A
Appendix: Sensor Characteristics
Here the results of the noise modelling are presented. Table 10, 11 and 12 show the estimated
variances of the measurement noise.
All estimated variances for the IMU are based on four data sets where one experiment was made
outside. Balrog was standing still on flat ground. The data set used for the odometer was made
when Balrog was rotating on the same spot, the left and right velocity was constant. An other
measurement for the odometer was made when Balrog was standing still, all data was zero as
expected. The GPS measurement noise was modelled from data sets when Balrog was standing
still outside. Two data sets were taken. The ultrasonic sensor measurements were made in
stationary for each sensor at four different distances against a wall. As mentioned i Section
5.3.1 one and same variance for the sensors was chosen.
Sensor
Accelerometer
Gyroscope
Magnetometer
GPS
variance x
1.0435e-05
2.9861e-07
7.6524e-05
0.2400
variance y
1.2221e-05
2.2154e-07
1.1146e-04
0.4166
variance z
9.3496e-06
1.9815e-07
3.6418e-05
0.0279
Table 10: Noise variances
Sensor
Ultrasonic front left
Ultrasonic front right
Ultrasonic left
Ultrasonic right
Variance
0.073
0.073
0.073
0.073
Table 11: Noise variances
Sensor
Odometer
∆distance,lef t
3.6916e − 06
∆distance,right
1.0776e − 06
velocity left
2.1725e − 04
velocity right
2.6475e − 04
Table 12: Noise variances
For the GPS an inverse filter was modelled and the coefficients of the first order AR-model are
presented in Table 13.
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 38
LiTH
2015-12-07
Autonomous Mine Sweeper
coefficient
a1
x
-0.9838
y
-0.9866
z
-0.9840
Table 13: Coefficients AR-model GPS
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 39
Autonomous Mine Sweeper
B
LiTH
2015-12-07
Appendix: Message Id’s
Name ID
Legacy Id’s
NETWORK_MESSAGE_HEARTBEAT
NETWORK_MESSAGE_STOP
NETWORK_MESSAGE_RESET
NETWORK_MESSAGE_SET_MODE_MANUAL
NETWORK_MESSAGE_SET_MODE_AUTOMATIC
NETWORK_MESSAGE_SET_MODE_SEARCH
NETWORK_MESSAGE_WHEEL_SPEED
NETWORK_MESSAGE_WAYPOINTS
NETWORK_MESSAGE_GPS_SET_ORIGIN
NETWORK_MESSAGE_GPS_USE_CURRENT_POSITION_AS_ORIGIN
NETWORK_MESSAGE_GPS_GOT_FIX
NETWORK_MESSAGE_GPS_LOST_FIX
NETWORK_MESSAGE_GPS_ON
NETWORK_MESSAGE_GPS_OFF
NETWORK_MESSAGE_GPS_STATUS
NETWORK_MESSAGE_PLANNER_STATUS
NETWORK_MESSAGE_MINE_POSITION
NETWORK_MESSAGE_STATE_DATA
NETWORK_MESSAGE_SENSOR_DATA
NETWORK_MESSAGE_OPERATIONAL_AREA
NETWORK_MESSAGE_PROBABILITY_MAP
NETWORK_MESSAGE_OBSTACLE_MAP
NETWORK_MESSAGE_XBOX_CONNECTED
NETWORK_MESSAGE_XBOX_BUTTON_MAP
NETWORK_MESSAGE_GUI_WHEEL_SPEED
NETWORK_MESSAGE_CONTROL_PARAMETERS
NETWORK_MESSAGE_FILTER_PARAMETERS
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
ID no.
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
L IPs
Page 40
LiTH
2015-12-07
Autonomous Mine Sweeper
Sensor sample Id’s
NETWORK_MESSAGE_GPS_SAMPLE
NETWORK_MESSAGE_ACCELEROMETER_SAMPLE
NETWORK_MESSAGE_BAROMETER_SAMPLE
NETWORK_MESSAGE_GYROSCOPE_SAMPLE
NETWORK_MESSAGE_MAGNETOMETER_SAMPLE
NETWORK_MESSAGE_ODOMETER_SAMPLE
NETWORK_MESSAGE_LASER_SAMPLE
Processed sensor sample Id’s
NETWORK_MESSAGE_GPS_SAMPLE_SDSP
NETWORK_MESSAGE_ACCELEROMETER_SAMPLE_SDSP
NETWORK_MESSAGE_BAROMETER_SAMPLE_SDSP
NETWORK_MESSAGE_GYROSCOPE_SAMPLE_SDSP
NETWORK_MESSAGE_MAGNETOMETER_SAMPLE_SDSP
NETWORK_MESSAGE_ODOMETER_SAMPLE_SDSP
NETWORK_MESSAGE_LASER_SAMPLE_SDSP
NETWORK_MESSAGE_SENSOR_TOGGLE
Ultrasonic Id’s
NETWORK_MESSAGE_ULTRASONIC_SAMPLE_FRONT_LEFT
NETWORK_MESSAGE_ULTRASONIC_SAMPLE_FRONT_RIGHT
NETWORK_MESSAGE_ULTRASONIC_SAMPLE_LEFT
NETWORK_MESSAGE_ULTRASONIC_SAMPLE_RIGHT
NETWORK_MESSAGE_ULTRASONIC_SAMPLE_FRONT_LEFT_SDSP
NETWORK_MESSAGE_ULTRASONIC_SAMPLE_FRONT_RIGHT_SDSP
NETWORK_MESSAGE_ULTRASONIC_SAMPLE_LEFT_SDSP
NETWORK_MESSAGE_ULTRASONIC_SAMPLE_RIGHT_SDSP
Map Id’s
NETWORK_MESSAGE_LINE_MAP
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
L IPs
Page 41
Autonomous Mine Sweeper
LiTH
2015-12-07
References
[1] LIPS – nivå 1. Version 1.0. Tomas Svensson och Christian Krysander. Compendium,
LiTH, 2002.
[2] MTi User Manual, Xsens Technologies B.V., Netherlands, Document MT0605P, Revision
F, 27 February 2015.
[3] MT Low Level Communication Documentation, Xsens Technologies B.V., Netherlands,
Document MT0101P, Revision T, 27 February 2015
[4] Designspecifikation, Johan Norberg, http://www.isy.liu.se/edu/projekt/
tsrt71/2009/bandvagn/doc/Designspecifikation.pdf , Revision 1.0, 1
October 2009
[5] Requirement
Specification,
Marcus
Bäck,
http://www.isy.liu.se/
edu/projekt/tsrt10/2014/bandvagn/Documents/Requirement_
specification_v1.0.pdf , Revision 1.0, 19 September 2014
[6] Design Specification, Johan Källström, http://www.isy.liu.se/edu/
projekt/tsrt10/2014/bandvagn/Documents/TSRT10___Designspec.
pdf , Revision 1.0, 27 September 2014
[7] Technical
Documentation,
Marcus
Bäck,
http://www.isy.liu.se/
edu/projekt/tsrt10/2014/bandvagn/Documents/Documents/
TechnicalDocumentation.pdf , Revision 1.0, 11 December 2014
[8] User Manual, Oscar Hörberg, http://www.isy.liu.se/edu/projekt/
tsrt10/2015/bandvagn/UM.pdf , Revision 1.0, 8 December 2015
[9] SRF10 Ultrasonic range finder Technical Specification, Robot Electronics, http://
www.robot-electronics.co.uk/htm/srf10tech.htm
[10] Ultrasonic Rangers FAQ http://www.robot-electronics.co.uk/htm/
sonar_faq.htm
[11] Arduino Wire Library https://www.arduino.cc/en/Reference/Wire
[12] Arduino
Uno
ArduinoBoardUno
Overview
https://www.arduino.cc/en/Main/
[13] BL233 Datasheet, I2Cchip http://www.i2cchip.com/pdfs/bl233_b.pdf
[14] System Identification Toolbox, MATLAB http://se.mathworks.com/help/
ident/
[15] Statistical Sensor Fusion, Fredrik Gustafsson, Studentlitteratur AB, 2012 p3cm |
TSRT10
Oscar Hörberg
Ross Haj
[email protected]
L IPs
Page 42
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement