DEVELOPING CAPABILITIES OF ACCURATE LOCATING AND OBJECT AVOIDANCE OF AN AUTONOMOUS ROVER
Applicability of LiDAR rangefinder and RTK NTRIP technology in the conditions of an athletics event
M.Sc. Thesis Faculty of Engineering and Natural Sciences Examiner: Prof. Minna Lanz, Prof. tenure track Roel Pieters February 2021
ABSTRACT
Tommi Ylimäki: Developing capabilities of accurate locating and object avoidance of an autonomous rover
M.Sc. Thesis Tampere University
Digital Manufacturing and Data Handling February 2021
Autonomous robots are a subtype of robotics with a wide range of applications in industry, military, warehousing and many other fields of activity. Key needs and challenges for autonomous operations include sensor data processing, location capability, and the ability to detect and avoid collisions with other physical objects. In this study a prototype of a self-propelled vehicle that can be used to return throwing equipment at athletics competitions was further developed. The research started from a platform that was devised in the previous project, utilizing ArduRover autopilot software and a PixHawk flight control unit.
In order to utilize the prototype at athletics events, it must be able to locate itself more accu- rately than conventional GPS positioning allows and to detect and circumvent physical obstacles on the athletics field. The study experimented with improving satellite positioning accuracy with RTK technology and target detection with a LiDAR rangefinder.
The research builds on the V-model for system development, prototyping and risk assessment methods (ISO-12100). The result of the study was a prototype that, under ideal conditions, is able to dodge objects independently, but whose production use requires further development to ensure adequate safety. A list of 9 recommendations for future work was aggregated as a guideline to this development.
Keywords: Autonomous Rover, ArduPilot, LiDAR, RTK, Athletics
The originality of this thesis has been checked using the Turnitin OriginalityCheck service.
TIIVISTELMÄ
Tommi Ylimäki: Autonomisen ajoneuvon paikannuksen ja kohteen väistämiskyvyn kehittäminen Diplomityö
Tampereen yliopisto
Digitaalinen valmistus ja data käsittely Helmikuu 2021
Autonomiset robotit ovat eräs robotiikan alalaji, joilla on runsaasti käyttökohteita muun muas- sa tuotannossa, armeijassa, varastotoiminnassa kuin monilla muillakin toimialoilla. Autonomisen toiminnan keskeisiä tarpeita ja haasteita ovat anturidatan käsittely, paikannuskyky ja kyky havai- ta muita fyysisiä kohteita sekä välttää törmäämästä näiden kanssa. Tässä tutkimuksessa kehi- tettiin eteenpäin itsenäiseen toimintaan kykenevän ajoneuvon prototyyppiä, jota voidaan käyttää yleisurheilukilpailuiden heittovälinepalautuspalvelussa. Tutkimus lähti liikkeelle aiemmassa pro- jektissa toteutetusta alustasta, jossa hyödynnettiin ArduRover-autopilottiohjelmistoa ja PixHawk- autopilottiohjainta.
Jotta prototyyppiä voitaisiin hyödyntää yleisurheilutapahtumissa, tulee sen kyetä paikanta- maan itsensä tavanomaista GPS-paikannusta tarkemmin sekä havaitsemaan ja kiertämään ken- tällä olevat fyysiset esteet. Tutkimuksessa kokeiltiin satelliittipaikannuksen tarkkuuden paranta- mista RTK-teknologialla ja kohteiden havaitsemista LiDAR-etäisyysmittarilla.
Tutkimus tukeutuu järjestelmäkehittämiseen tarkoitetun V-malliin ja siinä hyödynnetään proto- typoinnin sekä riskienarvioinnin menetelmiä (ISO-12100). Tutkimuksen lopputuloksena syntyi pro- totyyppi, joka ihanneolosuhteissa kykenee väistämään kohteet itsenäisesti, mutta jonka tuotanto- käyttö vaatii jatkokehittämistä riittävän turvallisuuden takaamiseksi. Tutkimuksen lopuksi koottiin yhdeksänkohtainen lista tuon jatkokehittämisen ohjenuoraksi.
Avainsanat: Itsenäinen ajoneuvo, ArduPilot, LiDAR, RTK, Yleisurhelukilpailu Tämän julkaisun alkuperäisyys on tarkastettu Turnitin OriginalityCheck -ohjelmalla.
PREFACE
This thesis is an outcome of over three years long journey into the world of engineering science. It combines many topics covered during courses of this schooling, beginning from risk assessment and project planning, continuing to requirements analysis, struc- tural design, architecture planning of subsystems and ending to configuring Linux and embedded systems - not forgetting a little bit of web applications, of course.
It is a demanding task to fluently combine studies, work and family life. Now, at the final stages of this challenge, I have an emotional feeling. Really, have I been through all this and still standing on my own feet? And on the other hand, am I now ready to take the work challenges meant to be taken with this master of science examination?
My previous master’s thesis related to studying surface layers of paper with micro-CT technology. In it’s preface I proudly announced that it took one and a half month to put the text together. Now, with topic that compounded my long-time hobby of radio con- trolled cars and more recent objects of interest i.e. autonomous drones, a longer time was needed to put things up. Drones (or ground rovers in this case) are a combination of multitude technological achievements and it is almost frustrating that not even the cor- nerstones (like IMU, GNSS positioning, sensor fusion etc) can be studied in depth with the given time limitations. Actually, to make it possible at all to write this thesis and to conduct the research work behind it, a six-month scholarship given from the University of Tampere was direly needed. I’m grateful for this possibility and all the support I got from my supervisor professor Minna Lanz.
As well as in preface of my previous thesis, I’m again very curious to see, what kind of doors and possibilities this diploma opens. Like in previous case, those paths remain beyond thick fog of uncertainty. Still, I think, this has been a proper choice among the possible paths that were available back in 2018. As so, now it is a time to stop running for a while, get a deep breath and celebrate this milestone. Thank You Lord for allowing me to reach it!
Seinäjoki, 15th February 2021
Tommi Ylimäki
CONTENTS
1 Introduction . . . 1
1.1 Business problem and motivation of research . . . 3
1.1.1 Background . . . 3
1.1.2 Next steps of development . . . 5
1.2 Research structure . . . 6
1.2.1 Research objectives and questions . . . 6
1.2.2 Research methods . . . 6
1.2.3 Thesis structure . . . 7
2 Background . . . 8
2.1 Systems engineering . . . 8
2.2 Risk assessment . . . 13
2.3 Matching methods . . . 17
2.4 Emerging Technologies for unmanned vehicles . . . 19
2.4.1 Open source autopilot software: ArduPilot (ArduRover) . . . 19
2.4.2 Communication between vehicle and ground control system: Mi- cro Air Vehicle Link 2 . . . 21
2.4.3 Open source autopilot hardware: Pixhawk flight control unit . . . . 21
2.4.4 Internet connection via companion computer . . . 22
2.4.5 Limitless telemetry range: ZeroTier Software Defined Wide Area Network . . . 23
2.4.6 Sensing surroundings: Rangefinders . . . 23
2.4.7 Satellite-based positioning technologies . . . 24
3 Design and implementation . . . 26
3.1 Previous work and starting state . . . 26
3.2 Feasibility study and concept exploration . . . 26
3.2.1 Validation plan . . . 28
3.2.2 Limits of the system (ISO-12100) . . . 28
3.2.3 Hazard identification . . . 30
3.2.4 Risk assessment . . . 31
3.3 System requirements . . . 33
3.3.1 System verification plan . . . 34
3.3.2 Test track . . . 34
3.4 System design . . . 37
3.4.1 System architechture . . . 37
3.4.3 Subsystem verification and unit test plan . . . 45
3.4.4 Steps of prototyping . . . 46
3.5 Development and testing . . . 47
3.5.1 Step 1: Test connection board . . . 47
3.5.2 Step 2: Moving small rover . . . 57
3.5.3 Step 3: Moving full scale rover . . . 66
3.6 Verification . . . 72
3.6.1 Test track sequences . . . 72
3.6.2 Risk evaluation . . . 74
3.7 System validation . . . 76
4 Results . . . 78
4.1 Final assembly and architecture . . . 78
4.2 Test results . . . 79
5 Discussion . . . 82
5.1 Recommendations and future work . . . 86
References . . . 89
Appendix A ArduPilot attributes . . . 96
LIST OF FIGURES
1.1 Figures of different drones and rovers. . . 4 2.1 Systems Engineering "V" diagram according to [12] . . . 9 2.2 A map of the prototyping strategy space. WhereIiCnis theith iteration of
thenth concept. Each block represents a single prototype or build. Grey area depicts that each build has several factors of construction. The num- ber of iterations of each concept may vary. This process can be applied at the system, subsystem and component level. (According to [24]) . . . 13 2.3 The simplified functional safety methodology based on ISO 12100 and ISO
13849 . . . 16 2.4 Matched V-model and ISO-12100 risk analysis methods and prototyping
techniques. Certain V-model phases are merged to form a total of six separate phases. Dashed borderlines separate original V-model phases to make figure comparable with figure 2.1. V-model’s horizontal connecting lines between left and right side are not displayed to make figure clearer and more readable. Operations and maintenance phase is not executed in this research. . . 18 2.5 The basic structure of ArduRover’s architecture, according to https://
ardupilot.org/dev/docs/learning-ardupilot-introduction.html. 20 2.6 ArduRover high level architecture according tohttps://ardupilot.org/
dev/docs/rover-adding-a-new-drive-mode.html. . . 20 2.7 MAVLink 2.0 header according to [1] . . . 21 3.1 Typical obstacles on field: officials, photographers, camera stands, screens
and billboards. Photographs were shot in Finnish national championship competition Kalevan Kisat 2020. . . 29 3.2 The starting point for designing high level architechture for RecoveryCar
system was taken from the initial development project [8]. The Recov- eryCar unit is an autopiloted rover that can transfer telemetry (MAVLink) data with ground control station (GCS). The GCS runs a python script to communicate with web application to get new coordinates (waypoints) fed by staff with their smartphones (web browsers utilizing Geolocation API).
Arrows show directions of communication and dashed lines connections between entities. . . 38
internet connections are linked via virtual LAN (SDWAN), basic GPS unit is replaced with RTK unit, a rangefinder, LTE WLAN router and companion computer are attached to rover and powered from 5V DC-DC converter
power supply. . . 40
3.4 Pinout of Rasberry Pi 4 GPIO headerhttps://www.raspberrypi.org/ documentation/usage/gpio/ . . . 48
3.6 MAVProxy test connection . . . 50
3.7 A successful UDP test connection . . . 51
3.8 Test connection board without RTK and LiDAR units . . . 52
3.11 JST-GH - DF13 + jumper connector serial connection between Reach M+ module and PixHawk + DC-DC converter . . . 54
3.13 ReachView Status screen showing RTCM corrections from NTRIP caster. Positioning accuracy is order of tens of centimeters even though baseline is67kmwhich is considerably more than the officially supported10km. . 56
3.14 Detailed design schematics of autopilot hardware after prototyping step 1. 56 3.17 Final assembly of prototyping step 2. LTE-WLAN module is powered from Raspberry USB port. GNSS mast, telemetry radio and PixHawk Power- module are removed. . . 61
3.18 RPLidar2A rangefinder accuracy testing from various distances. A 55· 30cmplywood sheet and30cmred plastic cones as test objects. "Radar" screen on right is the proximity view of Mission Planner ground control software. . . 62
3.19 RPLidar2A rangefinder detection range testing from and against daylight Sun. A55·30cmplywood sheet as a test object. The greatest measurable distance from the Sun was10mbut against it the test object could not be reliably detected even if the rover collided with it. Screens on right are the map views of Mission Planner ground control software, showing detected objects as red circles. . . 63
3.20 An example of fake object detections (red circles north from rover symbol) on object-free parking lot asphalt. These fake detections proved to be a problem for object avoidance algorithms. . . 63
3.21 Object avoidance test using Bendy ruler algorithm. The rover started from point 0, was called to point 1 (with mobile phone from web application) and then commanded to return via pre-planned mission (green spots). Red triangle and circles are virtual fences which represent objects. Without object avoidance the rover should have taken route 1 from starting point and routes 2 and 3 but because of avoidance algorithm it could pass these barriers and found a clear pathway. . . 64
3.22 Detailed design schematics of autopilot hardware after prototyping step 2.
Major changes to step 1 are removal of separate PixHawk Power module and addition of speed controller, motor, steering servo and relay connec- tion from Raspberry Pi pin 32 and PixHawk aux 6 PWM pin. . . 65 3.23 Detailed design of prototyping step 3. . . 67 3.24 Detailed design of prototyping step 3. . . 68 3.25 Final version of prototyping step 3. Note white rig that represents the real
payload carry rack. Only the compass unit need a relocation when the rig is removed. . . 69 3.26 Lowered ground clearance stabilized the rover’s chassis so that LiDAR
didn’t produce fake measurements during sharp turns. . . 69 3.27 Detailed design schematics of autopilot hardware after prototyping step 3.
Major changes to step 2 are removal of "general" GNSS receiver module (only compass left) and addition second (parallel) battery and connectors between batteries, DC-DC converter and speed controller. . . 70 3.28 Test track sequence #1-2 example routes. . . 74 3.29 Test track sequence #2-1 to #3-2: a linear mission (solid yellow line) be-
tween two points with an obstacle in middle of the route. The rover has been able to find a clear way pass obstacle (red circles) but eventually could not evade it and has stopped in front of it. . . 75 3.30 . . . 76 3.31 Test track sequence #5-3 avoiding fenced exclusion area. . . 76
LIST OF TABLES
2.1 Mapping between techniques and commonly associated objectives. Re-
lated techniques are indicated with a solid circle (according to [24]) . . . . 12
2.2 ISO-12100 risk assessment scoring matrix (according to [40]). . . 17
3.1 Estimated price of parts list needed for autonomous rover (in addition to equipment that is used in manually driven throwing equipment recovery service cars) . . . 27
3.2 Risk evaluation . . . 32
3.3 System requirement analysis (limited to scope of the research) . . . 35
3.4 Requirement verification plan . . . 36
3.5 Rangefinder comparison . . . 42
3.6 RTK comparison . . . 44
3.7 Comparison of companion computers features . . . 45
3.8 Prototyping steps plan . . . 47
3.9 Results of rangefinder tests. See figures 3.18 and 3.19 for reference. . . . 62
4.1 Measured performance chart . . . 81
5.1 Recommendations and future work . . . 86
A.1 ArduRover parameters after prototyping step 3 . . . 96
LIST OF SYMBOLS AND ABBREVIATIONS
AV Autonomous Vehicle
CC Companion Computer (Raspberry Pi 4b in this thesis’ context) Drone Drone is a mobile unmanned autonomous robot capable of navigat-
ing and moving to given point(s) and performing other tasks with or without human supervision. Commonly "drone" is seen to mean exclusively airborne vehicle but practically same hardware and to large extent also software are used in both airborne and ground vehicles (or "rovers").
FCU Flight Control Unit
flight stack The autopilot software which actually controls the vehicle is run by the operating system of the Flight Control Unit hardware. Open source ArduPilot flight stack is used in this thesis.
FPU Floating Point Unit FPV First Person View GCS Ground Control System
GNSS Global Navigation Satellite System GPS Global Positioning System
GUI Graphical User Interface
IAAF International Association of Athletics Federations LiDAR Light Detection and Ranging
LTE Long-Term Evolution, a standard for wireless broadband communi- cation for mobile devices
MAVLink MAVLink (the Micro Air Vehicle Link) is a communication protocol for unmanned systems (e.g., drones, robots) [1]
NTRIP Networked Transport of RTCM via Internet Protocol PoC Proof-of-Concept
PWM Pulse Width Modulation
REST-API Representational State Transfer Application Programming Interface
that makes it easier to develope software for robot applications1. Rover Rover is an unmanned ground-rovering robot capable of navigating
and moving to given point(s) and performing other tasks with or without human supervision.
RSSI Received Signal Strength Indicator
RTCM Radio Technical Commission for Maritime Services RTK Real Time Kinematics
RTLS Real-Time Locating System
SD-WAN Software Defined Wide Area Network SLAM Simultaneous locating and mapping
UART Universal Asynchronous Receiver Transmitter UAV Unmanned Aerial Vehicle
UGV Unmanned Ground Vehicle
1Source: http://wiki.ros.org/Documentation, visited 5.8.2020.
1 INTRODUCTION
Mobile autonomous vehicles (AV), were they airborne UAVs1 or ground-bound UGVs2, have gradually gained high popularity in various industries both among hobbyist and in commercial use. Were it transportation, industrial production, army, commerce, photogra- phy or just leisure, these robots already have multiple areas of use and new ones emerge in a continuous manner. One of the most popular and well-known sector of autonomous vehicles is self-driving cars. According to [2], many giants in automotive and also in soft- ware industries (like Daimler, Tesla, Google and Apple to mention a few) have massive research and development programs related to autonomous vehicles.
One of the biggest challenges of designing autonomous vehicles is to harness data from different sensors. Typical designs include usage of LiDAR3, radar, ultrasonic sensors, inertial measurement units and stereo vision ([3] and [4]). Many modern AVs apply SLAM4 algorithms to navigate among physical obstacles [5]. In simpler applications algorithms like RTLS5and Sensor Fusion are also used [6]. To compare outcomes and performances of different designs, Society of Automotive Engineers (SAE) International publishes a classification system that standardizes levels of automation. This classification defines six automation levels from fully manual to fully autonomous vehicles [7]:
• Level 0: The system handles warnings but doesn’t control vehicle.
• Level 1: The system works with driver, features provide steering or brake/accelera- tion support. eg. adaptive cruise control (ACC) OR lane centering.
• Level 2: accelerating, steering and braking are controlled by the system, but the driver supervises supporting features and is ready to take control if needed.
• Level 3: The driver must drive only if features request it. Features can drive vehicle under limited conditions if all requirements are met.
• Level 4: No more human driving but these features work only in limited conditions.
• Level 5: No human involvement required any more. Features work in all conditions.
1Unmanned Aerial Vehicle
2Unmanned Ground Vehicle
3Light Detection and Ranging, a method for measuring distances by metering time of flight of laser light reflected from objects
4Simultaneous Localization And Mapping
5Real-Time Locating System
tonomous operation requires advanced linear accelerometers, gyros, positioning equip- ment, compasses, range finders and ability to fuse and then exploit meterings from these sensors. Miniaturization, mass production and open source activity have made it possi- ble to squeeze both size and price of these technological achievements to levels which are usable and affordable also in small scale and hobbyist budget vehicles. Because of this availability of these essential building blocks, small scale autonomous vehicles have become almost ubiquitous pieces of technology around us during about last ten years - be it aerial drones or ground rovers. Although there is no distinct point in history that could be seen as a start of this journey, some examples can be brought up to give us a glance about the pace of development. As with many other technological advancements, AVs’ precursors (in wide sense) were first developed for warring purposes. The idea to get some equipment to move itself to wanted location that is remote from human opera- tors and execute it’s (usually explosive) mission there has led to many innovations from
"precision guided munitions" like German World War II era Goliath6 and Vengeange 1
& 2 cruise missiles7 to multi-time usable delivery systems like Morfax Wheelbarrow 8 in 1972 and Predator9in 1995, not to forget Mars rovers10from 1970 onwards. Consumer products becan rushing to markets towards the end of 20th century, one example being Roomba11vacuum cleaner in 2002. Technology that we are now used to label "drones"
saw daylight in late 1990s. Falling prices of IMUs and other control electronics made drones available to enlarging groups of researchers and early-adopter hobbyist during mid-to-late first decade of 21th century, but the first successful consumer grade drone was AR.parrot12 that was unveiled in 2010. Nowadays drones and rovers are used for a multitude purposes ranging from leisure flying to photography and from crop spraying to traffic control and tactical support13. Size of drones varies from few grams14to full-sized farm tractors15to ocean-faring ships16. In addition to commercial products directed to con- sumer or professional use, a prominent community of open source software and hardware
6CC BY-SA 3.0, https://en.wikipedia.org/wiki/Goliath_tracked_mine#/media/File\
protect\leavevmode@ifvmode\kern+.2222em\relaxSdkfz302elektr.jpg
7Public Domain, https://media.defense.gov/2009/Sep/28/2000467855/780/780/0/
090928-F-1234S-010.JPG
8Public Domain, https://en.wikipedia.org/wiki/Wheelbarrow_(robot)#/media/File:
Remotely_controlled_bomb_disposal_tool.JPG
9Public Domain, https://fi.wikipedia.org/wiki/General_Atomics_MQ-1_Predator#
/media/Tiedosto:MQ-1_Predator,_armed_with_AGM-114_Hellfire_missiles.jpg
10Public Domain, https://en.wikipedia.org/wiki/Sojourner_(rover)#/media/File:
Sojourner_on_Mars_PIA01122.jpg
11CC BY-SA 3.0,https://commons.wikimedia.org/wiki/File:Roomba_original.jpg
12CC BY 3.0, https://en.wikipedia.org/wiki/Parrot_AR.Drone#/media/File:
Ardrone-img5-front.jpg
13In courtesy to Recon Robotics,https://reconrobotics.com/wp-content/uploads/2019/02/
Throwbot2_Robot_Back_Angle.jpg
14Cheerson CX-10
15Case IH Autonomous Concept Tractor
16MV Yara Birkeland
has seen rise during these years. This yields to availability of advanced technology and advice for free or at least in really affordable prices. As verified in prior project work [8], this makes open source ecosystems an attractive alternative when building case-specific applications and their prototypes.
1.1 Business problem and motivation of research
In this section the frame of the research is prepared by first presenting the practical busi- ness problem and it’s backgrounds, after which the motivation for the following steps of development are briefly discussed.
1.1.1 Background
Javelin, hammer and discus throwing are sports among IAAF17 Official world champi- onship track and field events. Even though all three have their own regulations, throwing equipment and techniques, they also share some basic concepts and boundary condi- tions:
1. athletes cannot perform concurrently (both for security reasons and because length of every throw must be measured separately),
2. throwing distances fall between quite same measures (70−90mat world champion tier competitions) and every piece of throwing equipment must be brought back to throwing point before next athlete’s turn
3. to ensure smooth running of events, there must be 4 to 6 officials serving compe- tition on field.
Historically it has been laborious work to bring equipment back from field, slowing down pace of competition events and committing staff to a quite boring and burdenous job.
Since 2005 our team18 has been developing and using radio-controlled cars (“recovery car”, later in this thesis dubbed as "RecoveryCar") to mitigate these problems and thus pacing up events, lowering down amount of needed field personnel and enhancing secu- rity. One example of this service can be seen in a video from Paavo Nurmi Games 2019 event19.
The pace of track and field sport events is gradually tightening up. This serves needs of both local and broadcast audience, making events more intense and thus interesting.
On the other hand the security and high quality (reliable repeatability) of events is more and more important for event organizers’ brands. These trends together make it desirable
17International Association of Athletics Federations
18A non-profit, unofficial group of technically oriented RC-car hobbyists.
19Video from Paavo Nurmi Games 2019 event: https://www.youtube.com/watch?reload=9&v=A4YhsJCxg7M, shooted and published by RC-car club of city of Turku 2019.
(a)Goliath 1942 (footnote 6) (b)V-1 1944 (footnote 7)
(c)Wheelbarrow 1972 (footnote 8) (d)MQ-1 Predator 1995 (footnote 9)
(e)Sojourner 1997 (footnote 10) (f)Roomba 2002 (footnote 11)
(g)Throwbot 2007 (footnote 13)
(h)AR.Drone 2010 (footnote 12)
Figure 1.1.Figures of different drones and rovers.
to reduce the amount of personnel on the field. Nowadays the operation of recovery car requires two persons at a time: one mechanic and one driver. According to rules the driver must reside outside of sports field for security and TV camera vision reasons, which is a quite demanding requirement as it becomes difficult to estimate exact position and speed of car at greater distances. This tends to lead into collisions and non-optimal driving routes both of which are signs of unprofessional performance. If the RecoveryCar system could be reliably operated from mechanic’s working position (“pits” is normally located next to hammer throwing cage), separate driver would become unneeded. This in turn would make it more profitable and easier to arrange throwing equipment recovery service especially in case of more than one day events.
The initial steps towards RecoveryCar service system that could be operated by a single extra person (instead of at least two of them) were taken in spring 2020 when a Proof- of-Concept (PoC) system consisting of autonomously driving RecoveryCar rover and a mobile web application were developed. The point was that (in principle) competition of- ficials themselves could summon and dismiss the rover as per the state of affairs require.
Because of lack of any object avoidance capability and way too unaccurate GPS20 posi- tioning this PoC stage wasn’t ready for even test use in real environment, but serves as a baseline for furter developement measures.
1.1.2 Next steps of development
To build competition events’ brands in a favorable direction, competition organizers con- sider safety and overall smooth running of events to have a paramount importance. There must not be any significant possibility to inflict harm to humans or equipment on sports fields or at their surroundings. In order to achieve the goal of excluding separate driver from RecoveryCar system it must be made sure that the RecoveryCar won’t cause these kind of problems, were them due to intented or even un-intented way of usage of the sys- tem. As a technical machine the rover alone can fail in a plethora of ways, let alone the system consisting of possibly multiple rovers and a software governing them.
The path to problem-proof and otherwise market-ready system requires multiple devel- opment steps ranging, among the other things, from route planning algorithms and user identification layers to reliable object avoidance and capability of handling multiple rovers at a time [8]. One of the required actions is extensive testing (orverification, see section 2.1) of the system in real or similar to real environment and conditions. Any testing in such conditions have at least one preliminary requirement: rover must be able to avoid collisions. So, to get started on the path of the needed development, the first natural step is to focus on the theme of avoiding collisions with people and equipment on event field.
20Global Positioning System is an American satellite system that is used for positioning, navigation and timing purposes.
1.2.1 Research objectives and questions
The questions of this research are derived directly from the business problem presented above. The hypothesis is that collisions could be prevented by using proper technology.
To test this hypothesis, the following questions are set:
1. What are the minimum requirements of positioning accuracy and object detection in this business case?
2. Is LiDAR technology feasible for the operating environment of the RecoveryCar?
3. Can GNSS21positioning accuracy be enhanced to the required level by using RTK22 technology?
By asking these questions and seeking answers to them, the objective of the research is formed: to assemble a workingprototype23 ("minimum viable product") of a RecoveryCar system that can be reliably operated in conditions mimicking high-profile track and field competitions and that can be used as a basis for next steps along the path of developing a market-ready product. The research objective can be divided into two parts:
1. the RecoveryCar rover must not collide any object relevant to business problem with any significant speed24,
2. the RecoveryCar must be realistically operatable with one person "crew" (the others being working on the event field already and thus marking no extra to total head- count of staff).
1.2.2 Research methods
Following a discussion with thesis supervisor[9] three methods were chosen in pursuit of answering research questions: product development using V-model and prototyping, risk analysis mainly according to ISO-12100 [10] standard and literature study.
A literature review is conducted to gain knowledge about other research methods (namely V-model, prototyping and risk analysis), certain basic technologies needed during de- velopment process and to form a clear picture of procurable equipment (off-the-shelf- validation).
The V-model gives a graphical representation for development life cycle of systems. It is
21Global Navigation Satellite System, eg. GPS, Galileo, Glonass
22Real-time kinematic positioning is a satellite navigation technique used to enhance the accuracy of GNSS positioning
23The concept of prototype is thoroughly reviewed in chapter 2 subsection 2.1.
24Avoiding collisions when the rover is stopped and other object moves to same spot is not pursued in this research.
used to build strong development life cycle and project management models. V-model gives distinct, progressive phases for a system development project and thus it estab- lishes a sound framework to conduct this research. Whereas V-model gives a process framework and names certain activities and outcomes of each phase for system devel- oping projects,prototyping can be seen as a set of techniques to do the concrete job in certain phases of the project. These techniques provide a good toolbox for this research’s purposes and so a large proportion of all actual development work is carried on with them.
Safety is a crucial viewpoint in any technical applications and especially important in de- veloping autonomously moving machines which are intended to share the area of opera- tion with humans. ISO-12100 standard gives a well-founded base for assessing machine- related risks and for systematically finding ways to reduce them to tolerable level.
While the V-model, prototyping, and ISO-12100 are originally unrelated concepts with separate historical backgrounds and sources of motivation, they also have a few similar or somewhat overlapping steps and procedures. Therefore, a coherent model that merges all three methods in a meaningful way is formed in chapter 2. This model is applied in practise in chapter 3.
1.2.3 Thesis structure
This thesis is divided into five chapters, current chapter1 Introduction,2 Background at the page 8,3 Design and implementationfrom the page 26 onwards,4 Resultsthat gather final outcome together and finally 5 Discussion beginning at the page 82. All material that is obtained from other authors or sources (like research methods and information of related technologies) are handled in Background. On the other hand all novel contribution like designs, test plans, iterative prototyping steps and tests are presented in Design and implementation. Final outcomes, evaluation of work and suggestions of further study are given in Conclusions.
2 BACKGROUND
2.1 Systems engineering
According to [11] a system is defined as a "construct or collection of different elements that together produce results not obtainable by the elements alone [...] The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected". This broad definition embraces all kind of systems from household appliances, transportation management systems and the latest weapon systems [12]. System engineering is "a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods"1or "a robust approach to the design, creation, and operation of systems.[...] the approach consists of identification and quantification of system goals, creation of alternative system design concepts, performance of design trades, selection and implementation of the best design, verification that the design is properly built and integrated, and post-implementation assessment of how well the sys- tem meets (or met) the goals"2.
Because of gradually increasing complexity and shrinking time frames, projects of devel- oping new or improving existing technological systems or their modules requires (or at least benefits greatly from) systematic work [13][14]. Project development faces many challenges from over-optimism and intolerable uncertainty at the beginning to problems concerning wrong choices of working methods and high cost of late changes [12]. These and other project-work related problems can be mitigated by following some project frame- work model [15]. A multitude of different kind of project management models3 has been developed during last decades with their respective pros and cons – some being new totally new approaches, others some new mix of other methods and some continuum of old methodologies [13][12].
V-model is one of the best known and most widely supported (or required by authorities) project models from transportation systems [12] to automotive embedded software testing
1https://www.incose.org/systems-engineering, accessed 16-07-2020
2NASA Systems Engineering Handbook, 1995
3One list is given in https://www.projectmanagement-training.net/which-project-management- qualification-is-right-for-me/
Figure 2.1. Systems Engineering "V" diagram according to [12]
[16] and federal level weather system initiatives [17] to name a few.
V-model is quite overloaded term with multiple historical branches evolving different em- phases [14]. At least three separate interpretations can be distinguished, namely the German V-modell, US V-model and less strictly defined software testing model that is mostly known in UK. While the German model is a comprehensive project management system, the US model has a narrower scope, focusing on systems life cycle [18]. The American interpretation [19][12] is used in this research because of the clear and still manageable amount of documentation available related to it.
There exists many graphical depictions of V-model with different amount and content of phases4. The one used by US Department of Transportation (US DoT) is shown in figure 2.1. Common to them all is that like linear waterfall model, V-Model also gives a set of stages and points of decisions that follow each other until the project is ready5. In V-model time goes on from left to right. The left side of the V-model represents requirements and specifications, while the right side gives steps of integration, verification and validation of the system [20]. One of the main ideas of V-model is the symmetry of left and right sides:
every step has its counterpart and every left side phases’ outcomes will be used in it’s related phase on right side - for example the system definition that is produced on left will be used in verifying steps of the right side.
Although according to [12] V-model contains guidance for both technical and project man- agement process, only steps from the former are presented here with emphasis on those steps that are applicable in the scope of this research. As there is no team nor formal
4A willing reader can try Google picture search for "v-model".
5https://airbrake.io/blog/sdlc/v-model, accessed 16.7.2020
of "cherry picking" is a well-founded decision. Thus content of steps depicted below follow but not strictly stick to [12] and related to figure 2.1.
1. Feasibility Study/Concept Exploration- Project’s business case is studied by as- sessing techical and economic feasibility; main risks, costs and benefits are iden- tified. Different possibilities to meet project’s purpose are explored and the best one is chosen. Project goals and objectives are used as sources of information to select a proper fundamental concept for project. Key activities consist of criteria for evaluation and identifying and evaluation of different concepts.
2. System Requirements- stakeholder needs are transformed into requirements that define what (but not how) system will do. System Verification Plan and Require- ments Document are created.
3. System Design - A design for the system is made according to system require- ments. A high-level design defines the framework within which the subsystems can be identified. These subsystems are further divided into components. Components are given requirements and specification of interfaces are made in detail. Test and verification plans are devised for the hardware and software components that need to be developed. Final decisions for off-the-shelf components are made.
4. Software/Hardware Development and Testing- Actual solutions are created as defined in the system design. Some solutions possibly need custom development, and some of them may be off-the-shelf items, possibly modified to meet the spec- ifications. The components are tested and delivered ready. Key activities include procuring off-the-shelf products, planning and executing development and perform unit and device testing. Clear definition of requirements and high level system de- sign helps developing proper hardware assemblies and configure software.
5. Integration and Verification- Components are verified and integrated to assem- blies or subsystems. Assemblies are verified and then integrated with others to larger assemblies. Finally the complete system has been integrated and verified.
6. System Validation- When the system is verified and installed the system owner/- operator conducts own set of tests to ensure that the system meets the identified needs. Unlike most of the system verification steps, validation can’t be done before the system is used by real users in its real operational environment.
While V-model has a proven scalability and successful outcomes in many kinds of projects, it has also been criticized. As stated in [18], while V-model make it possible - or at least make it feel possible - to manage, plan and control projects, this is not necessary in favor of true goal of the project: it may take "mind-numbing amounts of documentation in order to obtain approval to move on to the next stage, and the funding that goes with it." It is possible that project staff pays attention to other things than the real substance of the
project. Especially on larger projects it is difficult or even impossible to define require- ments or subsequent designs right in "first try" which can lead to systems with unneeded or unwanted features instead of the ones that users or business case really needs6. According to [21] a prototype is "an artifact that approximates a feature of a product, ser- vice or system". In turn [19] puts prototype "as the first thing of its kind; an original" and [22] gives definition "A prototype is a distinct product (hardware or software) that allows hands-on testing in a realistic environment. In scope and scale, it represents a concept, subsystem, or production article with potential utility. It is built to improve the quality of de- cisions, not merely to demonstrate satisfaction of contract specifications. It is fabricated in the expectation of change, and is oriented towards providing information affecting risk management decisions." [23] goes on by defining prototyping as design and development activities that aims to reduce technical uncertainty and to generate information to improve the quality of subsequent decision making: Prototyping activities include the design and fabrication of one or more representative systems (hardware or software) for limited test- ing and demonstration prior to a production decision. The prototype itself is the article being tested.
Prototyping activities have many potential objectives and respective techniques. Based on a thorough literature review, authors of [24] compile a table of relations of these objec- tives and techniques (table 2.1) and provides a framework that helps planning prototyping measures in a structured manner (figure 2.2). The objectives and techniques which are seen relevant to this research are presented in detail below.
Objectives of prototyping Table 2.1 presents six different objectives ("why’s") for de- sign prototyping. Three of them were considered interesting from the perspective of this research:
refinement means gradual improvement of design. Prototyping can be used to vali- date requirements, reveal critical design concerns [25], reduce errors [26], to identify performance-enhancing desing changes [27], design feature optimization via the sequen- tial testing and manipulation of parameters [28] and design refinement through simulated use [21]. Refining the system-level characteristics of a return car can be considered as the main goal of this study, and at the same time it is possible to identify several refine- ment needs for subsystems or components.
Exploration is the process of seeking out new design concepts [24]. According to [24]
prototyping can be associated with two high-level processes, namely divergence ie. find- ing new concepts from gathered information and converge ie. ruling out excess concepts from subsequent phases. It can be seen a somewhat ambivalent question that is this re- search going to produce new concepts or refinement already existing designs, but some divergent traits can probably be identified during the process, giving valuable ideas for
6https://airbrake.io/blog/sdlc/v-model
techniques are indicated with a solid circle (according to [24])
further research. This favors the view that exploration is one of prototyping objectives, even if it comes to fruition only by occasion.
Prototyping can be a tool ofactive learning, which is the process of gaining new knowl- edge about the handled theme [24]. Hands-on activity reveals tacit information [29] and designers can get a good sense of progress [because of rapid nature of prototyping] that gives an important psychological encouraging effect on them [30]. From the point of view of this research active learning has a profound importance because of the lack of rigor documentation of open source platforms used.
Techniques of prototypingDesigner must pursue the objectives he/she has set for pro- totyping with appropriate techniques. Authors of [24] identifies a space of prototyping techniques that can be separated in two sections that are depicted in figure 2.2. The first section contains iterative and parallel prototyping, which refers to question, how proto- typing phases are arranged and organized in relation to each other. The second section takes a position on how the prototyping activities are implemented within these steps with cost and time usage reduction in mind. Four techniques are presented: requirements, system,scaleandmediarelated ones.
Prototyping is not a well-defined, exclusive concept itself. In this sense it is not meaningful to assess reliability, scalability and generalizability of prototyping per se - one should first
Figure 2.2. A map of the prototyping strategy space. Where IiCn is the ith iteration of thenth concept. Each block represents a single prototype or build. Grey area depicts that each build has several factors of construction. The number of iterations of each concept may vary. This process can be applied at the system, subsystem and component level.
(According to [24])
clearly define certain techniques and only then have a closer look to these questions.
Still some problems related to prototyping can be brought to spotlight, giving at least a vague touch to this kind of assessment. For example, authors of [31] pinpoint the fact that prototypes can’t ever be fully evaluated in studies as they are situated in present world and circumstances, not in real context of use. The state of affairs cannot be emulated exactly, which leaves a risk of misjudgements. [23] promotes the same issue stating that relaxation of (prototype) requirements must be implemented carefully to ensure that proper insights can be collected.
2.2 Risk assessment
The business case of this thesis, recovering throwing equipment in high profile athletics competition events, sets high demands of safe and overall smooth operation of all techni- cal systems. The RecoveryCar is a moving machine that is used in the same space with humans and other property, thus having a potential ability to inflict damage to both. This makes it self-evident to pay close attention to identifying and reducing risks associated with this system.
In order to pursue safety and safe operability of a machine one must define what these words mean. According to [32] safety is a "state in which the system is not in danger or at
guide to inclusion of safety aspects to standards [33] says the term "safe" is often under- stood by the general public as the state of being protected from all hazards, which is a misunderstanding. "Safe" is rather the state ofbeing protected from recognized hazards that are likely to cause harm. Some level of risk is inherent in products or systems. Thus safety is "freedom fromrisk which is not tolerable". This intrinsic nature of risk of hazards in machinery is recognized in European Union’s Machinery Directive [34], which requires a CE certification for a machine that is to be commercialized. When implementing func- tional safety systems that comply with Machine Directive’s requirements one can follow either of two alternative standards bodies: The International Organization for Standard- ization (ISO) standard or the International Electrotechnical Commission (IEC) standard.
ISO standard structure for machinery has three levels [10, see chapter Introduction].
Type-A standards are basic safety standards which gives basic concepts and principles of design for machinery. Type-B standards are generic safety standards dealing with certain safety aspect or safeguard that can be used across a wide range of machinery. Type- C standards are machine safety standards that give direct requirements for a particular machine or group of machines. According to sources [35], [36] there is neither relevant type-C standard nor other clear and widely accepted regulation or standards dedicated for Drones. This has proved to be a problem for fully utilizing capabilities of drones es- pecially in civilian applications [35]. Different research groups have been developing their own risk assessment and mitigation frameworks to encounter the lack of official guidance.
For example [35] proposes both qualitative (based on ISO-12100 and ISO-13849) and quantitative (based on Bayesian Networks) approaches to identify, estimate and reduce risks of operating airborne delivery drones controlled off-site over internet. An alternative method of estimating risk is presented [37] that handles a case of usage of unmanned ground vehicle in construction site environment: potential casualties is estimated through a Monte Carlo simulation of probability of fatality or injury in case of impact between drone and human, density of humans in construction site, drone covered area and failure rate of the system. While qualitative assessment is a quite well defined process, it’s problem lies in it’s susceptibility to the personal opinions and perceptions of risks of evaluators. On the other hand quantitative approach requires vast amounts of reliable numerical data. In [35] data of drone-related accidents is collected from various statistical sources and still researchers are obliged to view only frequencies instead of actual probabilites of differ- ent root causes. The same goes with Monte Carlo simulation: outcomes (casualties per million work-hours) are strongly dependent on the input values that are fed to model. In addition this model doesn’t take any stance on the cause of casualty, only it’s frequency.
Because of lack of reliable statistical data of different kind of problematic occasions in throwing equipment service it is impossible to apply other than qualitative approach in risk analysis of this thesis’ business case. This combined with the fact that no appli-
cable type-C standard exists [38] makes type-A standard ISO-12100 a fallback solution that provides for terminology and tools to assess and mitigate case-related risks and to eventually achieve the state of safety defined in afore-mentioned guide [33]. [35] takes a profound tour on applying ISO-12100 and safety-functions related ISO-13849 [39] in drone operating risk assessment process, giving a sound example for this thesis’ risk analysis method.
[10] defines needed terms as follows:
• harm: physical injury or damage to health,
• hazard: potential source of harm,
• risk: combination of the probability of occurrence of harm and the severity of that harm,
• residual risk: risk remaining after protective measures have been implemented,
• risk estimation: defining likely severity of harm and probability of its occurrence,
• risk analysis: combination of the specification of the limits of the machine, hazard identification and risk estimation,
• risk evaluation: judgment, on the basis of risk analysis, of whether the risk reduction objectives have been achieved,
• risk assessment: overall process comprising a risk analysis and a risk evaluation,
• protective measure: measure intended to achieve risk reduction,
• inherently safe design measure: protective measure which either eliminates haz- ards or reduces the risks associated with hazards by changing the design or oper- ating characteristics of the machine without the use of guards or protective devices,
• safeguarding: protective measure using safeguards to protect persons from the hazards which cannot reasonably be eliminated or risks which cannot be sufficiently reduced by inherently safe design measures,
• information for use: protective measure consisting of communication links (for ex- ample, text, words, signs, signals, symbols, diagrams) used separately or in com- bination, to convey information to the user.
The two ISO standards’ (simplified) functional safety methodology is presented in 2.3.
ISO-12100 gives five-stage iterative process which starts from determining the limits and thus the intented use and foreseeable misuse of the machine. This makes it possible to identify hazards and associated hazarduous situations and estimate the risk related to each hazard. After risk estimation they have to be evaluated and if found un-acceptable, reducted by means of protective measures. As depicted in 2.3 the process should be continued with identifying needed safety functions and determining their required per- formance level (from a to e) using a risk graph. The latter two stages are covered by
System limits specification Hazard identification
Risk estimation
Risk evaluation
Is risk
Risk reduction measures
Safety functions identification
Performance level determination
non-tolerable tolerable
Inherently safe design Safeguarding and protective measures Information for use
ISO 12100ISO 13849 Risk analysis Risk assessment
End
Figure 2.3. The simplified functional safety methodology based on ISO 12100 and ISO 13849
ISO-13849.
According to [32] the drone limits (in ISO-12100 sense) can be divided into five categories, namelyphysical,temporal,environmental,behavioral andnetworking limits. [35] in turn suggests classifying hazard sources intoexternal andinternal and finds several hazards types from both classes, after which authors decide to follow four severity levels of these hazards (catastrophic, critical, marginal and negligible). After combining this classifica- tion of severity of identified hazards with their respective probabilities (frequent,probable, occasional,remoteandimprobable) a final risk assessment scoring matrix (seen in table 2.2) can be used to estimate each risk. Following the matrix, risks are evaluated and mit- igated with safe design, safeguarding and information as described in ISO-12100. These steps and classifications are utilized, where applicable, in the implementation chapter 3 of this thesis. In contrast, ISO-13849 related identification and estimation of required per- formance level of safety functions will not be taken under consideration as their real-world implementations would fall outside of scope of this research.
ISO-12100 and ISO-13849 are global standards that are followed in designing and build-
Table 2.2.ISO-12100 risk assessment scoring matrix (according to [40]).
Likelihood of occurence Severity of injury or illness consequence Negligible Marginal Critical Catastrophic
Frequent Medium Serious High High
Probable Medium Serious High High
Occasional Low Medium Serious High
Remote Low Medium Medium Serious
Improbable Low Medium Medium Medium
ing very versatile scales of machines (and businesses around them). This is a good proof of scalability and generalizability of these standards as a methods of implementing safety systems in compliance with European Machine Directive. On the other hand following standards to the point may be a heavy burden to bear with microscale developement projects like the one examined in this research. Thus, as long as no actual products are brought to market, it seems reasonable to adapt the risk analysis method described above to needs of this research so that main emphasis of process lies in identifying the most significant hazards, estimating their risks and finding out ways of reducing those risks with application of proper technology.
As stated in [35] this kind of qualitative risk analysis is prone to human misjudgements especially when assessing risk severity. Results may not necessarily be repeatable or predictable because of non-transparent nature of qualitative assessment. According to author of [41] "existing methods may be useful on general terms, but very inflexible for detailed risk assessment."
2.3 Matching methods
V-Model7, prototyping and ISO-12100 obeying risk analysis are separate concepts that have some overlapping features. V-model and ISO-12100 both give (among other things) a process to follow but they are not straight away compatible with each other. On the other hand V-model contains a set of phases and related project gates that in strict view shouldn’t be crossed before everything is ready in current phase and respectively project should never re-visit previous phases once they are left befind. This is at least somewhat contradictory to iterative and learning nature of prototyping techniques and objectives.
V-model was taken as the main framework that defines the order (and contents) of mea- sures that relate to product development in this research. Some phases were merged to- gether: initial feasibility study and concept of operations forms an integral phase in which business case and main objectives are set and initial steps of risk management are taken.
7Referring to the American version which was described in subsection 2.1
Figure 2.4. Matched V-model and ISO-12100 risk analysis methods and prototyping techniques. Certain V-model phases are merged to form a total of six separate phases.
Dashed borderlines separate original V-model phases to make figure comparable with figure 2.1. V-model’s horizontal connecting lines between left and right side are not dis- played to make figure clearer and more readable. Operations and maintenance phase is not executed in this research.
High and detailed design phases were merged to system design phase and subsystem verification and system verification & deployment phases formed a single integration/ver- ification phase. Phases from ISO-12100 sequence model (see figure 2.3) were matched to this framework: system limits specification takes place in initial part of feasibility study phase and hazard identification, risk estimation and evaluation in latter part of it. Actual ISO-12100 risk reduction measures are executed in V-model’s development and testing phase. In practise, prototyping techniques and mindset are utilized to actually make things happen: in system requirements phase for active learning and in development and testing phase to gradually refine the design in iterative steps - eventually integrating subsystems to the final system which is verified against the requirements. Every step will have it’s own execution plan ("prototyping strategy" in figure 2.2) Consequently it is difficult to exactly distinguish all V-model phases from each other: system design, development and testing and yet integration/verification phases changes smoothly. This is not a problem because of compact nature of this research: there is no need for strict project management, project gates and related pay posts or any kind of communication between different stakehold- ers. Figure 2.4 depicts the fusion of methods, portraying ISO-12100 related phases and prototyping objectives on top of V-model. V-model related outcomes of each phase are listed under respective phase header.
2.4 Emerging Technologies for unmanned vehicles
2.4.1 Open source autopilot software: ArduPilot (ArduRover)
ArduPilot is an open source autopilot software that can control both airborne and ground vehicles like multicopters, helicopters, fixed-wing airplanes, boats, submarines and rovers.
It is one of the best-known autopilot suites and is applied by many OEM UAV companies, such as 3DR and jDrones. Also several large institutions and corporations such as NASA, Intel and Insitu/Boeing use it as well as numerous colleges and universities around the world [42]. The ArduPilot code base is quite large (about 700k lines for the core ardupi- lot git tree) but the Dev team has documented the procedures and libraries well. The documentation is available on the ArduPilot website [43] .
According to ArduPilot developers documentation [44] the basic structure of ArduPilot is broken up into 5 main parts: vehicle code, shared libraries, hardware abstraction layer (AP_HAL), tools directories and external support code (i.e. mavlink, dronekit) like in fig- ure 2.5. The vehicle directories are the top level directories that define the firmware for each vehicle type. Currently there are 5 vehicle types: Plane, Copter, Rover, Sub and AntennaTracker. The libraries are shared amongst the four vehicle types Copter, Plane, Rover and AntennaTracker. These libraries include sensor drivers, attitude and position estimation (aka EKF) and control code (i.e. PID controllers). The AP_HAL layer (Hard- ware Abstraction Layer) is how ArduPilot is made portable to lots of different platforms.
There is a top level AP_HAL in libraries/AP_HAL that defines the interface that the rest of the code has to specific board features, then there is a AP_HAL_XXX subdirectory for each board type (like Pixhawk FCU). The tools directories are miscellaneous support directories like tools/autotest which provides the autotest infrastructure.
At high architectural level, the code base runs two type of loops: a single main loop that runs all the ’core’ libraries and methods and background threads for each sensor to execute ’sensor’ libraries and methods, see figure 2.6. For ArduRover the main loop is run at50Hzfrequency. During single main loop, setters methods are called to set flags which are used in action methods that are executed during the next loop cycles. Background threads call sensor methods regularly to get data from sensors and set corresponding variables like distance information handled by AP_RangeFinder library.
Figure 2.5. The basic structure of ArduRover’s architecture, according to https: //
ardupilot. org/ dev/ docs/ learning-ardupilot-introduction. html.
Figure 2.6. ArduRover high level architecture according tohttps: // ardupilot. org/
dev/ docs/ rover-adding-a-new-drive-mode. html.
2.4.2 Communication between vehicle and ground control system:
Micro Air Vehicle Link 2
According to [1] the Micro Air Vehicle Link (MAVLink 2) is a communication protocol for unmanned systems. It gives a set of messages transmitted between unmanned systems and ground stations. MAVLink is used in major autopilot systems, like ArduPilot, and provides powerful features for monitoring and controlling unmanned systems missions and integrating them into the Internet. MAVLink is a well-established lightweight mes- sage serialization protocol and it is specified to ensure the communication between the unmanned systems and the ground stations. Lorenz Meier released MAVLink in 2009 under the LGPL license. The advantage of the MAVLink protocol is that it supports dif- ferent types of transport layers and mediums thanks to its lightweight structure. It can be transmitted via WiFi, Ethernet (i.e., TCP/IP Networks) or serial telemetry low band- width channels operating at sub-GHz frequencies. Figure 2.7 shows MAVLink 2.0 header content. Table IV in [1] gives an example list of commands that can be delivered with
Figure 2.7.MAVLink 2.0 header according to [1]
MAVLink messages from ground control station to flight controller. [45] gives example of using MAVLink protocol as a part of limitless range drone controlling network service.
2.4.3 Open source autopilot hardware: Pixhawk flight control unit
Pixhawk is the hardware standard for open-source autopilots that was started as a student project in 2009 at ETH Zurich [46]. Development work is governed by Dronecode Founda- tion [47]. Pixhawk is an independent project providing autopilot hardware designs to hob- byist, academic and industrial applications. Different manufacturers have produced their own open design based boards with optimizations for different use cases[48]. The project creates open hardware schematics that define a set of components (CPU, sensors, etc.), connections and pin mappings. Multiple open designs/schematics are designed using the naming convention:FMUvX8 (e.g.: FMUv1, FMUv2, FMUv3, FMUv4, etc.). The Pixhawk 1 board (which was used in this research) was released in 2013 [49], comprising of 32-bit STM32F427 Cortex® M4 core with FPU9 microprocessor (168 MHz/256 KB RAM/2 MB Flash), 32 bit STM32F100 failsafe co-processor (24 MHz/8 KB RAM/64 KB Flash) and ST Micro L3GD20 3-axis 16-bit gyroscope, ST Micro LSM303D 3-axis 14-bit accelerom- eter / magnetometer, Invensense MPU 6000 3-axis accelerometer/gyroscope and MEAS
8FMU refers to Flight Management Unit, which is a synonym to Flight Control Unit (FCU)
9Floating Point Unit, a co-processor specialized into floating point numbers
(PWM13 or voltage) input, I2C14, SPI15 and external microUSB ports. Pixhawk can be equipped with GNSS sensor to provide location data, such as latitude, longitude, altitude and speed, as well as many other peripheral sensors like rangefinders, compasses and telemetry radios.
2.4.4 Internet connection via companion computer
For computationally intensive tasks (for example computer vision, SLAM or internet con- nection) a separate companion computer is needed along with real-time flight controller like Pixhawk. According to ArduPilot documentary [50] the two are connected with se- rial connection and exchange data using MAVLink protocol. By doing this a companion computer gets the MAVLink data that the autopilot produces, including GPS data, which can be used to make more complicated decisions during mission. For example, “take a photo when the vehicle is at certain GPS co-ordinates”, gather and pre-process infor- mation from advanced sensors or actuate lights, auxiliary servos or any other interfaces.
Respectively a companion computer can send MAVLink messages to flight controller and thus for example give it new mission items, velocity targets or change it’s flight mode.
There is no strict definition of companion computers and practically any computer that can receive, handle, route and send back MAVLink messages from/to flight controller could be used as such. In practise size matters in rover and drone applications which give rise to so called card computers like Raspberry Pi or NVidia TX series. ArduPilot homepage [50] and many articles (for example [51], [52] and [53]) promotes usage of Linux-based software to operate companion computers. From this research’s viewpoint the most inter- esting piece of software is MAVProxy that according to [54] is a fully-functioning, minimal- ist, portable and extendable ground control software for autonomous systems supporting MAVLink protocol. For this research, among many features, the key feature of MAVProxy is the ability to forward the messages from flight controller over the network via UDP16to multiple other ground station software on other devices.
10(Universal Asynchronous Receiver Transmitter, a serial communication chip
11Controller Area Network is a vehicle bus that is used to allow communication between devices
12Received Signal Strength Indicator measures the power of received radio signal
13Pulse Width Modulation
14Inter-Integrated Circuit is synchronous, packet switched serial bus
15Serial Peripheral Interface is a synchronous serial communication interface specification
16User Datagram Protocol, a connectionless protocol for computer applications to send messages to other hosts on an Internet Protocol (IP) network