Editor: Johan K allstr om Version 1 - Linköping University · Autonomous mine sweeper - Balrog...

Design specification

Editor: Johan Kallstrom

Version 1.0

Status

Reviewed Martin Szilassy 2014-10-24Approved Hanna Nyqvist 2014-10-27

Autonomous mine sweeper - BalrogLiTH

2014-10-27

PROJECT IDENTITY2014/HT, Invenire Periculosa

Linkoping University, Dept. of Electrical Engineering (ISY)

Group membersName Responsibility Phone Email

(@student.liu.se)

Martin Szilassy (MS) Project manager (PM) 070-8840295 marsz918Marcus Back (MB) Responsible for docu-

mentation (DOC)070-6924804 marba751

Victoria Alsen (VA) Chief of tests 073-9409540 vical845Johan Kallstrom (JK) Chief of design 073-0718371 johka546Mikael Hammar (MH) Master of SLAM 070-2658294 mikha087

Daniel Orn (DO) Chief of hardware 073-6448910 danor434Olof Zetterlund (OZ) Chief of information 073-7133822 oloze183Simon Ollander (SO) Junior technical advisor 073-8322898 simol515

Email list for the whole group: [email protected] site: http://www.isy.liu.se/edu/projekt/tsrt10/2014/bandvagn/

Customer: SAAB Bofors Dynamics, LinkopingCustomer contact: Torbjorn Crona, [email protected]

Course leader: Daniel Axehill, +46 13 284042, [email protected]: Hanna Nyqvist, +46 13 281 353, [email protected]: Martin Lindfors, +46 13 281365, [email protected]

TSRT10Marcus Back

Invenire [email protected]

LipsPage I

http://www.isy.liu.se/edu/projekt/tsrt10/2014/bandvagn/


2014-10-27

Contents

Document history IV

1 Introduction 1

2 System overview 2

2.1 Coordinate frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Global coordinate frame . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.2 Local coordinate frame . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.3 Balrog coordinate frame . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Base station 5

3.1 Graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 Status bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.3 Settings section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.4 Map section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.5 Waypoints section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.6 WiFi connection window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.7 Controller configuration window . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Hand controller 8

4.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.2 Implementation of communication . . . . . . . . . . . . . . . . . . . . . . . 9

5 Balrog 10

5.1 Propulsion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.1.1 ARM-processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.1.2 ARM-processor commands . . . . . . . . . . . . . . . . . . . . . . . 10

5.2 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.2.1 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.2.2 Laser sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.2.3 IMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.2.4 Ultrasonic sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.2.5 Odometers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.3 Operating system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.3.1 USB serial devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.3.2 Robot Operating System . . . . . . . . . . . . . . . . . . . . . . . . 17

TSRT10Marcus Back


LipsPage II


2014-10-27

6 SLAM 18

6.1 Obstacle detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.1.1 Line extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.1.2 Landmark model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.1.3 Landmark association . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.2 Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.2.1 Motion model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.2.2 Measurement model . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.2.3 Noise model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.2.4 Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.3.1 Obstacle map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.3.2 Probability map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 Route Planning 29

7.1 Search algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.2 Obstacles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

8 Mine detection 33

9 Automatic control 34

9.1 Control equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

9.2 Proposed values of constants . . . . . . . . . . . . . . . . . . . . . . . . . . 37

10 Implementation overview 38

10.1 Shared data structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

10.1.1 Sensor data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

10.2 Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

11 Program flow 41

11.1 Starting up the program . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

11.2 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

References A

Appendices C

A Balrog classes C

B Coding standard D

TSRT10Marcus Back


LipsPage III


2014-10-27

Document history

Version Date Changes Sign Reviewed

0.1 2014-10-01 First draft JK MB

0.2 2014-10-09 Lots of changes, mainly SLAM andsystem flow. Added H-files forprogramflow. Added coding stan-dard. Updated according to com-ments from tutor.

JK MS

0.3 2014-10-13 Lots of changes, mainly SLAM andobstacle detection. More details inroute planning. Updated accordingto comments from tutor.

JK MS

0.4 2014–10–30 SLAM, obstacle detection and routeplanning updated according to com-ments from tutor.

JK MS

1.0 2014-10-27 Version 0.4 approved MS MB

TSRT10Marcus Back


LipsPage IV


2014-10-27

1 Introduction

Balrog is an ongoing project to construct a mine sweeping crawler robot. It is a jointproject between Saab Bofors Dynamics and Linkoping University.

The project was started in the spring of 2009 with the student group O’hara’s. O’hara’smain focus were specifications, control programs, network communication and navigationtechniques.

In autumn 2009 the group Carpe Locus continued where O’hara’s had left and developedremote control of the crawler and automatic control for the propulsion. The crawler wasalso equipped with GPS.

The next autumn (2010) the group 8Yare continued by mounting an industrial computeron the crawler and ported the old code to the new computer. The crawler was alsomounted with stereo cameras (model Bumblebee 2).

In 2011 group iMAP focused on using the camera and the crawlers sensors to create a 3Dmap of the operating area. In 2012 Minenmarker choose not to continue the work withthe 3D map. Instead they developed the mine sweeping functionality and improved thecrawlers positioning. The main goal of the project in 2012 was to verify that the entirearea had been searched and that all the mines were found. Minenmarker also named therobot Balrog.

In 2013 the group Ostende Abscondita continued to improve the positioning and searchalgorithm. They also integrated a wireless hand controller for manual control of Balrog.

This year, 2014, the main goals of the project are to continue to develop Balrog’s posi-tioning. Balrog will be equipped with a 360◦ laser sensor and a more powerful industrialcomputer.

The design specification is a detailed overview of how the system is to be designed andimplemented. The purpose of this document is to provide the group with a completelayout of the system to be constructed. All the requirements of the functionality ofBalrog is found in the Requirement specification [1].

TSRT10Marcus Back


LipsPage 1


2014-10-27

2 System overview

The autonomous mine sweeping system consists of three main subsystems; the base sta-tion, the hand controller and Balrog. Balrog is a tracked vehicle which is divided intosmaller subsystems. Each subsystem perform specific tasks and consists of hardware,software or both. For a schematic overview of the system see Figure 2.1.

SLAM

Route planning

Control

Base station

Hand controller

Propulsion

SensorsIMU

Odometers

Laser scanner

GPS

ARM processor

Electric motor

GUI

Balrog

Hardware

SoftwareExt

erna

l com

mun

icat

ion

AP

I

Wireless link

Wireless link

Component

Description

Mine detection

Ultrasonic

Figure 2.1: Illustration of the system and its subsystems. Dependencies between subsys-tems are illustrated by an arrow pointing from the system towards the dependencies ofthat system.

A diagram describing the communication between the hardware of the system can bestudied in Figure 2.2.

TSRT10Marcus Back


LipsPage 2


2014-10-27

Main Control

Unit

Base StationWiFi

ARM

Odometers Laser sensor

GPS

Ultrasonic sensors

Analogue signalPWM Control signals USB USB

USB

TCP/IP

Wireless comm.

USB (Odometer data)

USB (Calculated control signals)

Electric Motors

IMUUSB

Wireless comm.Hand

controller Dongle

USB

Figure 2.2: Communication between the different hardware in the system.

2.1 Coordinate frames

The system uses three different coordinate frames.

2.1.1 Global coordinate frame

The coordinates (xg, yg, zg) are defined in the global coordinate system. The global coor-dinate system is given according to the RT90 standard which is a geodetic system adaptedfor Sweden with origin corresponding to the WGS84-coordinate N0◦0.000′ E0◦0.000′ atsea level. xg is the longitude, yg is the latitude and zg is the altitude above sea level forthe position (xg, yg).

2.1.2 Local coordinate frame

The coordinates (xl, yl, zl) are defined in the local coordinate frame, a translated androtated version of the global frame as shown in Figure 2.3. The origin of the local frameis always located in the bottom left corner in the area of operation. The local frame isa right hand system with xl and yl making out the two dimensional internal map in thesystem, pointing right and upwards respectively, and zl pointing outwards of the map.

TSRT10Marcus Back


LipsPage 3


2014-10-27

In order to express global coordinates in the local frame we need to know the translationand rotation, if we know the global coordinates of the origin of the local system (bottomleft corner of the operational area) (xgbl, y

gbl) and the global coordinates of the bottom

right corner of the operational area (xgbr, ygbr) we can compute the rotation α and then the

transformation. Since the z coordinate is not used for our application it will be left outof the transformation.

α = atan2(ygbl − y

gbr, x

gbl − x

bbr

)(2.1)

[xl

yl

]=

[cosα sinα− sinα cosα

] [xg − xgblyg − ygbl

](2.2)

x

y

α xg

ygl

l

x gbl y g

bl

Figure 2.3: Global and local frame relationship.

2.1.3 Balrog coordinate frame

The coordinates (xb, yb, zb) are defined in the Balrog coordinate frame and are fixed rel-ative to Balrog. xb points forward, yg to the left and zg upwards. The origin is in thecenter of Balrog. The rotation around the local frame is defined as the angle ψ as is shownin Figure 2.4.

If the origin of the Balrog frame has the coordinates (xlb0, ylb0) in the local frame, the

transformation can be computed as shown in equation 2.3[xb

yb

]=

[cosψ sinψ− sinψ cosψ

] [xl − xlb0yl − ylb0

](2.3)

x

y

Ψ xl

ylb

b

x lb0 y l

b0

Figure 2.4: Balrog and local frame relationship.

TSRT10Marcus Back


LipsPage 4


2014-10-27

3 Base station

The base station consists of an ordinary computer which communicates with Balrogthrough WiFi. The main tasks for the base station are receiving and displaying datafrom Balrog in the GUI as well as giving orders to Balrog through a limited set of com-mands. Since no new functions will be implemented to the base station much of thematerial produced for the base station in last year’s Balrog project will be reused.

3.1 Graphical user interface

The graphical user interface is divided into four main views; the status bar at the top,the settings at the left, the map at the center and the waypoints at the right, as seenin Figure 3.1. Some other settings are also provided through dialog windows availableby selecting ’File’ in the upper left corner. These other settings are filter configuration,network connection and hand controller settings, the latter described in Section 4.

Figure 3.1: The graphical user interface as of last year’s Balrog project.

3.2 Status bar

The status bar displays the current mode (manual or automatic) active for Balrog, theplanner status, the GPS status, the status of the WiFi connection to Balrog and if thehand controller is connected to Balrog.

TSRT10Marcus Back


LipsPage 5


2014-10-27

3.3 Settings section

To the left, the settings section provides buttons at the top for starting, stopping andresetting a search. It is also possible to set the starting point for a search, which will beused as the origin for the local coordinate system. This may be done either manually bytyping in the coordinates or by retrieving the coordinates from the GPS. Any coordinatesgiven to the GUI should use the RT90 standard since this is the standard used within themine sweeper system for the global coordinates [2]. Below the origin settings, there’s abutton for switching the GPS on and off. Furthermore the size of the search area can beadjusted. The shape of the search area is always rectangular and the lengths are givenin meters. The user will specify the angle describing the rotation of the search area inrelation to the global coordinate system. If position is given by the GPS this angle isset to zero. Finally, there are settings for filtering waypoints, obstacles and estimatedposition from the map.

3.4 Map section

At the center of the GUI, the map section will display a map of the search area where theprogression of the search will be shown in real-time. The map is a model of the searcharea, representing it by a mesh. The squares are white at start and gradually becomemore green as the probability that the area has been searched increases. On top of this theobstacles will be represented as smaller squares combined, the resolution of the obstaclesmap and the probability map will be about 20 cm whereas the accuracy of the mines willbe about 1 m. Mines will be displayed with the logotype of last year’s Balrog projectgroup and waypoints will be displayed as dots.

3.5 Waypoints section

To the right of the GUI there is a settings section and a display of the waypoints. IfBalrog is in autonomous mode, the waypoints generated by the route planning will beshown in the list. Waypoints can be added and removed manually from the GUI. Addingwaypoints manually is possible by giving their coordinates in the local coordinate systemor by clicking in the map. There is also support for saving and loading waypoints listfrom a text file.

3.6 WiFi connection window

This window is used to specify the IP address for the WiFi connection, se Figure 3.2.

Figure 3.2: The WiFi configuration window.

TSRT10Marcus Back


LipsPage 6


2014-10-27

3.7 Controller configuration window

Last year, the automatic control was split into three different control algorithms: Rotate-,Waypoint- and Align-controller. Each controller had different parameters, which were setvia the controller configuration window, displayed in Figure 3.3.

This year will only use one control algorithm due to SLAM and another implementation ofthe route planner. This results in replacing the six control parameters (K D W, T D W, K D R,T D R, K D A and T D A) with two parameters: K and T D. Balrog will use a PD-controllerwhere K is the proportional parameter and T D is the derivative parameter.

Figure 3.3: The controller configuration window for last year’s Balrog.

TSRT10Marcus Back


LipsPage 7


2014-10-27

4 Hand controller

The hand controller facilitates the control of Balrog when in manual mode but can alsobe used to perform some other actions related to mine search. The hand controller is aMicrosoft Wireless Xbox 360 Controller which communicates at the 2.4 GHz band througha USB dongle located on Balrog.

4.1 Functionality

The main functionality of the hand controller is to be able to steer Balrog. This is doneby using the left joystick on the controller when the system is running and in manualmode. The hand controller can also be used for several other functions. The followingfunctions are implemented:

• Set to automatic mode

• Set to manual mode

• Start search

• Stop the vehicle

• Reset search

• Set the origin to current GPS coordinates

These functions are pre-implemented with the standard configuration shown in Table 4.1.A model of the hand controller displaying the button ID in relation to the correspondingbutton is available in Figure 4.1.

Table 4.1: Standard configuration for the hand controller.Function Button IDStart in manual mode 0Start in automatic mode 6Start search 7Send stop signal 1Send reset signal 14Set origin to current GPS position 3

These function/button relations can be configured through the Xbox controller config-uration window, see figure 4.1. The configuration window is accessed through the GUIat the base station by selecting ’File’ and then ’XBoxConfiguration’ in the upper leftcorner. When the Xbox button configuration is modified and the user has pressed the’OK’ button the settings are sent to Balrog and saved in the main control unit as a file.This file is read when the system is initialized. If no such file exists when initializing thesystem, Balrog uses the standard configuration.

TSRT10Marcus Back


LipsPage 8


2014-10-27

Figure 4.1: The hand controller configuration window.

4.2 Implementation of communication

The communication between Balrog and the hand controller is built upon availableUbuntu drivers in combination with the C libraries linux/input.h and linux/joystick.

h. The classes used for the hand controller communication are mainly xbox in the codefor Balrog and xboxbuttonmap in the common code. The same base is used as for therest of the system.

When the hand controller connects to Balrog a file is created in the main system onBalrog. The file created is /dev/input/jsX where X is a number assigned to the handcontroller. The file is interpreted with the C libraries mentioned above and from whichthe data can be translated into different commands.

xbox The xbox class handles the communication between hand controller and Balrog.This communication is handled in a separate thread and has a low priority, not to disturbother communication lines. The thread listens for communication from the hand controllerby iterating a loop. The first part of this loop is reading the joystick file, which will blockthe thread until new data is available. When new data occurs the thread awakens andthe command is interpreted. The information is then sent through the real-time threadwhich will connect the signals from the hand controller with other functionality.

xboxbuttonmap The xboxbuttonmap class handles the current configuration of thehand controller as well as communication regarding button configuration changes.

TSRT10Marcus Back


LipsPage 9


2014-10-27

5 Balrog

This section focuses on the basic aspects of the crawler subsystem Balrog. It describespropulsion, the sensors available and the choice of operating system used on the mainprocessing unit.

5.1 Propulsion

Balrog is able to navigate by having two tracks equipped with an electrical motor for eachtrack. There are also two odometers, one for each track, recording the rotation of thetracks. The communication and control with the motor and odometers is facilitated viaan ARM processor connected to the main control unit via an I2C bus [2].

5.1.1 ARM-processor

An ARM processor is responsible for reading odometer data and setting/retrieving thecurrent motor output. The code in this ARM processor is not accessible to us and wetherefore need to use the external interface already provided. This external interface isvery poorly documented from previous projects but it is clear that the ARM is connectedto the main unit via BL233B [3] I2C to PC converter and that a text based protocol withcertain commands [2] is used to communicate with the ARM processor.

5.1.2 ARM-processor commands

The communication protocol is text based. In Table 5.1 the different communicationcommands for the ARM-processor are displayed.

Table 5.1: Communication commands for the ARM-processorcommand format parameters returnSet velocity sVXXYY XX and YY is velocity in mm/s

(one byte each) for left track andright track respectively. Last year’sproject only used speeds in the rangeof 100 mm/s and 760 mm/s.

sVOK if successful

Get distance upDi Retrieve distance traveled since lastread.

Signed double for eachtrack in mm*.

Get velocity upVe Retrieve current velocity Signed double for eachtrack in mm/s*.

* The lack of comments in last year’s code inflicts uncertainty in the interpretation of the format ofthe data retrieved from the odometers, using upDi and upVe. In odometers.cpp the raw data fromthe odometers is divided by the factor 10 000. This finding together with the fact that the precisionof the mark spacing is given in 1

10000 mm makes it probable that the format of the data returned byupDi and upVe is mm and mm/s respectively.

TSRT10Marcus Back


LipsPage 10


2014-10-27

5.2 Sensors

The following subsection describes the different sensors mounted on Balrog.

5.2.1 GPS

Balrog has a GPS receiver of the type Ublox-5. The receiver sends data through a serialport according to the NMEA-0183 standard which is a text based protocol developed fornavigation equipment. The different NMEA messages used are available on pages 40-54 inreference document [4]. The information sent contains position data, time of positioning,number of satellites used for positioning and positioning accuracy.

The positioning data is given as latitude and longitude according to the WGS84 standard.These coordinates are converted to the RT90 standard, using the algorithms from lastyear, before being used by the SLAM, since this is the standard used throughout Balrog[2].

5.2.2 Laser sensor

Balrog is equipped with a laser sensor from Robot Peak, RPLIDAR A1M1-R1, displayedin Figure 5.1. The laser sensor rotates 360◦ in positive θ direction as is shown in Figure5.3. It samples distance data from obstacles at a distance of up to 6 m. The revolutionfrequency of the sensor is adjustable from 1 Hz to 10 Hz. The maximum frequency forwhich the sensor collects data samples for every degree (360 samples per revolution) is5.5 Hz[5].

Figure 5.1: Laser sensor mounted on Balrog.

Connections

The connection between the laser sensor and the main control unit is over a USB cablethrough a USB converter (Silicon Labs CP2102) [6]. The USB connection is configuredas a virtual COM port on the main control unit. The USB cable also provides the lasersensor (5 V) and its motor (3.6 V - 6 V) with power.

Consumption

In Table 5.2, the voltage and current used by the laser sensor is specified [5].

TSRT10Marcus Back


LipsPage 11


2014-10-27

Table 5.2: Power supply and consuption of the laser sensor.Item Unit Min Typical Max CommentsScanner system voltage V 3.6 5 6 Low ripple voltage rec-

ommendedScanner system current mA TBD 40 70 Sleep mode (5 V input)

TBD 130 200 Work mode (5 V input)Motor system voltage V 3.6 5 6 Adjust voltage according

to speedMotor system current mA TBD 100 TBD 5 V input

Messages

The laser sensor has three different message protocols: no-reply, single-reply and multiple-reply. The no-reply requests are STOP and RESET. The single-reply requests are GET INFO

and GET HEALTH. The multiple-reply requests are START SCAN and FORCE SCAN. See Table5.3 for details [7].

Table 5.3: Message requests to the laser sensor.Request name Value Response mode DescriptionSTOP 0x25 No Stops the laser sensor.RESET 0x40 No Resets the laser sensor core.GET INFO 0x50 Single Ask for laser sensor information,

(e.g. serial number, hardware ver-sion).

GET HEALTH 0x51 Single Ask for laser sensors health info.START SCAN 0x20 Multiple Starts scan by entering the scanning

stage.FORCE SCAN 0x21 Multiple Starts scan without checking rota-

tion speed.

Returned data

When in scanning mode, the laser sensor returns data after each completed revolution.The data returned is 40 bits for each sample value. The data contains 6 bits for thequality, 15 bits for the angle, 16 bits for the distance, 2 bits for start new scan and 1control bit. The quality bits represents the strength of the returned laser pulse. Theangle (θ) is given in degrees from the forward position and the distance (d) to an objectis given in millimeters. In Figure 5.3 the returned angle and distance is displayed. Thestart bit S is sent with a complementary inverted S and the control bit, C, is always 1.See Figure 5.2 for the bit order. For return data for the other requests (GET INFO andGET HEALTH), see RPLIDAR Interface Protocol [7]

TSRT10Marcus Back


LipsPage 12


2014-10-27

Figure 5.2: Returned data from laser sensor for each sample.

Figure 5.3: Graphic display of measured angle and distance by the laser sensor.

Assembly

The laser sensor will be mounted above the computer to maximize the field of vision. Ametal plate will be bent and attached in the same screw holes as the computer, to createa surface above the computer where objects can be attached. On top of this surface, thelaser sensor and a cover for the laser sensor will be attached. The cover will consist offour legs/poles and a roof. See figure 5.4 for a drawing of the assembly.

TSRT10Marcus Back


LipsPage 13


2014-10-27

Ultra sonicLaser

Lower metal plate Screw holes

Pole

Figure 5.4: Drawing of attachment of the laser sensor.

5.2.3 IMU

Balrog is equipped with a 3DM-GX1 IMU [8] manufactured by MicroStrain.

The computer on Balrog communicates with the IMU through a USB-connection and canretrieve the following data from the IMU:

• Raw acceleration data along all three axis (±5 m/s2)

• Raw magnetic field data along all three axis (±1.2 Gauss)

• Raw angular velocity data around all three axis (±300◦/s)

• Stabilized and preprocessed acceleration, magnetic and angular velocity data, alongwith estimation of absolute angle

The resolution of each measurement is 16 bits.

According to previous year, the acceleration data is noisy and biased, and affected byroll and pitch. The noise will be compensated for in the state vector x (see 6.3), wherethe bias is modulated, and the effect of gravitation has to be taken into account. Since

TSRT10Marcus Back


LipsPage 14


2014-10-27

the accelerometer seems to be much work for little improvement, this data won’t beused unless the positioning is bad when not using it it. The IMU is also able to give apre-filtered signal which is less noisy, and is regarded as an output option.

The angular velocity of Balrog is estimated using the gyro in the IMU. If the z-componentof the angular velocity is measured while the tracked vehicle is not moving, the gyroproduces an average greater than zero, originating from its bias. To compensate for this,the program on the industrial computer starts by taking 100 samples to estimate this biasalong all three axes. That means that the angular velocities read from the sensor classesin the program are already compensated from bias. This gives agreeable values withina reasonable amount of time after the bias estimation and given that the temperaturearound the gyro is somewhat constant. As the angular velocity is biased with a non-specific mean (see [2, sec 6.1.3], bias from the output will be considered modelling.

The magnetic field strength measured by the magnetometer of the IMU is a sum of themagnetic field of the earth, external fields from the mines and disturbances generatedby the electric motors. Subterranean mines produce clear spikes in the measured field,thus the magnetic field data can be used for mine detection. Unfortunately, the motordisturbances are in the same magnitude as the magnetic field of the earth, which makesit hard to use the magnetometer for the purpose of navigation.

A specification of the performance of the MicroStrain 3DM-GX1 IMU can be found inTable 5.4.

Table 5.4: Performance of the MicroStrain 3DM-GX1 IMUParameter ValueNon-linearity accelerometer 0.2 %Bias stability accelerometer 0.010 gNon-linearity gyro 0.2 %Bias stability gyro 0.7 ◦/sNon-linearity magnetometer 0.4 %Bias stability magnetometer 0.010 GaussResolution orientation < 0.1◦ minimumRepeatability 0.20 ◦

Accuracy±0.5 ◦ at static test conditions±2.0 ◦ at dynamic (periodic) test conditions

A detailed technical specification is available online [9] as well as in the communicationmanual [10].

5.2.4 Ultrasonic sensors

Balrog is equipped with four ultrasonic sensors used solely by the control subsystem forbraking when Balrog is on the way to drive into an obstacle. The ultra sonic sensors areof type SRF10 and specifications for the sensor can be found in [11].

Sensor interface

The ultrasonic sensors are connected to the main control unit through the Inter-IntegratedCircuit (I2C) bus. Through the I2C bus multiple sensor units are able to communicate

TSRT10Marcus Back


LipsPage 15


2014-10-27

on the same physical wire. Each ultrasonic sensor is assigned with a unique address thatspecifies which sensor is to be read or written to at the moment, see table 5.5. The maincontrol unit has no connection for I2C and is using a USB-port together with an USB-I2Cconversion chip.

Table 5.5: I2C address for each ultra sonic sensor.Direction Position Adress

ForwardLeft 0xE2

Right 0xE6

RightFront 0xEA

Back 0xEE

Communications protocol

The ultrasonic sensors can be set to different addresses in order to communicate using thesame I2C bus. The converter I2C-2-C is controlled through an easy text based protocoldescribed in its data sheet [12]. The ultrasonic sensors have four different internal registersthat can be written to and be read from the I2C bus. For a more detailed description of thefunctions and the interface of the sensors, see the technical specification for SRF10 [11].

A distance measurement is started by sending a command to the command register of thesensor. Subsequently the computer stays passive 100 milliseconds before the measurementis completed and is ready to be read from the result register of the sensor. The result isgiven in centimeters.

5.2.5 Odometers

The odometers measure the distances travelled by each track if there were no slip. Eachodometer has 500 marks spaced with 1.0744 mm that are used to estimate the distancetravelled [2].

5.3 Operating system

This section presents and motivates the choice of operating system (OS) on Balrog. Pre-vious projects have used Ubuntu Linux as OS on Balrog, this year’s project will complywith this and also use Ubuntu. This is due to several reasons, the foremost being thepossibility to be able to reuse as much as possible from previous projects and therebyavoiding unnecessary work.

The version of Ubuntu that will be used is Ubuntu Server 14.04 on Balrog and UbuntuDesktop 14.04 on the base station which is an upgrade from past years usage of Ubuntu10.04 on Balrog. This is done in order to enable usage of the increased functionality of thenewer OS while ensuring compatibility for the libraries between the different platforms.

5.3.1 USB serial devices

To enable ARM-processor communication, a file with the line "options usbserial

vendor=0x03EB product=0x6125" have to be added to /etc/modprobe.d/ [13]. The

TSRT10Marcus Back


LipsPage 16


2014-10-27

laser sensor works when plugged in and does not require any thing special to enablecommunication, this have been tested on Ubuntu 12.04.

To enumerate the same USB serial devices to the same devices in /dev/ a UDEV rule canbe made [14]. To set the speed of a specific serial device a similar rule can be used [15].To be able to access the serial adapters the user have to be in the dailup group of the OSor another UDEV rule have to be made to change the permissions of the specific device.

5.3.2 Robot Operating System

A small investigation has been made whether ROS (Robot Operating System) can beutilised in the project. ROS is a framework that can be used when constructing robots asit has support for different features such as sensors, navigation etc. Our conclusion is tonot use ROS in this project due to two reasons. The first reason is the lack of experienceusing ROS within the project group; this results in difficulties to estimate the workloadneeded to set up and port last year’s algorithms to work with ROS. It could thereforeresult in a lot of unplanned work. The second reason is the aim of the project. As theaim of the project is not to build a robot from scratch but rather to improve an alreadyexisting robot, implementing ROS lies outside the scope of the project.

TSRT10Marcus Back


LipsPage 17


2014-10-27

6 SLAM

The SLAM subsystem is responsible for estimating the position of the robot, mappingthe environment, identifying objects and associate them with landmarks.

The subsystem is further divided into three additional systems explained below: Position-ing, Mapping, Obstacle detection.

Figure 6.1: Flowchart of SLAM parts: Obstacle Detection, Positioning and Mapping.

6.1 Obstacle detection

The obstacle detection subsystem is responsible for taking raw measurement values fromthe laser sensor and pre-processing them. The processed measurements are then inputsto the positioning and mapping subsystems.

Pre-processing of the laser scanner includes removing outliers, compensating for measuringwhile moving and approximating the point cloud with straight lines representing objects.

The point cloud created by the laser sensors consists of 360 angle values and a distanceassociated to each of them. Based upon this, a probabilistic sensor model, that connectseach distance with the probability of it being a correct measurement is calculated, will beconstructed.

6.1.1 Line extraction

In order to separate the different lines to be created the edges of each line must beidentified. To solve this, the following algorithm will be implemented:

TSRT10Marcus Back


LipsPage 18


2014-10-27

1. Start iterating through the 360 measurements

2. When a non-maximum distance measurement is found, mark this point as an edgeof a line

3. Continue the iteration, if the distance to the next point is greater than a threshold( ≈ 5 cm, to be tuned) mark this point as the other edge of the line

4. Start searching for a non-maximum distance measurement again, and repeat 2. - 3.until the whole lap is completed

With this method, the line extraction algorithms will have the necessary information toseparate the lines to be created.

To approximate straight lines from a point cloud either split-and-merge or RANSAC willbe implemented. To decide which point cloud is to be approximated with lines,

Split-and-merge The split-and-merge algorithm creates a simpler curve made of fewerpoints given a greater set of points. It requires a list of points and a distance threshold,ε. [16]

1. Create a line between the first and the last point in the list

2. Find the point with the maximum distance to this line

3. Check if this distance is greater than ε

4. If yes, recursively simplify the line until the maximum distance is below the thresholdby calling the function again

5. Return the simplified list of points

The main advantages of the split-and-merge algorithm are its speed and correctness.

RANSAC The RANSAC (RANdom SAmple Consensus) algorithm can perform robustfitting in a situation where outliers are present. The laser sensor has a risk of produc-ing outliers when it finds a false point. Given a set of data, it performs the followingoperations:

1. Randomly select a subset of two points of the data

2. Create a line through these two points

3. Calculate the distance between the remaining points and this line

4. Split the set in inliers and outliers using this distance

5. If the inlier set is sufficiently large, use it to fit a new line and remove the inliers

6. Repeat until max iterations reached or there are too few points left to work with

TSRT10Marcus Back


LipsPage 19


2014-10-27

In summary, it tries different combinations of subsets until a consensus is reached con-cerning which points are inliers and which are outliers by separating the points in differentsubsets and comparing them to each other.

RANSAC has the advantage that is can be used with many types of features once a featuremodel is obtained. Simple implementation is another advantage.

The lines will be stored in reference to the relative positioning map created by Balrog, inthe form of coordinates for the start and ending position of the line.

6.1.2 Landmark model

The landmarks will be stored in a vector when identified. The objects can be regardedas a state and will therefore be modelled as

mk+1 = mk, (6.1)

where the landmark vector mk =

m1

m2

...mj

, with j being the number of known landmarks.

The landmarks will be stored as lines represented by two coordinates (x, y). Every line(when seen) will be used for positioning, so lines will not be fused together creating objects(polygons).

6.1.3 Landmark association

The lines will be matched to each other using an ICP-algorithm. The ICP (Iterative Clos-est Point)-algorithm compares a given point cloud (source) to a reference point cloud. Itfinds the closest corresponding point between the two clouds, then it estimates a trans-formation consisting of rotation and translation. This transformation is the one thatoptimally aligns the points according to their mean square error. The source is thentransformed, and the procedure is iterated. The output is the transformation matrix. Itfinds the closest points matching between model and data. Singular Value Decomposition(SVD) is used to determine the optimal transformation.

As we’re interested in point-to-line matching, this will be evaluated if necessary. Firstand foremost we will try implementing point-to-point, if this is successful we will use thismethod.

Point-to-point To compensate for distortion caused by Balrog moving while scanningwith the laser sensor [17, Algorithm 2] will be implemented. It functions by estimatingthe velocity of the sensor to model out the fact that the scan data is taken at differentpositions.

To perform the point-to-point matching [17, Algorithm 1] will be implemented.

The unmatched points are then used to create lines using RANSAC or split-and-merge(see 6.1.1).

TSRT10Marcus Back


LipsPage 20


2014-10-27

Point-to-line To perform point-to-line matching it needs two different laser scan ro-tations at nearby times (model and data), together with an initial guess of the trans-formation matrix describing the distortion. Lines are extracted by using RANSAC orsplit-and-merge (see 6.1.1). The distortion caused by Balrog moving is still compensatedby [17, Algorithm 2].

Algorithm to match points to lines can be found in A version of the algorithm is describedin [18, fig 5]. An example of an implementation can also be found in [19].

The unmatched points are then used to create lines using RANSAC or split-and-merge(see 6.1.1).

6.2 Positioning

The positioning subsystem is responsible for estimating the position, with regards tomeasurements from the IMU, GPS and odometer, output from the obstacle detectionsubsystem, the map from the mapping subsystem and a motion model of Balrog.

The measurements from the IMU, GPS, odometer and ultrasonic sensor are updated witha frequency of 11 Hz and the laser sensor with a frequency of 5.5 Hz.

6.2.1 Motion model

The dynamics of the Balrog can generally be modelled as

xk+1 = f(xk,wk), (6.2)

where the non-linear function f describes the dynamics of Balrog, with regards to theprocess noise wk and the state vector xk.

We will consider different dynamical models (as described below). We will consider coor-dinated turn constant velocity model first and foremost. If this results in bad positioningof the Balrog, we will consider a modified coordinated turn constant acceleration model.As the values from the IMU are biased with a non-specific mean (according to [2] page25-27), an alternative is to model the bias in the gyro as a state.

Coordinated turn constant velocity model The state vector xk has the followingform

xk =

xkykvkψkωk

, (6.3)

where xk and yk represent the position of Balrog in the map (local), vk represents the speedof Balrog, ψk, ωk represent the orientation and speed of rotation (in local coordinates)respectively.

TSRT10Marcus Back


LipsPage 21


2014-10-27

The function f(xk,uk) can be written as

f(xk,uk) =

xk + Tvk cos(ψk)yk + Tvk sin(ψk)

vkψk + Tωk

ωk

(6.4)

The process noise added to the states ωk and vk is assumed to be Gaussian with mean 0and covariance Cov(w). The noise affect the states as (according to [2])

Qk = GCov(w)GT , (6.5)

where

G =

T 2

2cos(ψk) 0

T 2

2sin(ψk) 0T 0

0 T 2

2

0 T

. (6.6)

Coordinated turn constant velocity with bias model The state matrix xk is now

xk =

xkykvkψkωkωbk

, (6.7)

where ωbk is the bias of the turning rate.

The dynamics then becomes

xk+1 =

xk + Tvk cos(ψk)yk + Tvk sin(ψk)

vkψk + Tωk

ωkωbk

+ wk, (6.8)

with the process noise w (noise in vk, ωk, ωbk) affecting the states as

G =

T 2

2cos(ψk) 0 0

T 2

2sin(ψk) 0 0T 0 0

0 T 2

20

0 T 00 0 1

, (6.9)

TSRT10Marcus Back


LipsPage 22


2014-10-27

6.2.2 Measurement model

The measurements will be modeled as,

yk = h(xk,mk) + ek, (6.10)

where h(xk,mk) is a non-linear function dependent on both the state vector xk and thelandmarks mk, and ek is the measurement noise.

Depending on the motion model used in 6.2.1

No bias and acceleration The measurement vector yk will be implemented as

yk =

XGPS

YGPS

ωIMUvr+vl

2vr−vldv

m1rk

m1α

...

mjrk

mjα

, (6.11)

where XGPS and YGPS are measured using the GPS values. These are updated at afrequency of 11 Hz. From the IMU we achieve a measurement of the turn rate of Balrog.From the odometers the speed of Balrog is measured, by taking the mean of left and right.Also, the turn rate can be approximated calculating vr−vl

dv, where dv is a virtual width,

as per last year. With the laser sensor the distance mirk and angle mi

α to each knownlandmark i = 1, 2, . . . , j is measured. The laser sensor is updating with a frequency of 5.5Hz, which corresponds to half of the other sensors.

The measurement function h(xk,mk) is implemented as

h(xk,mk) =

xkykωkvkωk√

(m1x − xk)2 + (m1

y − yk)2

atan2(m1y − yk,m1

x − xk)√(m2

x − xk)2 + (m2y − yk)2

atan2(m2y − yk,m2

x − xk)...√

(mjx − xk)2 + (mj

y − yk)2atan2(mj

y − yk,mjx − xk)

, (6.12)

TSRT10Marcus Back


LipsPage 23


2014-10-27

where atan2(y, x) corresponds to the function arg(x + iy) with 0 ≤ arg(x + iy) ≤ 2π.As the IMU gives biased values of the turning rate and the acceleration, these will bemodelled in the measurement model. This is an extension of the measurement functionwith the landmarks (both distance and direction) being added to the function h.

The covariance of the measurement noise will vary whether we’re standing still or not. Ifwe are standing still, the speed measurement will rely heavily on the measurement of theodometers, and thus neglecting any measurements coming from the gyro. Vice versa ifwe’re not standing still (the odometers are unreliable when turning because of slip).

Acceleration

yk =

XGPS

YGPS

ωIMU

ωxIMUvr+vl

2vr−vldv

aIMU

m1rk

m1α

...

mjrk

mjα

, (6.13)

The measurement function h(xk,mk) is expanded to (with the assumption that φk issmall).

h(xk,mk) =

xkykωkvkωk

ak − gφ√(m1

x − xk)2 + (m1y − yk)2

atan2(m1y − yk,m1

x − xk)√(m2

x − xk)2 + (m2y − yk)2

atan2(m2y − yk,m2

x − xk)...√

(mjx − xk)2 + (mj

y − yk)2atan2(mj


, (6.14)

where g is the standard acceleration due to gravity.

TSRT10Marcus Back


LipsPage 24


2014-10-27

Modelled bias In case of no acceleration, but modelled bias, we get

yk =

XGPS

YGPS

ωIMUvr+vl

2vr−vldv

m1rk

m1α

...

mjrk

mjα

, (6.15)

with the measurement function h(xk,mk) as

h(xk,mk) =

xkyk

ωk + ωbkvkωk√

(m1x − xk)2 + (m1

y − yk)2

atan2(m1y − yk,m1

x − xk)√(m2

x − xk)2 + (m2y − yk)2

atan2(m2y − yk,m2

x − xk)...√

(mjx − xk)2 + (mj

y − yk)2atan2(mj


. (6.16)

6.2.3 Noise model

Since this project will use the same sensors as last year except the laser sensor, we willalso use the same noise models (though approximating them as Gaussian for the sake offiltering). The distributions with respective parameters for each sensor can be found inTable 4 in [2]. Since the laser sensor is new hardware in this project a noise model ofwill be developed to increase the performance of the filter used. The noise model will bedeveloped in the following procedure:

1. Sensor data retrieval: Data from the laser sensor will be gathered while Balrogis standing still.

2. Noise analysis: The frequency spectrum of the data gathered in 1. will be analysedand the cross correlation of the noise will be examined. The result of the crosscorrelation should be zero since the different measurements should not be correlated.In case the cross correlation is zero, the noise is white.

TSRT10Marcus Back


LipsPage 25


2014-10-27

3. Noise modelling: The measured data will be compared with known distributionsto determine the properties of the noise. Possible distributions used in the compar-ison will be: Gaussian or Student’s t-distribution. When a suitable distribution ischosen the parameters can be estimated.

6.2.4 Filters

EKF The EKF contains a measurement update and a time update. Putting the equa-tions 6.2, 6.1 and 6.10 together we get

xk+1 = f(xk) + wk

mk+1 = mk

yk = h(xk,mk) + ek

. (6.17)

To implement the filter the Jacobian of the functions f and h has to be calculated.Regarding Cov(wk) = Qk and Cov(ek) = Rk and creating a matrix Hmk

k (c1:Ikk ) (which issparse, with the association j = cik implies that column j of Hmk

k is non-zero), algorithm11.1 on page 295 in [20] will be implemented. The covariances Rk and Qk are tuningparameters, which can be approximated by measuring the data from the sensors.

As the sample rate of the laser is half the sample rate of the other sensors, the EKF-algorithm has to be split in two cases. The above works every other sample. If no newdata from the laser scanner is obtained, the landmarks mk are dropped from yk and thefunction h thus simplifying the EKF-algorithm.

Another alternative is to implement the algorithm found in [21] on page 3, which basicallydoes the same.

Particle filter As both the motion function f(x) and the measurement function h(x,m)are partly non-linear, a PF-approach might be preferable.

See Algorithm 11.3 on page 305 in [20].

As there are many states to be estimated and a regular particle filter scales badly withthe number of states (though linearly with the number of landmarks), the approach of amarginalized particle filter will also be considered.

In the case of the marginalized PF the states can be augmented as

zk =((xnk)T (xlk)

T mTk

)T(6.18)

where xnk is the non-linear part of the state vector xk, xlk the linear part and mk the

landmarks which are linear. The linear Gaussian parts will then be estimated usingKalman filters. See Table 4 in [2] for the distributions, and 6.4 and 6.10 for linearities.

See Algorithm 11.4 on page 308 in [20].

To solve the problem with multi-rate sensors, we either use the measurements availableand alter the matrices describing the functions (f and h) and calculating the state esti-mate given what we know. An alternative is to use an algorithm designed for multi-ratepurposes, such as algorithm 2 on page 3 in [22]. A drawback is that this algorithm requireslinear dynamics (which we do not have). If this is to be used, we either have to linearise

TSRT10Marcus Back


LipsPage 26


2014-10-27

or try to improve the algorithm so it works in the non-linear case. Hence this algorithmwill not be prioritized.

In [23], [24], useful libraries for general SLAM have been investigated. These use a particlefilter.

6.3 Mapping

The mapping subsystem is responsible to create a map of the surroundings of Balrog. Itis also responsible to determine the probability that the whole area has been visited. Itstask is to map the search area and to identify and classify objects from the point cloud.

The subsystem takes state estimates of the position from the positioning subsystem andinformation of detected obstacles from the obstacle detection subsystem as input. Withthis information the subsystem will create a probability map and also a map of the searcharea containing all obstacles.

6.3.1 Obstacle map

The obstacle map is an object containing information of were all detected obstacles arepositioned. This map is dynamic and will come to change when new information is addedfrom the other subsystems.

The obstacles will be represented in a grid, with a resolution which is small enough. Thegrid will contain information whether a specific cell is unsearched, free, occupied withobstacle and occupied with fully discovered obstacle.

The grid will be updated when obstacles (lines) are discovered.

6.3.2 Probability map

The concept of the probability map is to give each square in the grid a probability thatthe square has been explored. The path finding subsystem needs this map to determine ifa square needs to be revisited, that is whether the probability for the square having beenexplored is too low. The probability that a square (i, j) has been explored is updatedaccordingly to

p1:k(i, j) = 1− (1− pk(i, j))(1− p1:k−1(i, j))pk(i, j) = p(|x− r(i, j)| < L)

(6.19)

where p1:k(i, j) is the probability that the square (i, j) has been explored up to timeupdate k, pk(i, j) is the probability that Balrog is sufficiently close to the center of thesquare at the given time sample, pk(i, j) is the probability that the square was exploredup to the previous time sample and r(i, j) is the position of the center of square (i, j). Toestimate the probability of Balrog’s current position, the state estimates of the positionxposk = (x, y)T and its corresponding covariance matrix P pos

k is used. Where P posk is the

top left 2x2 matrix of the state covariance matrix P . The states xposk are assumed tobe Gaussian distributed with expected value xposk and covariance P pos

k . The probability

TSRT10Marcus Back


LipsPage 27


2014-10-27

distribution of xpos in a given time sample k, is then given by the following probabilitydensity function

fX,Y (xpos) =1

2π|P posk |

− 12 e−

12(xpos−xpos)T (P pos

k )−1(xpos−xpos) (6.20)

The probability is updated for the squares (i, j) which are in the perimeter of Balrog andis determined by the grid size. The probability is finally given by summing the weightof each particle within a circle, with radius L, around each square center, see Figure 6.2.This model assumes that the current position is independent of previous measurementswhich is a false assumption, but will work as an approximation.

r(i,j)

L

xpos^

P

Figure 6.2: Concept sketch of how the probability map will be calculated.

TSRT10Marcus Back


LipsPage 28


2014-10-27

7 Route Planning

The task of the route planning subsystem is to provide waypoints to the automatic controlsubsystem. The provided waypoints ensures that the whole searchable area is exploredand mapped. The control subsystem marks waypoints as reached by signaling the routeplanning. The active waypoint can be modified by the route planing subsystem as thecontrol subsystem will fetch the active waypoint each iteration in the control loop. Allthe calculations like obstacle in front and fully discovered will happen in the route planingthread. The new cells discovered calculation will be done by checking if the discrete mapdata structure have a changed time stamp since last time there was a discovery.

7.1 Search algorithm

The search algorithm will be the same as last years with the exceptions of a finer gridsystem as specified in [1] and a different obstacle following algorithm, see section 7.2.

When the robot is initiated there will not be any initial waypoints until the operatorinputs a search area. When this is done, a list of waypoints are generated so the wholearea is explored. This will be accomplished by placing the waypoints in a zig-zag pattern.Since the squares in the grid are smaller than Balrog, way points will be placed withsufficiently intermediate spacing. See Figure 7.1. The flow is described below and inFigure 7.2.

1. Obstacle in front? If yes go to ’Obstacle following mode’ (see Section 7.2), if no goto 2.

2. Reached final way point? If yes, Balrog will revisit squares that have a to lowprobability to have been searched according to the probability map, see section6.3.2, using the A* algorithm and then stop at the final position. This will also setthe route planing in a mode waiting for new user interaction. If we have not reachedthe final waypoint go to 1.

TSRT10Marcus Back


LipsPage 29


2014-10-27

B

Figure 7.1: Zig-zag search pattern. Green dots are waypoints, blue lines are referenceroute for Balrog to follow

TSRT10Marcus Back


LipsPage 30


2014-10-27

Figure 7.2: Program flow of the route planning sub system

TSRT10Marcus Back


LipsPage 31


2014-10-27

7.2 Obstacles

To navigate around the obstacles, the route planning system will create waypoints forthe automatic control system to follow. Waypoints are updated when the route planningnotes that there is a obstacle in front of the robot if the robot is in waypoint mode andwhen new cell (parts of obstacles in their discrete form) is updated if we are in the obstaclefollowing mode.

In waypoint mode the route planing subsystem is sleeping waiting for obstacles to be infront of the robot, then checks the gridded obstacle map if it has been updated. If so, theroute planing subsystem changes to ’Obstacle following mode’. The system flow of the’Obstacle following mode’ is described below.

1. Generate waypoints to the closest undiscovered part of the obstacle by using theA* algorithm. If multiple undiscovered points with the same straight line cost isfound, the A* algorithm is run multiple times. If there are no undiscovered cellsaround the obstacle, generate a new path using A* algorithm to the original (theinitial goal before there was a obstacle in front of the robot) waypoint

2. Wait for new cells to be discovered. When new cells have been discovered go to 1

The grid will have a greater resolution than previous year to make it possible to navigatearound the irregular obstacles smoothly. A margin will be introduced around the obstacleso the A* algorithm does not navigate too close. The margin will be the same as previousversions, i.e. 25 cm on each side of Balrog. The Mapping subsystem in SLAM containsand generates the gridded map including margins, see Section 6.3.1.

TSRT10Marcus Back


LipsPage 32


2014-10-27

8 Mine detection

The mine detection subsystem is responsible for detecting the mines surrounding Balrog.The mines are represented as magnets and are detected using a magnetometer, which isinside the IMU. The algorithms and implementation of the mine detection will not bechanged from last year’s project and will run in a separate thread. This means that amine is detected if the magnetometer is saturated, which occurs at 1.2 Gauss. This valueshould be set in comparison to earth’s magnetic field strength at 0.5 Gauss.

The mine is considered new if the distances between Balrog and already explored minesare sufficiently large. If a new mine is detected, the position of the mine is set to theestimated position of Balrog. Balrog is able to detect mines in a radius of approximately0.5 meters and has no information regarding what direction from Balrogs view point themine is placed. Either we need to implement a search algorithm to estimate the positionbetter or use multiple magnetometers to triangulate the position. But as this is outsidethe scope for this project, we have decided to leave the implementation used last year.

TSRT10Marcus Back


LipsPage 33


2014-10-27

9 Automatic control

The controller part will be mostly unmodified from last year’s project [2]. The controllerwill aim to go straight to the next waypoint, with help of the waypoint list created by theroute planner and the position and bearing estimate provided by the SLAM algorithm.It will do so by trying to minimize the difference between the actual bearing ψk and thebearing ψ∗k required to reach the next waypoint. A flow chart of the control algorithmwhen close to a waypoint is shown in Figure 9.1 and described further in Section 9.1. Thevariables used is shown in Table 9.2.

Figure 9.1: Flow of control algorithm.

9.1 Control equations

The controller consists of two parts, vk and vcorr. Here, vk is the desired speed and vcorris the PD controller according to

vcorr = Kεk +TdTs

(εk − εk−1). (9.1)

TSRT10Marcus Back


LipsPage 34


2014-10-27

Table 9.2: Description of control variables.

Variable Descriptionxk,w x coordinate of next waypoint at time instant k (comes from route plan-

ner)yk,w y coordinate of next waypoint at time instant k (comes from route plan-

ner)xk x coordinate of estimated position of Balrog at time instant k (comes

from SLAM)yk y coordinate of estimated position of Balrog at time instant k (comes

from SLAM)ψk Estimated bearing at time instant k (comes from SLAM)ψ∗k Bearing required to reach the waypoint from current position at time

instant kεk Bearing error at time instant kd Distance between Balrog and the next waypoint at time instant kVmax Maximum allowed speedVmin Minimal allowed speeddlim The radius around a waypoint where Balrog moves slowly and more ac-

curatedreached How close Balrog must be to a waypoint for it to be considered reachedεk,max Maximal allowed bearing errorK Proportional gain constantTd Derivative timeKd Derivative gain constantα Scaling factorvcorr PD controllervk Desired speedvl,k Speed of left tackvr,k Speed of right track

TSRT10Marcus Back


LipsPage 35


2014-10-27

Δx

Δyd

xkyk

xk,w yk,w

Ψk

Ψk*

ϵk

Figure 9.2: Angle error

The bearing error εk can be calculated as

∆xk = xk,w − xk,∆yk = yk,w − yk,d =

√∆x2k + ∆y2k,

ψ∗k = atan2(∆xk,∆yk),εk = ψ∗k − ψk,

(9.2)

and the connection between the variables can be seen in figure 9.2. vk is given by

vk =

0 if εk ≥ εk,max,

min(Vmax

1.2, Kdd+ Vmin) if d ≤ dlim and εk < εk,max or

α(Vmax − |Vcorr|) if d > dlim and εk < εk,max,

(9.3)

and as shown, calculated differently depending on how close to the waypoint the Balrogis and how big the angle error is. α is a scaling factor that can be used to reduce thespeed.

In Figure 9.3 a flow chart for choosing vk is shown.

TSRT10Marcus Back


LipsPage 36


2014-10-27

Figure 9.3: How to choose correct vk.

The speed for the left track, vl,k and right track vr,k is computed by subtracting vcorr fromthe left track and adding it to the right, according to

vl,k = vk − vcorrvr,k = vk + vcorr

(9.4)

with a rotation as a result. Notice that |vl,k| and |vr,k| must be in the range [Vmin, Vmax]for Balrog to move at all.

A waypoint is considered reached if d < dreached. In that case the waypoint is removedand the next waypoint is used instead.

9.2 Proposed values of constants

Table 9.3 lists last project’s references of constants and limits [2]. Those should be a goodstarting point.

Table 9.3: Table of constants and limits.Constant Proposed valueVmax 760 mm/sVmin 100 mm/sdlim 1 mdreached 0.3 mεk,max 20o

α 1 (new this year)

TSRT10Marcus Back


LipsPage 37


2014-10-27

10 Implementation overview

This section presents an overview of the implementation of Balrog and its subsystems.In Figure 10.1, an overview of the different subsystems of Balrog and the shared datastructures is given. An arrow pointing from a subsystem to a data structure indicatesthat the subsystem is writing to the data structure. An arrow pointing from a datastructure to a subsystem indicates that the thread is reading from a data structure.

Figure 10.1: Illustration of subsystems, shared data structures and hardware

The key concepts for our implementation is summarized in the following list:

• Each subsystem must be independent of the other subsystems and must be able torun as a standalone application. All dependencies must be passed in at instantiation.This allows a high degree of decoupling between the different subsystems and theycan be developed in parallel and tested independently of each other.

• Each subsystem can either run periodically or once when they are called.

• Shared data structures can be shared between subsystems. All operations in theshared data structures must be implemented as if they were atomic to avoid con-currency problems.

TSRT10Marcus Back


LipsPage 38


2014-10-27

10.1 Shared data structure

Shared data structures holds common data in the system. The data is shared betweendifferent subsystems by passing in a reference to the data when the subsystem is instan-tiated. All data manipulation (such as add and get) must be implemented to be safe forconcurrency, race condition etc. In practice this might mean mutually exclusive locks etc.,but the objects using the shared data structures can be ignorant of this and use them asif all manipulating tasks were atomic.

All shared data structures inherits from ASerializable, meaning it is possible to serializeand deserialize the object to and from a stream, this to be able to send them via the datalink.

10.1.1 Sensor data

The sensor data is stored in the class SensorSamples that maintains a list of sensorsamples and provides methods for adding and retrieving sensor samples. The publicmember functions (except for the constructor and destructor) to be used are listed inTable 10.1

Table 10.1: List of public member functions in SensorSamples classMethod name Argument type Descriptionadd ASensorSample Adds a sensor sample (the argument)

to the sensor samples.getLatest n/a Returns the sensor sample with the

most recent time stamp.getAfter const std::time t Returnes a vector with all sensor sam-

ples more recent than the argument in-dicates.

count n/a Returns the number of sensor samplesin the collection.

10.2 Subsystems

Subsystems inherits from the class ARunnable and are all completely isolated subsystems.As long as they are instantiated with the correct parameters (such as references to shareddata structures and other subsystems), they must be able to run independently of theother subsystem. This allows a high degree of decoupling between subsystems and theycan easily be tested and developed in parallel. In Table 10.2 the public member functionsfor the classes that inherrit from ARunnable can be seen.

TSRT10Marcus Back


LipsPage 39


2014-10-27

Table 10.2: List of member functions in ARunnable sub-classesMethod name Argument type Descriptionwork n/a Contains the entry point of the sub-

system. Execution starts here. If thesubsystem was a stand alone applica-tion the work method (or possibly aloop that periodically calls the workmethod) would be the main method.

run n/a Runs the work method once. The in-ternal state may be updated and kept.

run int periodtime Runs the work method periodically.The periodtime is in nanoseconds.

stop n/a Stops the subsystem after the currentexecution of the work method is done.Internal state is kept and will be re-sumed from when run is called again.

reset n/a Resets the subsystem internal state. Ifthe subsystem is running the state willbe reset after the current execution ofthe work method.

Each subsystem runs in its own thread. The thread instantiation is taken care of au-tomatically in the ARunnable class and is nothing we need to consider when using theobjects. Each subsystem may in turn spawn new internal subsystems based on the sameprinciple as above. For example the SLAM subsystem may spawn subsystems in its ownthread to process data in parallel. Each subsystem must be instantiated. Usually someof the shared data structures are passed as arguments to the constructor. A subsystemmight need to be able to read the shared data or even to manipulate it.

Subsystems may also need references to other subsystems. For example the SLAM subsys-tem might carry a reference to the route planner. If for example the route planer runsevery time a new obstacle is detected, the slam system, which is responsible for detectingobstacles, needs to notify the route planner that it must run. With a reference to theroute planner it can call the route planner’s int run() method, making the route plannerrun once.

TSRT10Marcus Back


LipsPage 40


2014-10-27

11 Program flow

In this section the general program flow of Balrog is described. In Appendix B the codingstandard for the project is shown. The different classes used on Balrog is listed anddescribed briefly in Appendix A.

11.1 Starting up the program

The start up procedure is as follows

• Instantiate all shared data structures

• Instantiate all subsystems, pass references to shared data structures and other sub-systems if needed

• Start all subsystems

When all subsystems have been started route planning waits for a new search area to beadded via the base station communication. When this have been done way points aregenerated and the control loop starts navigation to the next way point.

11.2 Threads

Figure 11.1 is a schematic overview of the different threads in the system. The commu-nication between the threads is mainly handled through shared data structures. Routeplanning is running on a variable tick dependant of the state state the planning. All otherthreads run periodically in a given tick. All I/O run in separate threads to minimize theeffect of external unperiodic behavior.

TSRT10Marcus Back


LipsPage 41


2014-10-27

Ticks Slowly

Ticks 11Hz

Ticks 11Hz+

Ticks 2-5.5Hz

Ticks 5.5Hz

Ticks 11Hz

Ticks 11Hz

Ticks 11Hz

Positioning

Route planning

Control

IMU

ComARM/Odometers

Laser scanner

GPS

Hardware

Software

Component

Description

MappingObstacle detection

Propulsion

Mine detection

Base station

Hand controller

Thread

Ticks SlowlyAll sub system data structures

Ultrasonic

Ticks 11Hz

Figure 11.1: Schematic overview of information and threads.

Last year the threading library used was Qt, however this year will use Linux Pthreadsinstead. As we plan to use shared data structures we don’t need signals and slots (eventdriven scheduling) to send information between threads, which was used last year in Qt.This option still exists with Pthreads but is implemented differently. When signals andslots are not used the scheduling of the threads and the priority of each thread becomesmore important.

TSRT10Marcus Back


LipsPage 42


2014-10-27

References

[1] Marcus Back. Requirement specification, September 2014. http://www.isy.liu.se/edu/projekt/tsrt10/2014/bandvagn/Documents/Requirement_specification_

v1.0.pdf.

[2] Emmeline Kemperyd. Teknisk Dokumentation Minrojningsbandvagn, December2013. http://www.isy.liu.se/edu/projekt/tsrt10/2013/bandvagn/teknisk_

dokumentation.pdf.

[3] i2cchip.com. BL233B, RS232 I2C/SPI/1WIRE ADAPTOR & CONTROLLER, Ok-tober 2014. http://www.i2cchip.com/pdfs/bl233_b.pdf.

[4] u-blox AG. u-blox 5 Receiver Description, November 2009. http:

//www.u-blox.com/images/downloads/Product_Docs/u-blox5_Protocol_

Specifications(GPS.G5-X-07036).pdf.

[5] Robot Peak Team. RPLIDAR Introduction and data sheet, May 2014. http://

rplidar.robopeak.com/download.html.

[6] Silicon Labs. Serial Communications Guide for the CP210x. http://www.silabs.

com/Support%20Documents/TechnicalDocs/an197.pdf.

[7] Robot Peak Team. RPLIDAR Interface Protocol, Mars 2014. http://rplidar.

robopeak.com/download.html.

[8] Micro Strain. 3DM-GX1 Gyro Enhanced Orientation Sensor Technical Overview,3.1.02 edition, September 2014. http://files.microstrain.com/3DM-GX1%

20Datasheet%20Rev%201.pdf.

[9] Micro Strain. Detailed Specifications For 3DM-GX1, September 2014.http://files.microstrain.com/3DM-GX1%20Detailed%20Specs%20-%20Rev%

201%20-%20070723.pdf.

[10] Micro Strain. 3DM-GX1 Data Communications Protocol, 3.1.02 edition,September 2014. http://files.microstrain.com/manuals/3DM-GX1%20Data%

20Communication%20Protocol%203102.pdf.

[11] Robot Electronics. SRF10 Ultrasonic range finder Technical Specification. http:

//www.robot-electronics.co.uk/htm/srf10tech.htm.

[12] I2Cchip. BL233 Datasheet. http://www.i2cchip.com/pdfs/bl233_b.pdf.

[13] Hartmut Schimmel. Connecting AT91xx based GPS-Loggers to USB on Linux. http://www.schimmelnetz.de/projekte/iTU4l/usb.html.

[14] Persistent names for usb-serial devices. http://hintshop.ludvig.co.nz/show/

persistent-names-usb-serial-devices/.

[15] Best way to set serial port speeds on boot? http://unix.stackexchange.com/

questions/91458/best-way-to-set-serial-port-speeds-on-boot.

TSRT10Marcus Back


LipsPage A

http://www.isy.liu.se/edu/projekt/tsrt10/2014/bandvagn/Documents/Requirement_specification_v1.0.pdf



http://www.isy.liu.se/edu/projekt/tsrt10/2013/bandvagn/teknisk_dokumentation.pdf

http://www.isy.liu.se/edu/projekt/tsrt10/2013/bandvagn/teknisk_dokumentation.pdf

http://www.i2cchip.com/pdfs/bl233_b.pdf

http://www.u-blox.com/images/downloads/Product_Docs/u-blox5_Protocol_Specifications(GPS.G5-X-07036).pdf



http://rplidar.robopeak.com/download.html


http://www.silabs.com/Support%20Documents/TechnicalDocs/an197.pdf

http://www.silabs.com/Support%20Documents/TechnicalDocs/an197.pdf



http://files.microstrain.com/3DM-GX1%20Datasheet%20Rev%201.pdf

http://files.microstrain.com/3DM-GX1%20Datasheet%20Rev%201.pdf

http://files.microstrain.com/3DM-GX1%20Detailed%20Specs%20-%20Rev%201%20-%20070723.pdf

http://files.microstrain.com/3DM-GX1%20Detailed%20Specs%20-%20Rev%201%20-%20070723.pdf

http://files.microstrain.com/manuals/3DM-GX1%20Data%20Communication%20Protocol%203102.pdf

http://files.microstrain.com/manuals/3DM-GX1%20Data%20Communication%20Protocol%203102.pdf

http://www.robot-electronics.co.uk/htm/srf10tech.htm

http://www.robot-electronics.co.uk/htm/srf10tech.htm

http://www.i2cchip.com/pdfs/bl233_b.pdf

http://www.schimmelnetz.de/projekte/iTU4l/usb.html

http://www.schimmelnetz.de/projekte/iTU4l/usb.html

http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/

http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/

http://unix.stackexchange.com/questions/91458/best-way-to-set-serial-port-speeds-on-boot

http://unix.stackexchange.com/questions/91458/best-way-to-set-serial-port-speeds-on-boot


2014-10-27

[16] Agostino Martinelli Nicola Tomatis Roland Siegwart Viet Nguyen, Stefan Gachter.A comparison of line extraction algorithms using 2D range data for indoor mo-bile robotics. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=

1545234.

[17] Seungpyo Hong. Improved Motion Tracking with Velocity Update and DistortionCorrection from Planar Laser Scan Data, 2008. http://www.imrc.kist.re.kr/

MediaWiki/images/3/35/laser_tracking.pdf.

[18] Andrea Censi. An ICP variant using a point-to-line metric, May 2008. http://

censi.mit.edu/pub/research/2008-icra-plicp.pdf.

[19] Andrea Censi. Canonical Scan Matcher. http://censi.mit.edu/software/csm/.

[20] Fredrik Gustafsson. Statistical Sensor Fusion, 2012.

[21] Josep Tomero Leopoldo Armesto. SLAM Based on Kalman Filter for Multi-rateFusion of Laser and Encoder Measurements, September 2004. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1389668.

[22] Fredrik Gustafsson Thomas B Schon, David Tornqvist. FAST PARTICLE FILTERSFOR MULTI-RATE SENSORS, 2007. http://user.it.uu.se/~thosc112/pubpdf/schontg2007.pdf.

[23] Ronald Parr. DP-SLAM, 2003. http://www.cs.duke.edu/~parr/dpslam/.

[24] Ronald Parr Austin I. Eliazar. DP-SLAM 2.0. http://www.cs.duke.edu/~parr/

dpslam2.pdf.

[25] Tomas Svensson and Christian Krysander. LIPS – niva 1. Version 1.0, 2002.

TSRT10Marcus Back


LipsPage B

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1545234


http://www.imrc.kist.re.kr/MediaWiki/images/3/35/laser_tracking.pdf

http://www.imrc.kist.re.kr/MediaWiki/images/3/35/laser_tracking.pdf

http://censi.mit.edu/pub/research/2008-icra-plicp.pdf

http://censi.mit.edu/pub/research/2008-icra-plicp.pdf

http://censi.mit.edu/software/csm/



http://user.it.uu.se/~thosc112/pubpdf/schontg2007.pdf

http://user.it.uu.se/~thosc112/pubpdf/schontg2007.pdf

http://www.cs.duke.edu/~parr/dpslam/

http://www.cs.duke.edu/~parr/dpslam2.pdf

http://www.cs.duke.edu/~parr/dpslam2.pdf


2014-10-27

Appendices

A Balrog classes

Class name Short descriptionAMeasureModel An abstrace base class for a measurement modelAMotionModel An abstrace base class for a motion modelARunnable Abstract class for making child classes runnable using

pthreadsARunOnce Abstract class for making child classes runnable using

pthreadsASampler Abstract class for Sampler child classes, inherits from

ARunnable

ASensorSample A container for a generic sensor sampleCartesian A container for a cartesian object with an x,y and z coordinateCommunication Class for the Communication, inherits from ARunnable

Controller Class for the automatic controll, inherits from ARunnable

GpsSample A container for a GPS sampleGpsSampler Class for sampling the GPS sensor, inherits from Asampler

ImuSample A container for an IMU sampleImuSampler Class for sampling the IMU, inherits from Asampler

ISerializable All objects that are serializable inherits from this classKalman The Kalman filter handeling the sensorfusionLaserSample A container for a GPS sampleLaserSampler Class for sampling the Laser sensor, inherits from Asampler

Map Class for map representationMine A structure wraping the statevector with a timestampMines A list of Mine t’sOdometerSample A container for a Odometer sampleOdometerSampler Class for sampling the Odometers, inherits from Asampler

ParticleFilter A particle filter using prior samplingRoutePlanner Class for the route planningSearchArea Describes the area to be searched and if it have been soSensorEnumerator This is a class responsible for returning the path for the dif-

ferent sensors com ports e.i /dev/tty*SensorSamples A list of generic sensor samplesSlam Class for the SLAM, inherits from ARunnable

State A structure wraping the statevector with a timestampStates A list of State t’sUltrasonicSample A container for a Odometer sampleUltrasonicSampler Class for sampling the Ultra sonic sensor, inherits from

Asampler

Waypoint A structure wraping the statevector with a timestampWaypoints A list of Waypoint t’s

TSRT10Marcus Back


LipsPage C


2014-10-27

B Coding standard

The goal of coding standards is to increase the business value of the code. The mostobvious (and indeed most important) way to do this is to make the code robust andcorrect. Equally important, but more subtle goals include reducing coder friction andmaintainability.

The aim of this coding standard document is to keep it short and simple, therefore itmight not cover all possible situations. If an undocumented situation appears, bring itup for discussion and add it to the standards!

Good code is

• Straightforward, not clever

• Understandable to somebody who has not seen the code before

• Consistent

• Well documented

General rules

• Eliminate duplicate code - Any code that is used twice must be refactored outand put in a common class

• Choose great names for your classes, methods and variables - they should be selfdescriptive rather than short

• Comment the what and why rather than the how, the code in itself should beself explanatory, comments should not duplicate what the code says

• Declare variables in the most limited scope possible

• Prefer small and focused functions

• Prefer function overloading rather than default arguments

• Always include curly braces on conditional and loop statements

• Use explicit constructor

• No compiler errors or warnings from the final code

Namespace

• Wrap all classes and objects in the namespace Balrog

• Do not use using namespace anywhere, it pollutes the global space.

TSRT10Marcus Back


LipsPage D


2014-10-27

Header files

Header files ends in .h and is named after the class or data structure inside it, for exampleClassName.h and are placed in a include directory.

All header files must avoid header collision by wrapping the code in the header file

1#ifndef BALROG_CLASS_NAME_H

2#define BALROG_CLASS_NAME_H

3

4...

5

6#endif // BALROG_CLASS_NAME_H

Declaration order within a class

• Public before private,

• Methods before data members (variables), etc.

Class definitions must start with its public section, followed by its protected section andthen its private section. If any of these sections are empty, omit them.

Within each section, the declarations must be in the following order:

• Typedefs and Enums

• Constants (static const data members)

• Constructors

• Destructor

• Methods, including static methods

• Data members (except static const data members)

Source files

All source files ends with .cpp and are placed in a src directory.

Naming formats

• Classes: Camelcase, i.e. ClassName

• Abstract classes: Prefix classname with A, i.e. AClassName

• Interfaces: Prefix classname with I, i.e. IClassName

• Variables: Lower camel case, i.e. myVariable

TSRT10Marcus Back


LipsPage E


2014-10-27

• Member functions: Lower camel case, i.e. myFunctionName()

• Constants: Upper case and underscroes, i.e. I AM GLOBAL

• Getters and setters: Lower camel case with get/set prefix, i.e. getMyVariable

• Private variables: Postfix underscore, i.e. myPrivateMember

Initialize variables upon creation

1int i=10; // This is correct

2

3int i;

4i=10; // This is wrong

Use of const

• All member functions not altering the state of the object must be marked const

• All member variables that do not change during the lifetime of the object must bemarked const

• All method parameters not modified in the method must be marked const

Memory semantics

The use of pointers and references is sometimes error prone. Who is responsible of cleaningup and freeing memory?

• Passing a pointer to an object or method means that this object is responsible forcleaning it up

• Passing a reference means that the caller retains ownership

Inheritance

Classes should extend from at most one class that is not abstract or an interface. Theremight be exceptions to this rule, but think carefully. Twice.

Globals

Never use globals. There might be exceptions to this rule, but think carefully. Twice.

TSRT10Marcus Back


LipsPage F


2014-10-27

Comments

Comments are written in Doxygen javadoc style. All classes and methods MUST be doc-umented. All high level comments are kept in the header files. Only short implementationspecific comments are in the cpp files.

Classes

Include at least a general description of the class and its purpose.

Methods

At least the purpose of the method along with input and output must be documented,also include information about exception and error handling.

Automatically generated constructors and operators

Remove copy constructors and copy operators if they are automatically generated butrender unexpected behaviour. Always implement them if it makes sense.

Source format

• Use tabs, 2 spaces wide

• Namespaces do not add an extra line of indentation

• Line width: 80

Conditionals

1if(condition)

2{ // spaces inside parentheses - rare

3...

4}

5else

6{

7...

8}

Loops

1for(int i = 0; i < kSomeNumber; ++i)

2{

3printf("i");

4}

TSRT10Marcus Back


LipsPage G

Editor: Johan K allstr om Version 1 - Linköping University · Autonomous mine sweeper - Balrog...

Documents

Transcript of Editor: Johan K allstr om Version 1 - Linköping University · Autonomous mine sweeper - Balrog...