Dissertation Final Report Santhosh

Eindhoven University of Technology
MASTER
Investigation of model based adaptive cyber physical system for autonomous trucks
Santhosh
Award date:
2019
Link to publication
Disclaimer
This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student
theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document
as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required
minimum study period may vary in duration.
General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners
and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
• Users may download and print one copy of any publication from the public portal for the purpose of private study or research.
• You may not further distribute the material or use it for any profit-making activity or commercial gain
Department of Mathematics and Computer Science
Model Driven Software Engineering Research Group
Investigation of Model Based Adaptive

Cyber Physical System for Autonomous
Trucks
Master Thesis
Dissertation for the completion of
Master’s Degree in Embedded Systems
Graduation Supervisor/ Tutor:

dr.ir.Ion Barosan
Student Name:
Santhosh.S
Assessment Committee Members

dr.ir.Ion Barosan
dr.ir.Dip Goswami
dr.ir.Richard Verhoeven
Abstract
Autonomous driving is the technology of the future. Though autonomous/self driving vehicle tech-
nology is emerging, their deployment in a large scale is absent. This could be attributed to social,
political will towards self driving cars, the infrastructure needed and safety concerns. This report is
primarily concerned with the dissertation for graduation thesis where the proposed topic is explored
as a solution towards an actual implementation of an autonomous truck driving in a distribution
centre. From a research standpoint, this report aims at an investigation of a model based cyber
physical system for autonomous trucks.
A model based cyber physical system for autonomous trucks in a distribution centre is aimed to
be developed to achieve its driving functionality. Model Based Software Development is taken up for
its advantages over the traditional method of software development. The goal is to develop a cyber
physical system, in the form of a control software. The software should be able to provide driving
commands to a truck-semitrailer in the distribution centre and achieve its motion. The development
of software has been done resembling the steps from a reference book eliciting the requirements of
a formal model based software design and the specific method used is Round Trip Engineering.
A cyber physical system in the case of driving could have uncertain environmental conditions.
Thus, there arises a requirement of adapting its behaviour at run-time. The programming frame-
work called OSGI is used as it is suited for the preceding definition of cyber physical system. OSGI
is a component based software framework based on Java and it needs a special container to be de-
ployed. Thus the importance of OSGI programming in cyber physical system and its applicability
in solving a real world problem is examined. A run-time environment to test the functioning of the
software was aimed to be the scaled model truck trailer and a distribution center which is present
in the campus of TU/e. Its digital twin is available in Unity simulator and hence it is taken up as
the primary run-time environment.
Implementation is planned by enumerating a set of requirements needed to achieve the driving

functionality. Some of the important constituents of such an implementation are a path planner
which finds the path between two given points. A novel motion planning framework that is proposed
as a part of this thesis for the purpose of truck driving based on the results of the path-planner
as a source of guidance. For discrete points from the results of the path planner, an orientation
finder determines the orientation of the vehicle and the motion planner finds the angle between the
points using trigonometric angle finding by forming a right triangle between the given source and
destination points and uses its results to set the appropriate steering angle. This motion planner
is also suited for driving using the kinematically feasible motion primitives for a subset of cases in
the reverse direction. Thus the authenticity of this motion planning framework could be argued to
be experimentally verified. A comparison between this motion planning framework and a reference
Proportional Integrative derivative Controller based driving of the truck has also been presented.
Investigation of Model Based Adaptive Cyber Physical System for iii

Autonomous Trucks
The Preamble
I am sincerely thankful to my supervisor dr.ir.Ion Barosan for deciding to supervise this Master’s
graduation thesis. I am also thankful to his project inputs, guidance, patience, cooperation, motiva-
tion during the various stages of this thesis. I thank dr.ir.Dip Goswami and dr.ir.Richard Verhoeven
for kindly deciding to be members of assessment committee. I also thank dr.ir.Igo Besselink for his
consulting hours. I am sincerely thankful to the almighty, my parents, relatives, near and dear
ones for their continuous support.
I thank Oskar Ljungqvist of Linköping University, Sweden for his vital inputs and help in solving
the motion primitives using ACADO Toolkit. I also thank Marcello Cirillo, Head of Motion Planning
and Control, Scania CV AB and Nishanth Nair of TU/e, for providing an explanation about using
motion primitives and discretization of the lattice space respectively.
This thesis is carried out in accordance with the TU/e Scientific Code of Conduct and the
vital energy is supplied by will power along with the guidance/ support by the institution. I am
thankful to TU/e for providing me an opportunity to pursue my Master of Science in this august
institution. I cherish the memories of scientists, professors and teaching staffs who inspired me by
their concept clarity and hard work.
Investigation of Model Based Adaptive Cyber Physical System for v

Autonomous Trucks
Contents
Contents vii
List of Figures ix
List of Tables xii
1 Introduction 1
1.0.1 Model Based Cyber Physical System . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.0.2 Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.0.3 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Preliminaries 9
2.1 Problem Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Project Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Model Based Software Development . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Open Source Gateway Initiative (OSGI) . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Kinematic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4 Motion Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.5 UNITY Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.6 ArUco Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 System Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Platform Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Design and Implementation 20

3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Implementation Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Path planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Design of Actuation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.1 Determination of Orientation of the Vehicle . . . . . . . . . . . . . . . . . . . . . 25
3.4.2 Motion Planning Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.3 Design of Communication Module . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.4 Other Implementation Specifics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Experimental Analysis 33
4.1 Vehicle Movement through Way-points- a Discussion . . . . . . . . . . . . . . . . . . . . 33
4.2 Comparison of the proposed Motion Planning Framework with that of a PID controller 37
4.2.1 Trajectory Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2 Throttle/Velocity Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.3 Steering Angle Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 Experiments with Motion Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.1 Maximum Velocity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.2 Example Velocity used in our driving . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.3 Usage of Motion Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Performance Comparison based on Target Platform . . . . . . . . . . . . . . . . . . . . 43
Investigation of Model Based Adaptive Cyber Physical System for vii

Autonomous Trucks
5 To Conclude 45
5.0.1 Research Questions and their Answers . . . . . . . . . . . . . . . . . . . . . . . 45
5.0.2 Deviations from the Original Proposal and their Reasons . . . . . . . . . . . . . 47
5.0.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.0.4 Limitations and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.0.5 Scientific Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Bibliography 51
Appendix 53
A Lattice Time Bounded Astar 53
B Keywords 54
viii Investigation of Model Based Adaptive Cyber Physical System for

Autonomous Trucks
List of Figures
1.1 Netherlands Road-map in the Automotive Industry [25] . . . . . . . . . . . . . . . . . 2

1.2 Evolution of Vehcile Automation from [19] . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Functional Architecture of a Vehicle Centric Architecture from [18] . . . . . . . . . . 3
1.4 Levels of Vehicle Automation from [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Cyber Physical System from [32] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Truck Semitrailer example from [22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Jumbo Distribution Centre in Veghel from [1] . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Model of Distribution Centre in Automotive Engineering Sciences Lab of TU/e . . . . 10
2.4 Modelling Spectrum from [20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Formal Model Based Development Steps from [13] . . . . . . . . . . . . . . . . . . . . . 12
2.6 Layered Model OSGI Architecture from [37] . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7 Kinematic Model of a Singly Articulated Truck and Semitrailer from [18] . . . . . . . 14
2.8 UNITY Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.9 ArUco markers from the simulations setup . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.10 Architecture of the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1 OSGI services implementing the driving fuctionality . . . . . . . . . . . . . . . . . . . 21

3.2 Dimensions of the provided Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Dimensions chosen for implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Possible orientations of the Vehicle (Diagram Not to Scale) . . . . . . . . . . . . . . . . 24
3.5 Orientation Angle Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6 East West/West East Orientation Steering Error . . . . . . . . . . . . . . . . . . . . . . 26
3.7 North South/South North Orientation Steering Error . . . . . . . . . . . . . . . . . . . 26
3.8 East West Orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.9 West East Orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.10 North South Orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.11 South North Orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.12 Flowchart for Motion Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1 Initial State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Waypoint-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Waypoint-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Waypoint-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5 Docking State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.6 Docking State (in Focus) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.7 Trajectory of ArUco markers during simulation from [8] (Dimension scale as in Figure
3.2 all units in metres) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.8 Trajectory of Front Aruco marker using our software (Dimensions as in Figure 3.3 . . 38
4.9 Truck Linear Velocity during our simulation until waypoint1 . . . . . . . . . . . . . . . 39
4.10 Truck Linear Velocity from [8] using PID controller (X-axis-Time in Seconds and Y-
axis-Linear Velocity in km/h) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.11 Steering angle during our simulation until waypoint1 . . . . . . . . . . . . . . . . . . . 40
Investigation of Model Based Adaptive Cyber Physical System for ix

Autonomous Trucks
4.12 Steering angle from [8] using PID controller (X-axis-Time in Seconds and Y-axis-
Steering angle in degrees) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.13 Plot of the rear point of trailer (left) and heading angle of trailer (right) with time . . 41
4.14 Plot of gamma (left) and delta (right) with time . . . . . . . . . . . . . . . . . . . . . . . 41
4.15 Plot of the rear point of trailer (left) and heading angle of trailer (right) with time . . 42
4.16 Plot of gamma (left) and delta (right) with time . . . . . . . . . . . . . . . . . . . . . . . 42
A.1 Lattice Time Bounded Astar from [23] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
x Investigation of Model Based Adaptive Cyber Physical System for

Autonomous Trucks
List of Algorithms
1 seudocode for Astar Algorithm23 2

P Routine for Steering Error Calculation26 3
Routine for Forward
Motion Planning Framework29 4 Routine for Reverse Motion Planning Framework for Docking Choices
1 and 2 (using Motion Primitives)30 5Routine for Reverse Motion Planning Framework for Docking
Choices 3 to 10 (using Astar Algorithm)31
Investigation of Model Based Adaptive Cyber Physical System for xi

Autonomous Trucks
List of Tables
5.1 Original Proposal and its Deviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.1 List of Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
xii Investigation of Model Based Adaptive Cyber Physical System for

Autonomous Trucks
Chapter 1
Introduction
Autonomous driving in trucks is an exciting area of technological advancement that could be envi-
sioned. Companies like Amazon, Daimler and many others [27][30][33] have started testing their
autonomous truck technologies. They are majorly focused on driving on highways. The work taken-
up in this research is concerned with the development of an autonomous driving scheme in a distri-
bution/logistics centre for both forward mode driving and reverse mode docking. In the forthcoming
pats of the introduction, the significance of this research is highlighted, followed by the evolution
and types of automation trends in vehicle, followed by the state of the art in the context of autonom-
ous driving is presented.
The Significance of Logistics to the Economy of Netherlands is around 10 percent of its GDP
and thus Logistics is one of the most important focus sector of Netherlands [26]. The Autonomous
Vehicles Readiness index of 2019 ranks Netherlands as the global leader in terms of preparedness
to deploy autonomous vehicles [3]. This suggests that the scope for autonomous vehicles to be de-
ployed practically is ample.
The Netherlands has the highest number of distribution centers in Europe [26]. INTRALOG
project (Intelligent Truck Application in Logistics) has been started for identifying the potential of
automated driving within the logistics domain [16]. INTRALOG is a consortium of companies and
universities, in which our TU/e is a member[16]. One of the major focus of INTRALOG is dock-
ing semitrailers at distribution centers [16]. The INTRALOG project aims at exploring the added
planet, people and Profit value that automated guided trucks can bring to smart logistics operations
at distribution centers [12].
According to the news item in [38], there is reported shortage of truck drivers in the Netherlands
and other parts of Europe. This presents an opportunity for deploying autonomous trucks in the
Logistics sector without concerning the lack of jobs that adoption of autonomous driving is argued
to bring about. The movement of trucks if done by human drivers could be time dependent due to
their non-availability past work hours [9]. Thus autonomous trucks has the potential to improve
the efficiency of a distribution centre and making its operation less depended on human drivers.
A dock assist system has been developed by Eaton as discussed in [34]. With the supervision
of a human driver, assistance is provided only for the case of docking. It is reported that the dock
assist system made far more corrections and was slower compared to a human driver. Also the
most important limitation is that the driver needs to initially park the semitrailer parallel to the
docking station. According to [36], the most difficult professional skill is the docking of a truck.
Thus automated docking could be a significant step towards easing the manual effort required to
make the docking.
Investigation of Model Based Adaptive Cyber Physical System for 1

Autonomous Trucks
The automotive road map from AutomotiveNL is shown in Figure 1.1. This suggests that, at
present technologies like automated parking is one of the major focus areas. The road map shows
the significant improvement that can be made in the future eras of vehicle automation achieving a
fully automated approach in the highway and eventually in the city.
Figure 1.1: Netherlands Road-map in the Automotive Industry [25]
Figure 1.2: Evolution of Vehcile Automation from [19]
2 Investigation of Model Based Adaptive Cyber Physical System for

Autonomous Trucks
In the perspective of evolution of vehicle automation, Figure 1.2, presents three types of auto-
mation as driver centric, network centric and vehicle centric. Automated parking/park assist is a
driver centric approach [19]. In the case of autonomous trucks, Dock Assist from [34] discussed
previously still requires a human driver to be in the drivers seat. Thus this approach belongs to a
driver centric approach. Also approaches like vehicle teleoperation, where there is no human driver
on board but operates from a remote location also belongs to this category. Starsky Robotics has
developed an autonomous truck capable of driving by a human in a remote teleoperation centre [15].
Network centric approaches stands between the vehicle and driver centric approaches. Teleop-
eration [19] can also be called network centric as it requires remote communication between the
vehicle and the human driver. This is an example of vehicle to infrastructure approach, whereas
concepts like platooning are example of a vehicle to vehicle approaches.
The approach of autonomous driving taken up in this research is a vehicle centric approach
and hence we do not need a human driver in the truck. A vehicle centric architecture model of a
control system is provided in Figure 1.3. This approach is provided for on road driving.In the case of
distribution centre, the perception system will be different. But other constituents like supervisory
control, vehicle state feedback, path and mission planner re common.
Figure 1.3: Functional Architecture of a Vehicle Centric Architecture from [18]
Autonomous movement of vehicles depends on the context in which it operates, for instance driv-
ing on road require factors like speed maintenance, lane following, avoiding risks to human life etc.
Distribution centres on the other hand require movement of vehicles once they are parked in the
parking stations to the docking station, where the goods brought by the truck are unloaded from its
semitrailer.

Autonomous Trucks
Figure 1.4: Levels of Vehicle Automation from [2]
In vehicle automation, the state of the art is currently at the level of automation that can be
achieved. Figure 1.1 from [2] shows the different levels of automation. Level 3 refers to conditional
automation and the implementation done as a part of this research will belong to this category.
From the perspective of on road driving, Daimler has been able to test drive a Level 4 autonomous
truck on pubic road according to [32].
Though this table holds good for on road driving, this research also attempts driving but for a
fixed distance and within the fixed boundaries of the given distribution centre. The distance and
the requirement of the combination of forward and backward driving mode required depends on the
dimensions and the placement of static obstacles in the distribution centre. Trucks in distribution
centres need to be moved from parking to docking stations. The most important step in such a case
is the docking of semitrailers in one of the docking stations which requires the movement of the
truck and trailer in the reverse which is a difficult task as already discussed. Thus the context of
levels of automation in the case of on road and in the distribution centre can hold different set of
requirements.

Autonomous Trucks
1.0.1 Model Based Cyber Physical System
In this subsection, the introduction to the proposed topic is provided. The aim of this research is to
develop a model based cyber physical system. A model in a mathematical sense is a set of entities
that satisfy all formulae of a given system [20]. A model means a written artifact. As human be-
ings form abstractions and create mental models, it can be applied to the development of software
systems as well [20]. Model driven approach is claimed to increase the productivity of developers,
decrease the time to develop a software, help to improve reuse of software and also makes the soft-
ware more maintainable [20].
Figure 1.5: Cyber Physical System from [32]
A cyber physical system involves computation, communication and control as its three major
requirements. A cyber physical system can be envisaged as provided in Figure 1.2. Software de-
velopment was always based on a closed assumption, that the boundary between the system and
the milieu in which it is expected to operate is known during design time and is not subjected to
drastic changes [40]. But in the case of a cyber physical system, it is not possible to have a complete
knowledge about the system environment in which it operates.
Cyber physical systems are thus required to support modifications that are not expected at
design time as they are expected to be triggered by the system context at run time. Such modifica-
tions require a context aware working of the designed system which requires modifying the working
of the system without affecting the rest of the system [40]. This context aware working of the cyber
physical system is suited for the problem at hand and hence the need for a suitable programming
framework will be justified in the succeeding chapter.

Autonomous Trucks
1.0.2 Research Objectives
The development of a dynamic control software remains the primary objective. The control software
needs to be designed with the location of the truck as input and the most important aspect of the
software is its actuation, i.e, driving the truck by setting steering angle and throttle.
Self adaptation is a feature of cyber physical system that is suitable to explore when the context
of the environment is subject to changes. For example, during the autonomous driving of a truck,
an unforeseen obstacle has been introduced and thus, the software needs to make run-time changes
in the actuation to avert a collision. Thus, it could be expected that the incorporation of self adapt-
ation features could lead to furthering of level of automation but realizing self adaptation features
depends on the target environment in which it operates. For example uncertainties and unexpected
events happening in the environment, which is otherwise not changing is required to best realize
the concept of self adaptation.
A path-finding algorithm is the first step in vehicle movement. Assuming a two dimensional
grid input to the algorithm, the problem and solution in such a case will be two dimensional. The
requirement of moving a truck and semitrailer is a third spatial dimensional problem and hence
the applicability of a two dimensional solution to a three dimensional spatial requirement must
be studied. The path finding algorithm for vehicle movement usually involves the kinematic con-
straints of the vehicle. Thus the requirement of kinematic model being incorporated in the path
planning algorithm can be examined. It could also be argued at this stage that, the ’motion’ of the
vehicle which must be made in accordance with its kinematic constraints. Thus integrating the
kinematic model into the motion planning framework could also be done.
The control software framework developed must be made to work in a target environment like a
simulation or in a scaled truck semitrailer. In the former case, a computer with a modern processor
is required to perform the computation and communicate with the simulator. In the latter case, a
single board computer can be mounted on the scaled truck to achieve the functionality.

Autonomous Trucks
1.0.3 Research Questions
1. Can a model based self adaptive control software framework for autonomous truck semi trailer
combo vehicle be developed?
Control software to be developed for autonomous trucks is aimed to be reactive, in the sense
of adapting/ using portions of code as required. For this purpose, a software framework called
OSGI which is based on Java is proposed and its features and advantages are covered in the
next chapter. Model based software development is attempted for its advantages over the tra-
ditional software development.
2. Can a path finding algorithm for autonomous truck semi trailer vehicle be integrated into the
developed framework above?
Path finding algorithms, when using a grid based reference provides two dimensional solu-
tions. The applicability of a two dimensional solution to a third dimensional spatial require-
ment of moving a truck semitrailer as discussed in the previous subsection presents us with
this research question.
3. How can the Kinematic Model of the Truck Semi Trailer be integrated into the Path finding
algorithm
Truck movement must be made in accordance with its kinematic model and also respecting its
non-holonomic constraints. Whether, the kinematic model of the vehicle be encoded in the path
planning algorithm, i.e., some aspects like the configuration of the vehicle being included in
the path planning algorithm similar to the one in [4] can be explored. It could also be argued at
this stage that, the ’motion’ of the vehicle which must be made in accordance with its kinematic
constraints. Thus integrating the kinematic model into the motion planning framework could
also be done.
4. Can the developed framework be implemented for a Raspberry Pi mounted on a miniature
autonomous truck?
The control software must be tested for its correctness. For this purpose, deploying them on
a single board computer or digital simulation environment like UNITY must be explored.

Autonomous Trucks
Chapter 2
Preliminaries
This chapter introduces the preliminary ideas that lies behind this research, in the context of the
problem at hand, followed by the project/software context, system context and at last by the target
platform context.
2.1 Problem Context

Autonomous movement of the truck-semitrailer in distribution centres requires making an autonom-
ous movement from the parking station to one of the docking stations. The initial movement requires
forward mode driving, whereas docking requires reverse mode driving as the semitrailer must be
presented to the docking station to unload the goods into the distribution centre. An example of
truck and Semitrailer from [22] is presented in the figure below.
Figure 2.1: Truck Semitrailer example from [22]
A fully autonomous implementation from the perspective of Automotive engineering for steering
the vehicle has been developed [9]. The present approach in this research is from the perspective
of Embedded Systems using the programming framework OSGI with an aim of building a novel
control software that has the capability to adapt its behaviour is aimed.
The model of distribution centre taken up for this implementation is shown in Figure 2.2. This
is the Jumbo distribution centre in Veghel which is also discussed in [9]. A miniature concept of
the Jumbo distribution centre is available at the Truck Lab of Automotive Engineering Sciences at
TU/e and is shown in Figure 2.3. Its dimensions are scaled down in the ratio of 1:13.3 [9].

Autonomous Trucks
Figure 2.2: Jumbo Distribution Centre in Veghel from [1]
Figure 2.3: Model of Distribution Centre in Automotive Engineering Sciences Lab of TU/e
The problem context presents us with the following ideas about the preliminary requirements
for the research implementation which will be explored in depth in the succeeding chapter.
• A fixed parking station from where the initial movement must be made.
• A forward and a full scale reverse motion (with precision) must be made in tandem.
• The constraint of correct docking on one of the provided docking stations.
Different from on road driving by the following account

• Traffic signals need not be taken into account.
• Concepts of dynamic obstacle avoidance, that concerns on road driving safety for other vehicles/-
passengers and moving human obstacles.
• Observing the rules of lane and lane keeping as in a road driving.

Autonomous Trucks
2.2 Project Context
In this section, the concepts used in this research from project context is discussed. A general notion
of the concepts and the reasons for choosing them are briefly discussed in the following subsections,
whereas detailed steps involved in the implementation is discussed in the next chapter.
2.2.1 Model Based Software Development

Model based software development is suitable for addressing the design complexity of a cyber phys-
ical system and evaluation of the system through a virtual prototype [13]. The aspect of re-usability
was utilized throughout the implementation where, several parts of the codes were statically im-
ported for reuse along with bundles requiring one another for a smooth operation of driving func-
tionally. Verification and automated code generation from models are not done as a part of this
research. Requirements are taken-up and individual functionality of modules were prefixed before
the implementation is done and hence it is relevant to call it model based development.
Advantages of model based software development apart from the ones presented in the intro-
duction is provided below.
• Early identification of bugs [13].

• Understanding the system behaviour at the model level is better than at the code level [13].
• Effective communication with stakeholders who are involved in the software development pro-
cess [20].
• It also helps in effective planning, as models helps us identify the precise nature of work to be
done [20].
Figure 2.4: Modelling Spectrum from [20]
The modelling spectrum from [20] is provided in Figure 2.4. In the code only approach, no
specific modelling approaches are taken into account. This makes the developed software/ system
difficult to understand [20]. The second category of the spectrum, code visualization where the
required functionality of the code to be achieved is visualized through separate models and they are
manually converted in to code [20]. The third category of the spectrum uses both code visualization
techniques and developing code based on models. This is Round-trip engineering and the approach
used for developing code using this category belongs to this method. A model centric approach was
originally aimed through Bit Reactive software but later it was dropped for the convenience of OSGI
framework like, Eclipse Equinox and also since most of the program functionality relies on OSGI.

Autonomous Trucks
The concrete rules of formal model based software development that resemble the design steps
from [13] is presented in the Figure below.
Figure 2.5: Formal Model Based Development Steps from [13]
The approach used in this research closely resembles the process of formal model based devel-
opment as shown in the Figure above and they are justified as follows.
1. At the Abstract Requirement modeling level, the variables that must be monitored and con-
trolled [13] were decided. In our development, the monitored variables is the position of the
truck. The controlled variables are the throttle and steering angles.
2. The properties of the desired system is determined [13]. The desired system must be able to
send control signals to the run-time environment to achieve the motion of truck and semitrailer
and receive position feedback on a continuous basis for analysis and deciding on further steps.
3. Creating concrete requirements model [13]. The concrete requirements are designed in such
a way that they address the system, sub systems , their functions and the amount of overlap
between the systems presents an opportunity for code reuse, which is also extensively used in
this research implementation.
4. Specification of the code Synthesis model. Here the concept of round-trip engineering comes
into picture.subsystems like path-planner and communication with the run-time environment
are developed as code and they are visualized later as models. subsystems like orientation
finder and motion planner are developed as models and subsequently developed as a code.
5. Synthesize the source code [13]. When OSGI bundles are run using Eclipse Equinox frame-
work, a validation check is performed to satisfy the external dependencies that are needed.
This is followed by resolving the internal run-time bundle requirements and packages that
are needed by one another. This is followed by checking the compilation requirements (if any
unresolved compilation is found, the program cannot run for example an typo/error in code).
Once all these phases are successful, the compiled executable code is generated and it runs.

Autonomous Trucks
2.2.2 Open Source Gateway Initiative (OSGI)
The control software for an autonomous truck needs to adapt its behaviour at run-time. Thus, Open
Source Gateway initiative (OSGI) technology framework, which supports the dynamic adaptation
of the software modules is suited for its development as discussed in [39]. OSGI allows creation of
applications that are packaged known as bundles [39]. Figure 2.6 from [37] explains the layered
model of OSGI architecture. OSGI has been used to create complex applications like IDE, applica-
tion servers and application frameworks etc [10].
A bundle refers to a unit of modularity and in a practical sense it is a Java .jar file. But there
is difference between a normal .jar file and an OSGI bundle. Bundles have OSGI metadata that
provides details about the bundle version, the packages within it that are visible and also informa-
tion about what packages need to be imported. Using this information, the OSGI framework does
not need to load all the classes in every bundle unlike .jar files. This aspect improves the speed of
the system [37].
Bundles can create objects and subsequently register them with the service registry. Other
bundles can get the registered services through this registry. This aspect has the advantage of
bundles getting swapped and updated without turning off the rest of the system [37]. Other ad-
vantages of OSGI is provided below.
Figure 2.6: Layered Model OSGI Architecture from [37]
Advantages of OSGI
1. OSGI allows to model segments of code as bundles, which can be used flexibly at run-time
[39].
2. Updating of components with less downtime i.e., bundles can be updated without turning off
the system [37].
3. Reduction in complexity [37], as component based models require reduction in the lines of code
needed to make a certain functionality.
4. OSGI also supports abstraction for the components to hide their inner workings [37].

Autonomous Trucks
2.2.3 Kinematic Model
Kinematics is a branch of classical mechanics that describes the motion of bodies [14]. A kinematic
model is a model describing its motion without considering its force and mass [18]. The kinematic
model is important to be understood for vehicle movement. The vehicle model used here is of a singly
articulated type as shown in Figure 2.7. The Kinematic model of the singly articulated vehicle from
[18] is shown in the figure below.
Figure 2.7: Kinematic Model of a Singly Articulated Truck and Semitrailer from [18]
The vehicle shown in Figure 2.7 consists of a tractor with one front and one rear axle, a trailer
with one axle. A kingpin point, connects the tractor with the trailer. The steering angle input is
given by δ. v0 represents the longitudinal velocity. It is defined at the reference point (x0 , y0 ). θ0
and θ1 represents the heading angles of the tractor and semitrailer.
The heading angle of the tractor and semi-trailer are represented by θ0 and θ1 .γ represents the
articulation angle, which is the difference in heading angle between tractor and semi-trailer. L0
represents the wheelbase of the tractor. Lob represents the distance between rear of the tractor
and the kingpin (x1f , y1f ). L0b will be negative for a normal tractor-semitrailer combination. L1f
represents the distance between the kingpin and the axle of the semi-trailer (x1 , y1 ). The kinematic
model is based on the constraint that the wheels on the axles have no side-slip. The equations that
can be written down for the kinematic model from [18] of the vehicle is as follows.

Autonomous Trucks
θ˙0 = (v0 /L0 ) ∗ tan(δ)); (2.1)
θ˙1 = (v0 /L1f ) ∗ (sin(δ) − (L0b /L0 ) ∗ tan(δ) ∗ cos(δ)); (2.2)
x˙0 = v0 ∗ cos(θ0) (2.3)
y˙0 = v0 ∗ sin(θ0) (2.4)
˙ = x˙0 − L0 ∗ sin(θ0 ) ∗ θ˙0
x0f (2.5)
˙ = y˙0 + L0 ∗ cos(θ0 ) ∗ θ˙0
y0f (2.6)
˙ = x˙0 + L0b ∗ sin(θ0 ) ∗ θ˙0

x1f (2.7)
˙ = y˙0 − L0b ∗ cos(θ0 ) ∗ θ˙0
y1f (2.8)
x˙1 = x˙0 + L0b ∗ sin(θ0 ) ∗ θ˙0 + L1f ∗ sin(θ1 ) ∗ θ˙1 (2.9)
y˙1 = y˙0 − L0b ∗ cos(θ0 ) ∗ θ˙0 − L1f ∗ cos(θ1 ) ∗ θ˙1 (2.10)

γ̇ = θ˙0 − θ˙1 (2.11)
2.2.4 Motion Primitives

A motion primitive is the motion pattern that is made in accordance with the kinematic model of
the vehicle. The motion primitive encodes the constraints provided by the kinematic model of the
vehicle. It is a trace graph between a start and end point for the provided dimension of the truck-
trailer with, velocity and steering angle constraints. This problem can be solved using the ACADO
toolkit as done in [21] (where a kinematic model of two trailer system is taken up). The kinematic
model under consideration for this research is different from the one in [21].
The kinematic model of a singly articulated truck is prescribed by equations 2.1 to 2.11. The
global orientation of the trailer i.e. theta1 and the heading of the rear axle point of the semitrailer
(x1 , y1 ) is the most important requirement for the motion primitive trace graph that is required.
Thus we take up the parameters in the following form.
p = (x1 , y1 , θ1 , γ)
where p denotes the states [24].
In order to obtain the motion primitive using the kinematic model from ACADO toolkit, the fol-
lowing boundary value problem is solved
Z T
minimizeu(.), T fo (p̄(t), u(t))dt
0
subject to
˙ = fo (p(t), γ(t))dt
p(t)
˙ =ω
δ(t)
˙ =u
ω(t)

Autonomous Trucks
fo (p̄(t), u(t)) is the objective function of the truck semitrailer system which can be taken up as
10 ∗ ω 2 + u2 + δ 2 .
This objective function is taken up as it is argued that it is possible to generate smooth steering
angles when possible [21]. f (p(t), γ(t)) is the model of the truck semitrailer system which is given
by the equations 2.1 to 2.11. u(.)andT are the decision variables of the problem. Here u(.) repres-
ents the rate of acceleration and T refers to the final time. T can either be minimized or it can be
provided with a lower and upper limit as an input to ACADO toolkit.
These equations and the concept of boundary value problem solving is from [21], which is de-
veloped for a full scale truck-semitrailer combination using ACADO toolkit. The specification of the
problem relies on taking up the upper maximum and minimum values for the parameters provided
in the Kinematic model. The velocity is fixed and the steering angle is to be input as a variable. The
experimental results with respect to the motion primitive graphs is covered in depth in chapter 4.

Autonomous Trucks
2.2.5 UNITY Simulator
The truck lab that finds mention in Section 2.1 is available in the form a digital simulation in the
UNITY platform. This interface is a replica of the model available in the Truck lab. This provides
us with a handy platform to test the developed code. The scene of the simulation is presented in
Figure 2.8. The simulator’s dynamics of truck motion is respected by UNITY Physics Engine [8].
Figure 2.8: UNITY Simulation Setup
2.2.6 ArUco Markers

ArUco markers refer to the camera trace of three markers, one placed over the truck and two other
placed over the semitrailer and is as shown in the figure below.
Figure 2.9: ArUco markers from the simulations setup

Autonomous Trucks
2.3 System Context
The source code developed as OSGI bundles is done in the Eclipse Equinox OSGI framework. The
bundles work together to send control signals (in the form of throttle and steering) to the UNITY
Simulator and receive back data signals (in the form of position feedback). The position feedback in-
formation is based on simulated cameras in the UNITY module. Communication happens through
the internet by making use of the Network UDP facility in the simulator. The diagram below shows
the architecture of the system to be developed.
Figure 2.10: Architecture of the System

Autonomous Trucks
2.4 Platform Context
In-order to test the correctness of the proposed implementation, a suitable target environment is
needed. This could be a digital simulation as envisaged in the previous section. In case of a digital
simulation, the developed code can be run in the same computer in which the simulation is operat-
ing. Thus Intel processor is taken up as one possible platform.
The primary deployment scenario of the developed control software is aimed to be the UNITY
simulation as envisaged in the previous section. However, the deployment of the developed software
is also aimed for a single board computer for mounting on experimental truck in the truck lab. The
Raspberry pi is chosen for the following reasons.
1. The working Random Access Memory (RAM) of Raspberry Pi is high. The memory complexity
of the code to be developed is aimed to be high as many functionalities along with the A*
algorithm is aimed to consume a high working memory.
2. Raspberry Pi supports C, C++, Java and Python [24]. In our case, OSGI is an extension of
Java and hence the support for Java remains handy.
3. It is possible to expand the circuit of the Raspberry Pi with other electronic components like
sensors and electronic circuits [24]. This is also suitable for this case of implementation as
sensors and other prototyping circuits must be employed for realizing the self adaptation fea-
tures offered by OSGI.
A preliminary analysis can be drawn up based on the target platform.
• It is noteworthy though both OSGI (which is based on Java) is platform independent i.e. it gets
converted to Byte-code. It could be interesting to make a comparison in such a case between
Raspberry Pi and the Intel processor. The metrics in such a case could be confined to run time
comparison between the processors for moving the truck up to a particular way-point.

Autonomous Trucks
Chapter 3
Design and Implementation
This chapter is devoted to the design and implementation steps, specifically the design of OSGI
bundles. The implementation steps are taken up in a phased manner.
3.1 Requirements
The following requirements are identified for implementation.
• A grid representing the dimensions of the truck lab must be taken-up.

• A path-planning algorithm must be present to find the path between the two given points in
the grid.
• A motion planning framework must be present for actuating/ steering the vehicle.
• A dedicated orientation finder must be present for finding the orientation of the vehicle at any
given point of time.
• The motion of the vehicle must be made in accordance with its kinematic model.
• A dedicated communication module of the software must be present for communication with
the UNITY simulator as envisaged in the previous chapter.
• A master launcher module must activate/cooperate with other functionalities to achieve the
intended overall driving of the vehicle.

Autonomous Trucks
3.2 Implementation Approach
This subsection presents the overall driving functionality. The implementation can be simplified to
the Master Launcher OSGI bundle, which activates itself and has the requirement of services from
all other bundles and it acts as a master switch for the algorithm. The overall driving functionality
is presented as a glimpse in Figure 3.1 and elaborated below.
• The way-points are set in the master launcher bundle.

• For every way-point, Astar search is performed, followed by actuation of the vehicle as dis-
cussed in the previous subsections with the help of UNITY communication.
• The UNITY communication bundle also provides the feedback signal, i.e., position of the
ArUco markers.
• Throttle is constant and increases slightly for steeper angles according to the rationale that
steeper angles require more turning velocity. This is arrived by experimenting with the sim-
ulator.
• The time for which the actuation needs to be made is a constant and set along with the actu-
ation command. In the case of forward driving, a time unit of 5 seconds and for reverse driving
a time unit of 2 seconds is set for all possible steering angles.
• Checking for collision is a possibility with the simulator [7]. But it does not provide information
about the probability of collision.
Figure 3.1: OSGI services implementing the driving fuctionality

Autonomous Trucks
3.3 Path planner
A path planning algorithm forms the primordial step towards any driving, thus this subsection
focuses on the path planning algorithm used in this implementation. Among the graph search
algorithms, A* algorithm has completeness and optimality for a chosen cost function and it is the
suitable choice in most robotic path finding applications [6]. The scale of the provided simulator is
given in Figure 3.2. This scale is obtained by experimenting with the simulator and retrieving the
position information of the truck in all the four quadrants. For the purposes of this implementation
and to keep the grid dimensions as unsigned numbers for the convenience of programming in Astar
path-finding, it has been converted to the dimensions as shown in Figure 3.3.
Though in a mathematical sense, x and y axes are contrary to the one provided here, but since the
UNITY simulator y-axis is taken as x-axis, it will be convenient for the position parser subsystem
to convert the dimension from the UNITY position feedback. The dimensions presented in Figure
3.3 is provided as two dimensional grid input to the Astar algorithm. Path-planner is developed
as a separate OSGI bundle and it gets the source and destination coordinates as inputs and gives
out the closed list and its length as outputs. A brief routine of the algorithm inspired by [31] is
presented in Algorithm 1. If the source and the destination coordinates are similar, the algorithm
will prompt the user to change the coordinates.
Figure 3.2: Dimensions of the provided Simulator

Autonomous Trucks
Figure 3.3: Dimensions chosen for implementation
Algorithm 1 Pseudocode for Astar Algorithm

1)Initialize xsize ←55 ysize←60
2)Forall GRID[xsize][ysize]←1
3)Forallobstacles GRID[][]←0
4)Compute G, H and F costs
5)Assign open, closed,neighbour, taken lists
6)Set counter variable← 0
7)Set neighbourcounter← 0
8)Set pathnotfound←true
while pathnotfound do
if countervariable > 0 then
Choose the neighbour with smallest F cost
Assign the chosen neighbour to the takenlist
end
Assign taken to the closedlist
if takenlist coordinates matches destination coordinates then
Set pathnotf ound=f alse
end
Flush the neighbourlist
Label:
for the neighbours of current taken point do
Update G, HandF costs
Assign a new temporarylist with updated costs
if the temporary list is a member of closedlist then
go to Label:
end
Assign the temporary point with costs to the neighbourlist
Increment the neighbourcounter
end
Increment countervariable
end

Autonomous Trucks
3.4 Design of Actuation System
The control mechanism available in the simulator is the ASCII payload that must be sent to set the
appropriate steering angle and the velocity. The steering angle is in the range of (-1,1) maps to (-45
to 45 degrees) and for throttle (-1,1) is in the order of km/h [8]. The Actuation System achieves the
actual movement of the truck-semitrailer system by the information provided by the path-planner.
The motion planning designed in this project involves obtaining the orientation of the vehicle as the
vehicle can take different possible orientations in a 360 degree angle scale. This could be envisaged
through the following illustrative diagrams.
Figure 3.4: Possible orientations of the Vehicle (Diagram Not to Scale)
Figure 3.5: Orientation Angle Diagram
The orientation of the vehicle can be envisaged in the figure above and the angles to which they
belong. This presents us with the information that angles 45, 135, 225 and 315 falls common to
two different orientations. Such scenarios need to be considered as intersection angles for motion
control.

Autonomous Trucks
3.4.1 Determination of Orientation of the Vehicle
Determining the orientation of the vehicle is important before motion planning and thus this sub-
section covers the procedure behind finding the orientation of the vehicle. The angle between the
front marker i.e., (x1,y1) and the third marker (x3,y3) can give us information about the orientation.
Angle between the points could be found by constructing a right angled triangle. Since this method
reported inaccuracies during some positions of the truck-trailer, the converse of it has been used,
explained in the following enumeration
• For an angle of 45 degrees the absolute difference y3-y1 is found to be 5 in the assumed simu-
lator scale. This is common to the angles 45, 135, 225 and 315 as provided in the orientation
angle diagram. These angles overlap between the orientations, however for the purposes of
this implementation they are clubbed with NS or SN orientation.
• This leaves us with the cases of absolute value of y3-y1 lesser than 5 to be less than 45 degrees
and hence they could be categorized to EW or WE orientation and absolute value of y3-y1
greater than 5 informs us angle greater than 45 degrees to belong to NS or SN orientations.
3.4.2 Motion Planning Framework

The motion planning framework forms the most important part of the cyber physical system that
decides the steering and throttle commands that must be sent and receives position feedback in-
formation from the UNITY interface. The information of closed list from the path-finding algorithm
is taken-up and algorithm 3 provides the detailed steps involved in motion planning. The reverse
motion is also achieved by the same motion planning framework in a reverse driving context. The
reverse motion planning framework is presented in algorithms 4 and 5. In the algorithms, even
when the angles are computed to be a nan (not a number), a steering angle of 0 is set and the
vehicle will be in motion.
The motion planning framework takes the front ArUco marker for forward movement and into
account but it may-not place the truck-trailer always at the desired point. Thus it is important to
account for errors in the steering angle. Thus for froward motion, steering angle error is calculated
by algorithm 2. Figures 3.6 and 3.7 provides a visual representation of how steering angle error is
accounted for different orientations of the vehicle.
The nature of motion is determined by the sign of the steering angle as error can either be
negative or positive and hence it is appropriately added to account for steering angle errors. The
steering angle error calculation is not accounted for reverse motion planning framework, as rear
ArUco marker is used for reverse motion (using Astar) and hence accounting of errors based on rear
ArUco marker will be cumbersome. The case of reverse motion using motion primitives also does
not involve error computation as at present a precise motion is achieved without error computation.

Autonomous Trucks
Algorithm 2 Routine for Steering Error Calculation
Result: Steering angle error
if abs(actual.x-exp.x> 2) then
if East West Orientation then
error=(actual.x-exp.x)/10
end
if West East Orientation then
error=(exp.x-actual.x)/10
end
end
Figures 3.6 a and b provides an idea about error computation with respect to steering angle
and since the orientations must be aligned to x-axis, correcting them with respect to x-axis alone
produces smooth driving. The same approach for North south and South North orientation with
respect to y-axis as shown in figures 3.7 a and b was previously included in the code, but later it
was not taken up as it produced incorrect results. Figures 3.8 to 3.11 provides the idea behind the
motion planning based on different orientations of the vehicle.
Figure 3.6: East West/West East Orientation Steering Error
Figure 3.7: North South/South North Orientation Steering Error

Autonomous Trucks
Figure 3.8: East West Orientation
Figure 3.9: West East Orientation

Autonomous Trucks
Figure 3.10: North South Orientation
Figure 3.11: South North Orientation

Autonomous Trucks
Algorithm 3 Routine for Forward Motion Planning Framework
while closed list 6=∅ do
for (i=0;i<length(closed list);i=i+5) do
orientationinf o ←orientation
if East West Orientation

p then
hypotenuse ← (dest.x − source.x)2 + (dest.y − source.y)2
cosangle ←arccos((dest.y − source.y)/hypotenuse)
sinangle ←arcsin((dest.x − source.x)/hypotenuse)
if cosangle > 90(degrees) then
declare TURN INFEASIBLE
end
EastW eststeeringangle ←–sinangle/scalingfactor
end
if West East Orientation
p then
if cosangle < 90(degrees) then
end
W estEaststeeringangle ←sinangle/scalingfactor
end
if North South Orientation
p then
tanangle ←arctan(dest.x-source.x)/dest.y-source.y)
sinangle←arccos((dest.x − source.x)/hypotenuse)
if sinangle < 0(degrees) then
end
N orthSouthsteeringangle ←tanangle/scalingfactor
end
if South North Orientation
p then
tanangle ←arctan(dest.x-source.x)/(dest.y-source.y)
if sinangle > 0(degrees) then
end
SouthN orthsteeringangle ←–tanangle/scalingfactor
end
end
Add steeringangleerror from the previous step
Actuate the vehicle usingthecalculatedsteeringangle
end

Autonomous Trucks
Algorithm 4 Routine for Reverse Motion Planning Framework for Docking Choices 1 and 2 (using
Motion Primitives)
while Motion Primitive List 6=∅ do
for Motion Primitives List do
p then
end
end
p then
end
end
p then
tanangle ←arctan(dest.x-source.x/dest.y-source.y)
end
N orthSouthsteeringangle ←–tanangle/scalingfactor
end
p then
cosangle ←arccos((dest.y − source.y/hypotenuse))
end
SouthN orthsteeringangle ←tanangle/scalingfactor
end
end
end

Autonomous Trucks
Algorithm 5 Routine for Reverse Motion Planning Framework for Docking Choices 3 to 10 (using
Astar Algorithm)
while closed list 6=∅ do
for (i=0;i<length(closed list);i=i+1) do
p then
end
end
p then
end
end
p then
tanangle ←arctan(dest.x-source.x/dest.y-source.y)
end
N orthSouthsteeringangle ←–tanangle/scalingfactor
end
p then
cosangle ←arccos((dest.y − source.y/hypotenuse))
end
SouthN orthsteeringangle ←tanangle/scalingfactor
end
end
end

Autonomous Trucks
Figure 3.12: Flowchart for Motion Planning
3.4.3 Design of Communication Module

The design of UDP communication bundle is discussed in this subsection. The UDP communica-
tion bundle shares the primary responsibility of sending and receiving UDP packets through ports
54320 and 54321 [8]. The packet sender subsystem is responsible for sending and receiving pack-
ets, but the information received is in the form of a string and the scale of the simulator is different
to the scale taken up for this implementation and hence they are parsed accordingly by a position
parser subsystem.
3.4.4 Other Implementation Specifics

The core implementation details were covered in the previous subsections, whereas this subsection
presents other details.
• For UNITY interface, most of the services offered by any bundle is not accessed through the
service registry, as services like path-planning, UNITY communication and parser for position
feedback information are meant to be static, i.e. their functionality does not changes during
the run-time of the program and hence they are imported as dependencies to the launcher
bundle. This performs the whole operation of running, thus the dynamism offered by OSGI
could not be best captured for UNITY simulator interface as it does not have say for example
a changing event notification like a sensor reading.
• Equinox OSGI framework offers two ways for bundles to use each other’s services. i.e., require
bundle gives all the classes and its sub dependencies in the bundle and hence it is tantamount
to importing the whole package (assuming one package per bundle), wheres import-package
offers a custom fit to add the specific classes in a particular bundle/package.
• Eclipse Equinox OSGI framework and Eclipse IDE are used, in combination with JAVA Stand-
ard Edition 1.8 and JAVA Standard Edition 1.7 as execution environments for Intel processor
and Raspberry Pi respectively.

Autonomous Trucks
Chapter 4
Experimental Analysis
This chapter is dedicated for presenting the experimental results and analysis including motion
planning framework comparisons, motion primitives and finally the implementation on Raspberry
Pi is discussed.
4.1 Vehicle Movement through Way-points- a Discussion

The desired motion is to be achieved by choosing way-points and the idea is from [9]. The primary
bundles that are needed to implement the driving functionality of the vehicle is available, but since
the motion involves avoiding the obstacles, walls, boundaries and other fences, a maneuvering plan
must be made to make the movement from point to point with the primary responsibility of avoid-
ing static obstacles. Thus the choice of way-points and the reasons for choosing them are discussed
below.
The following rules for the choice of way-points are arrived after performing experiments with
the simulator.
• First way-point is chosen as the first exit on the right side as shown in the Figure 4.2. The
choice of this way-point is common for any possible combination of parking to docking stations.
• The exit on the left side has been avoided as the present orientation of the trailer is tilted
at an angle of 45 degrees to both the reference axes, a leftward movement cannot be made
without colliding with other trucks (assumed to be present but not shown in the simulator).
Such choices of way-point on the left side also leaves us with collision of the truck in the wall.
• The movement of the vehicle can be visualized in the following Figures from 4.1 to 4.5. The
movement from way-point 3 to the docking station is reverse mode driving.
• The choice of docking station can be selected in the program and hence the way-point 3 and
the subsequent reverse motion changes accordingly.

Autonomous Trucks
Figure 4.1: Initial State
Figure 4.2: Waypoint-1

Autonomous Trucks

Autonomous Trucks
Figure 4.5: Docking State
Figure 4.6: Docking State (in Focus)

Autonomous Trucks
4.2 Comparison of the proposed Motion Planning Framework
with that of a PID controller
PID control can be used for either velocity or steering angle control or both. It takes into account,
the proportional, integral and derivative terms for control. PID controller is used widely in industry
that requires continuous changes in control [35]. The proposed motion planning framework is not
based on a control system concept, but it is still relevant to make a comparison from the perspective
of driving functionality as the same simulator driving is implemented using PID control in [8].
4.2.1 Trajectory Comparison

The trajectory of the path taken by our motion planning framework for the purpose of comparison
to that of the PID controller could be justified by the following trajectory comparison. Figure 4.7
shows the trajectory of the truck movement i.e., the position trace of ArUco markers during the
simulation. The figures units are in metres and is same as the dimensions of UNITY simulator as
shown in Figure 3.2.
It takes a total of 22 seconds to make this trajectory and the reaching of central wall happens
around time t=12.5 seconds. Since the objective of truck movement from its initial position to the
first way-point tasks resembles our case, it presents an opportunity to analyze our motion panning
framework to the PID controller in-terms of linear velocity and steering angles.
The trajectory in Figure 4.8 is obtained using the developed control software. It must be seen
along with the full scale of the simulator (as shown in Figure 3.2.2 to have a clear overview). It
could be noted that the trajectory is for Front ArUco markers position and the line is a trace of
the corresponding marker. It could be observed from both the graphs that the distance travelled is
almost similar.
Figure 4.7: Trajectory of ArUco markers during simulation from [8] (Dimension scale as in Figure
3.2 all units in metres)

Autonomous Trucks
Figure 4.8: Trajectory of Front Aruco marker using our software (Dimensions as in Figure 3.3
4.2.2 Throttle/Velocity Comparison

In our driving scheme, throttle signal is kept constant. For steering angles less than 0.5, a throttle
of 0.1 km/h is set. For steering angles of 0.5 and above, a throttle of 0.2 km/h is used. It is correct to
observe careful turns during sharp corners, assuming a turn in a road driving environment which
usually does not require steeper turns. But in the provided distribution centre, sharp turns can be
observed like turns during exit walls.
Apart form that, there may be situations in which a sharp turn with high throttle could be re-
quired. For example when moving the vehicle from its initial state, a steep turn is required to make
a right turn and at the same time avoid going closer to the front wall. Thus keeping throttle as
0.1 for all combination of steering angles mostly results in the collision with the wall. The present
combination produces smooth trajectories, obtained by experimenting with the simulator.
The control signal is only for setting the throttle, whereas linear velocity varies during the run-
time and thus it is relevant to plot the linear velocity of km/h over time in seconds. PID controller
model takes 22 seconds to achieve the motion until way-point 1 whereas the software developed in
this research requires 32 seconds to traverse the same distance. This could be attributed to the
lower throttle/ linear velocity setting in our case which is also evident from the graphs 4.8 and 4.9
where the throttle used in the case of PID controller is almost double to the one used in this imple-
mentation.
Linear velocity is almost a constant from our simulation, whereas in the scheme used in [8], it
has minute variations as it is understood that the throttle is varied according to feedback whereas
in our case it has been fixed for a particular set of steering angles.

Autonomous Trucks
Figure 4.9: Truck Linear Velocity during our simulation until waypoint1
Figure 4.10: Truck Linear Velocity from [8] using PID controller (X-axis-Time in Seconds and Y-
axis-Linear Velocity in km/h)
4.2.3 Steering Angle Comparison

The steering angle is the other control signal and hence it is also relevant to be plotted. Steering
signal is given as a sinusoidal input in [8] whereas they take a deterministic form in the proposed
novel motion planning framework. This could be envisaged in Figures 4.11 and 4.12.

Autonomous Trucks
Figure 4.11: Steering angle during our simulation until waypoint1
Figure 4.12: Steering angle from [8] using PID controller (X-axis-Time in Seconds and Y-axis-
Steering angle in degrees)
4.3 Experiments with Motion Primitives

The following parameters are set for the generation of motion primitives using ACADO toolkit.
• The dimensions of the truck and semitrailer are taken up as provided in the report [18]. Ac-
cording to the report the dimensions are L1f = 7, L0b = -0.2, L0 = 3.8. (in meters)
• The velocity profile is in m/s whereas the simulator works with km/h.
• The motion primitive graph involving the heading angle of the trailer (i.e. θ1 could now be
generated. Thus it is important to do some experiments with different velocity profiles and
the rear axle position of the semitrailers (i.e. (x1 , y1 )) and they are presented in the following
subsection.

Autonomous Trucks
4.3.1 Maximum Velocity
The primitive graphs that are generated could be plotted as functions of time to understand how the
truck and trailer will behave when subject to its kinematic constraints. Since the lower and upper
limit of speed in the unity simulator is +-1 km/h, It could be insightful to generate the properties of
the kinematic constraints over time by setting the maximum velocity.
Figure 4.13: Plot of the rear point of trailer (left) and heading angle of trailer (right) with time
Figure 4.14: Plot of gamma (left) and delta (right) with time

Autonomous Trucks
Figure 4.13a is the trace of the rear point of the trailer (x1,y1) that was discussed in the kinematic
model. The graph has (0,0) as the starting position of the trailer and (20,20) as the end position of
the rear marker which is set in the ACADO toolkit. From graph 4.13b it could be observed that a
time of 120 seconds is taken up for achieving this motion pattern. The heading angle of the trailer
during the motion will be as plotted in 4.13b. Figures 4.14 a and b provides information about
gamma and delta (which is the steering angle component). The steering angle fluctuates between
-0.1 to +0.3 in the given span of 120 seconds.
4.3.2 Example Velocity used in our driving

The motion primitive graphs for velocity used in our driving for steering angles 0.5 and above i.e.
0.2 km/h (0.06 m/s) for which the graphs are as follows.
Figure 4.15: Plot of the rear point of trailer (left) and heading angle of trailer (right) with time
Figure 4.16: Plot of gamma (left) and delta (right) with time
Figure 4.15a is the trace of the rear point of the trailer (x1,y1) that was discussed in the kinematic
model. The graph has (0,0) as the starting position of the trailer and (20,20) as the end position of
the rear marker which is set in the ACADO toolkit. From graph 4.15b it could be observed that a
time of approximately 600 seconds is needed for achieving this motion pattern. The heading angle
of the trailer during the motion will be as plotted in 4.15b.

Autonomous Trucks
Figures 4.16 a and b provides information about gamma and delta (which is the steering angle
component). The steering angle fluctuates between -0.25 and +0.3 in the given span of 600 seconds.
Thus it will take 10 minutes to achieve a motion of 20 metres with the given constraints.
4.3.3 Usage of Motion Primitives

The motion primitive graphs now contains the heading angle of the trailer θ1 . But the motion
primitive graphs still could not be integrated in the present control software due to the following
reasons.
1. Graphs obtained by lower velocities i.e. for 0.1 km/h (0.03 m/s) produces unstable results.
Thus lower throttle requirement in forward driving for steering angles below 0.5, cannot use
these graphs.
2. In forward motion primitives, the solver fails for lower distance points like (3,3) and (5,5) and
hence generating finer primitives for lower distances is needed for UNITY simulator since
static obstacles like the wall and the presence of nearby trucks in the initial state of the truck
must be accounted.
3. Also the present implementation in ACADO toolkit is not able to provide the motion graphs
for reversing motion which is a major limitation for integrating them in the reverse direction.
However ideas using the graph were taken up and by trail and error correct motion primitives
were worked out for reverse motion for docking choices 1 and 2. Working out motion primitives
by trial and error is time consuming and not always reliable.
4. The generated primitives are not sophisticated in the sense as a trail of primitives as done in
[21] could not be realized.
5. Primitive generation forms part of offline planning [21][28] and the requirement of driving
functionality constitutes online planning, thus with only one primitive that could be generated
at a time by the present ACADO toolkit, it will be cumbersome to rely on it for driving decisions.
6. The solution to solve this problem in future is to use a more robust solver is provided in the
future work section.
Since the kinematic model of the vehicle using motion primitive graphs could not be integrated
properly (i.e. except for docking choices 1 and 2, a trial and error based reverse motion primitive
using the ideas from ACADO experimental results), an alternative rationale is used to avoid kin-
ematically infeasible motions which is integrated into the motion planning framework. They are as
follows.
• Steeper steering angles are scaled down by a factor because as per Ackermann’s steering geo-
metry’s principles, higher the turning angle, the deviation of the steering geometry from the
ideal one is more [29].
• Kinematically infeasible motions are assessed for every orientation and avoided. This is presen-
ted in Algorithms 3-5 and Figures 3.8 to 3.11.
4.4 Performance Comparison based on Target Platform

The deployment in the truck lab is not realized as a part of this research as, at present the cameras
and the model trucks are not in a good condition for experimenting. The same UNITY interface is
used for testing the software from the perspective of Raspberry Pi and Intel processors as envisaged
in Section 2.4. Also from [39], in-order to run OSGI on Raspberry Pi, Eclipse Equinox along with
management agent Apache Felix has been used [39]. The same approach is adopted in this imple-
mentation. The Eclipse Equinox framework is an OSGI container and it needs an IDE for which the
most suited one is Eclipse IDE. Raspberry Pi supports only versions Eclipse IDE versions like 3.8.1,
where the profiling tools like Java monitor were not working as intended and hence performance
comparison between Raspberry Pi and Intel processor could not be captured.

Autonomous Trucks
Chapter 5
To Conclude
This chapter revisits the proposed research questions to capture how far the research questions
are realized. This is followed by deviations from the original proposal, the conclusions that can be
drawn from the present research, limitations and finally the scientific contribution.
5.0.1 Research Questions and their Answers

1. Can a model based self adaptive control software framework for autonomous truck semi trailer
combo vehicle be developed?
The implementation of a control software through an OSGI framework is realized. The char-
acteristics of self adaptation using OSGI could not be captured and its reasons are discussed
in Table 5.1 and Subsections 5.0.4 and 5.0.5. However adaptation of the working of software
between different docking choices, using motion primitives and using Astar algorithm is im-
plemented. This makes the control software an Adaptive Cyber Physical System.
2. Can a path finding algorithm for autonomous truck semi trailer vehicle be integrated into the
developed framework above?
A novel approach to motion planning based on the results of Astar algorithm is devised and
hence achieving the driving functionality. The initially proposed lattice time bounded Astar
was dropped for it was developed for a single body motion truck whereas the case of this re-
search is a singly articulated truck with a semitrailer. (Lattice Time Bounded Astar is presen-
ted in Appendix A)
3. How can the Kinematic Model of the Truck Semi Trailer be integrated into the Path finding
algorithm
The kinematically feasible motion primitives are generated using the ACADO Toolkit. An
elaborate discussion on motion primitives integration (tantamount to integration of the kin-
ematic model) is presented in Table 5.1. It could be argued that a partial integration of the
kinematic model in the control software (specifically in the motion planning framework and
not path finding algorithm) has been done.

Autonomous Trucks
The kinematic model of the vehicle being encoded in the path planning algorithm as done in
[4] which was aimed when the research question is proposed is not vital as solving the mo-
tion primitives will provide all kinematically feasible paths and for shorter distances, even a
path-finding algorithm itself can be replaced, i.e., the motion primitive itself is a kinematic-
ally feasible path involving all the kinematic constraints of the vehicle and combining them
with the proposed motion planning framework can replace the path planning algorithm for
shorter distances. This is proved using algorithm 4 for reverse motion for docking choices 1
and 2. However for larger distances and different choices of motion primitives, a path planning
algorithm will still be required.
4. Can the developed framework be implemented for a Raspberry Pi mounted on a miniature

autonomous truck?
The developed control software framework is run on Raspberry Pi. Since generation of motion
primitives forms part of offline planning, they are not taken-up to be solved on Raspberry Pi
and hence ACADO toolkit is not installed on Raspberry Pi.

Autonomous Trucks
5.0.2 Deviations from the Original Proposal and their Reasons
Table 5.1 presents the deviations from the original proposal and their reasons also finds discussion.
5.0.3 Conclusions
Based on the answer to the research questions and the reasons for deviations in the previous sub-
sections, some conclusions can be drawn up and they are enumerated as follows.
1. A model based adaptive control software for autonomous trucks using OSGI programming is
realized with the run-time environment being UNITY digital simulation of the distribution
centre.
2. A path finding algorithm is integrated in the software framework. Kinematically infeasible
motions are coded in the motion planning framework, but the kinematic model of the vehicle
could not be fully integrated with the path finding algorithm as in the forward motion the
generated motion primitives are not suited to the present requirement. Still forward motion
is achieved in a kinematically feasible manner.
3. The ACADO toolkit was also not able to generate motion primitives for reverse motion but a
motion primitive using trail and error that achieves precise reverse motion with a straight
cabin in the end has been arrived at. This is used for docking choices 1 and 2. Whereas the
docking choices from 3 to 10 uses Astar algorithm. As the time required to arrive at the correct
motion primitive by trial and error is very high. This could be attributed to the higher number
of constraints in the kinematic model, the solutions space of correct motion primitive can be
less.
4. The control software developed based on OSGI is made to run both on an Intel processor and
Raspberry Pi and their run-time characteristics were assessed.

Autonomous Trucks
Proposed Aspect Reasons Alternatives Implemented
Hardware as at present the truck lab developed program is ported

Setup/Cluster equipment’s are not in a good to Raspberry Pi and the same
Computing condition. unity Interface is used for test-
ing and hence the need for
cluster computing also did not
arise.
Self Adaptation the present run-time environ- yes, adaptation of the program
using OSGI ment is not subjected to a dy- for the reverse motion accord-
namic change as the driving of ing to the choice of docking is
the vehicle is made by determ- implemented. This makes the
inistic way-points, however self control software an Adaptive
adaptation using OSGI could Cyber Physical System
be best captured by a dynamic
event based notification like
a proximity sensor reporting
a sudden unexpected obstacle
placed in the usual determin-
istic route. Thus self adapta-
tion using OSGI has been re-
quested as a future work.
Motion Primit- as motion primitives for yes, it could be argued that

ives Integration shorter distances and also for forward motion, assess-
involving the obstacles could ing and avoiding of kinematic-
not be generated for forward ally infeasible motions, avoid-
motion and the reverse mo- ing steeper steering angles as
tion primitives could not be per Ackermann’s steering geo-
generated at all. The solution metry principle’s as discussed
to overcome this problem is in subsection 4.3.3, with the
requested as a future work present choice of parameters
like constant low throttle for a
set of steering angles achieves
the kinematically feasible mo-
tions. However in the reverse
motion, a motion primitive for
docking choice 1 and 2 were
found out by extensive trial and
error that achieves smooth and
precise motion.
Lattice Time Lattice time bounded Astar yes, a simpler version of Astar
Bounded Astar seemed to be a complicated ap- algorithm suffices.
proach for it was originally de-
veloped for a single body mo-
tion truck whereas the case of
this research is confined to a
singly articulated truck with a
semitrailer .
Table 5.1: Original Proposal and its Deviations

Autonomous Trucks
5.0.4 Limitations and Future Work
• The UNITY simulator presents an opportunity to query the collisions states of the vehicle
with respect to the walls, fences, human objects etc [8]. The resulting information is static
and do not provide sufficient information to avert collisions (i.e. the probability of estimating
a collision based on the present trajectory). This leaves us with an opportunity to work on
collision avoidance based on trajectory estimation.
• In the present run-time environment, a change in context in the working of the program can be
created by accidentally setting way-points that is expected to have a collision and let program
adopt to the change in context. However, it does not present us with an opportunity of an
unexpected event when the way-points are deterministic. Thus the concept of self adaption
using OSGI in a dynamic unexpected change in run-time context will be more suited. For
example, a sudden obstacle is placed in the usual route of a deterministic way-point and a
proximity sensor dynamically reports (an event based notification) which leaves us with a
change in context. Thus self adaptation using OSGI could be requested as a future work.
• The limitations of motion primitives generated using ACADO toolkit is discussed in subsection
4.3.3. The solution to overcome the limitations is to use a more robust solver like CASADI and
IPOPT as done in [11] and [28] could be considered. The implementation was tried as a part
of the present research but the finer implementation specifics are not clearly known from [11]
and [28]. Thus this task is also being requested as a future work.
5.0.5 Scientific Contribution

• A novel orientation finding/ motion planning framework using the Trigonometric concept of
angle finding is implemented.
• Solving the motion primitives using ACADO toolkit as in [21] for the kinematic model of a
singly articulated truck using its kinematic model from [18]. It is significant because it is
used for a real size truck.
• A feature of adaptation that uses two different types of reverse controller one using motion
primitives and other using Astar path finding algorithm is implemented. This makes the
software framework an Adaptive Cyber Physical System.
• A state of the art problem and the nature of the research in using OSGI programming to
achieve a practical functionality, which is at the intersection of Embedded Systems and System
and Dynamics.

Autonomous Trucks
Appendix A
Lattice Time Bounded Astar
Lattice Time Bounded A star algorithm is a variant of Astar algorithm as discussed in [23] which
was planned to be taken into implementation. One of the major limitations of its adoption is the
type of truck and trailer used in [23]. It is important to note that the algorithm is made for a truck
with short trailer [23]. The suitability of this algorithm to a singly articulated truck and semitrailer
is a major impediment. However it is interesting to present it from a theoretical standpoint.
Figure A.1: Lattice Time Bounded Astar from [23]

Autonomous Trucks
Appendix B
Keywords

Autonomous Trucks
Term Description
OSGI Open Source Gateway Initiative, A software frame-

work based on Java.
ACADO Software environment for solving Optimal Control

Problems. It can be accessed through interfaces like
Visual Studio/C++ or through MATLAB environ-
ment.
PID Controller Proportional Integral Derivative Controller.
non-holonomic With reference to a vehicle, these constraints present

Constraint the motion directions that a vehicle cannot take.
UNITY Game Engine, Development Platform.
UDP User Datagram Protocol.
TCP Transmission Control Protocol.
ArUco Markers used for positioning using dedicated cam-

eras, typically in augmented reality applications.
IDE Integrated Development Environment.
IoT Internet of Things.
ASCII American Standard Code for Information Inter-

change.
CASADI Software environment for Non linear programming,

solving Optimal Control Problems.
IPOPT Interior Point Optimizer, a software library for large

scale non linear optimization.
Table B.1: List of Keywords

Autonomous Trucks
BIBLIOGRAPHY
December 5, 2019
References
[1] Jumbo distribution centre, image reference, weblink, http://www.skyclean.nl/en/
projects-references/jumbo-supermarkten, dated:23/10/2019.
[2] Trucking automation – key deployment scenarios, automated vehicles symposium 2017, https:
//higherlogicdownload.s3.amazonaws.com/AUVSI/14c12c18-fde1-4c1d-8548-035ad166c766/
UploadedImages/2017/PDFs/Proceedings/BOs/Bo6-0.pdf dated: 23/10/2019.
[3] Autonomous Vehicles Readiness Index 2019. https://assets.kpmg/content/dam/kpmg/xx/pdf/
2019/02/2019-autonomous-vehicles-readiness-index.pdf. October 2015, pages 5–6.
[4] Sandip Aine and P. B. Sujit. Integrating planning and control for efficient path planning in the
presence of environmental disturbances. Proceedings of the Twenty-Sixth International Conference
on Automated Planning and Scheduling (ICAPS 2016), page 3.
[5] Fahad Al-Dhief, Naseer Sabri, and Musatafa Albadr. Performance comparison between tcp and
udp protocols in different simulation scenarios. 12 2018.
[6] Yoko Watanabe Mathieu Rognant Michel Devy Alexandru Rusu, Sabine Moreno. State lattice
generation and nonholonomic path planning for a planetary exploration rover. 65 th International
Astronautical Congress.
[7] OSGI Architecture. https://www.osgi.org/developer/architecture/ dated 05/10/2019.
[8] Arash Arjmandi. Truck docking station simulation.
[9] Irfan Mashood Badshah. Master thesis report,automated docking of a scaled tractor semi-trailer.
[10] OSGI Benefits. web link https://www.osgi.org/developer/benefits-of-using-osgi/ dated
05/10/2019.
[11] Kristoffer Bergman, Oskar Ljungqvist, and Daniel Axehill. Improved optimization of motion
primitives for motion planning in state lattices, 01 2019.
[12] INTRALOG Defenition by HAN. https://www.han.nl/onderzoek/werkveld/projecten/
intralog-automotive-resea/ dated 27/11/2019.
[13] M. M. Archer C. L. Heitmeyer, S. Shukla and E. I. Leonard. On model-based software development.
pages 1–8.
[14] Kinematics Definition. https://en.wikipedia.org/wiki/Kinematics dated 23/11/2019.
[15] Vehicle Teleoperation Example. https://www.trucks.com/2019/06/26/
starsky-robotics-autonomous-truck-drive/ dated 02/12/2019.
[16] B. Gerrits. Multi-agent system design for automated docking of semi-trailers by means of
autonomous vehicles, April 2016, page 1.
[17] M.A.M. Hertogh. Development of a virtual environment and supervisory control for trucklab, 2018.
1
[18] Tony Hertogh. Automatic docking of articulated vehicles. Master’s Thesis, pages 5–6.
[19] Javier Ibanez-Guzman, Christian Laugier, John-David Yoder, and Sebastian Thrun. Autonomous
driving: Context and state-of-the-art. Handbook of Intelligent Vehicles (03/2012), pages 1271–
1310.
[20] Stephen W. Liddle. Book, model-driven software development. pages 1,5,6.
[21] O. Ljungqvist, N. Evestedt, M. Cirillo, D. Axehill, and O. Holmer. Lattice-based motion planning
for a general 2-trailer system. In 2017 IEEE Intelligent Vehicles Symposium (IV), pages 1–6, June
2017.
[22] M.F.J. Luijten. Lateral dynamic behaviour of articulated commercial vehicles. Master’s thesis,
Eindhoven, August, 2010, page 121.
[23] Sodertalje Sweden Marcello Cirillo, Scania Technical Centre. From videogames to autonomous
trucks: A new algorithm for lattice-based motion planning.
[24] Nikola Davidovic Vladimir Milosevic Mirjana Maksimovic, Vladimir Vujovic and Branko Perisic.
Raspberry pi as internet of things hardware: Performance and constraints. pages 6–7.
[25] Automotive NL Netherlands Automotive Roadmap. https://vereniging-ion.nl/sites/default/

files/files/Presentatie%20AutomotiveNL%2004-10-2016.pdf dated 23/11/2019. page 11.
[26] Netherlands office for Science and Special Report Technology. Smart logistics in the netherlands.
2018 Association for Computing Machinery, pages 5–6.
[27] Self Driving Trucks on Road Reference. https://www.cnbc.com/2019/09/10/

self-driving-trucks-are-being-tested-on-public-roads-in-virginia.html dated
02/12/2019.
[28] Daniel Axehill† Marcello Cirillo Oskar Ljungqvist, Niclas Evestedt and Henrik Pettersson. A path
planning and path-following control framework for a general 2-trailer with a car-like tractor. pages
21,38.
[29] Sweden Peter Fejes, Uppsala University. Estimation of steering wheel angle in heavy-duty trucks.
page 3.
[30] Amazon Self Driving Truck Reference. https://medium.com/@baumhedlund/
amazon-tests-self-driving-trucks-invests-in-tech-startup-a39ba986162b dated 29/11/2019.
[31] Astar Algorithm Reference. https://nl.mathworks.com/matlabcentral/fileexchange/
64978-a-star-serch-algorithm dated 20/04/2019.
[32] Cyber Physical System Introduction Reference. https://www.2b1stconsulting.com/
cyber-physical-systems-cps/dated 03/11/2019.
[33] Daimler Self Driving Truck Reference. https://www.trucks.com/2019/09/09/

daimler-starts-highway-test-autonomous-freightliner-truck/ dated 27/11/2019.
[34] Dock Assist System Reference. https://www.truckinginfo.com/159971/
driver-keeps-hands-off-as-eaton-system-docks-a-trailer news item date: 26/05/2017,
referred date: 23/11/2019.
[35] PID Reference. https://medium.com/@cacheop/pid-control-for-self-driving-1128b42ab2dd
dated 12/10/2019.
[36] Docking Skill Required. https://www.smart-trucking.com/setting-up-for-a-dock/ dated
24/11/2019.
[37] Norwegian University of Science Sandstad, Eivind and Trondheim Technology. Building intelligent
transport systems with reactive blocks and osgi. pages 6 to 15, 48.
2
[38] Netherlands Truck Driver Shortages. https://trans.info/en/
lack-of-drivers-in-the-netherlands-every-second-company-has-trouble-finding-workers-79697
dated 24/11/2019.
[39] Alexander Svae, Amir Taherkordi, Peter Herrmann, and Jan Blech. Self-adaptive control in cyber-
physical systems: the autonomous train experiment. 04 2017.
[40] Networked European Software White Paper and Services Initiative. Cyber physical systems,
opportunities and challenges for software, services, cloud and data. October 2015, pages 5–6.

Dissertation Final Report Santhosh

Uploaded by

Copyright:

Available Formats

You might also like

Dissertation Final Report Santhosh

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dissertation Final Report Santhosh

Uploaded by

Copyright:

Available Formats

Eindhoven University of Technology

Investigation of Model Based Adaptive

Graduation Supervisor/ Tutor:

Assessment Committee Members

Implementation is planned by enumerating a set of requirements needed to achieve the driving

Investigation of Model Based Adaptive Cyber Physical System for iii

Investigation of Model Based Adaptive Cyber Physical System for v

List of Tables xii

3 Design and Implementation 20

Investigation of Model Based Adaptive Cyber Physical System for vii

A Lattice Time Bounded Astar 53

viii Investigation of Model Based Adaptive Cyber Physical System for

1.1 Netherlands Road-map in the Automotive Industry [25] . . . . . . . . . . . . . . . . . 2

2.1 Truck Semitrailer example from [22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 OSGI services implementing the driving fuctionality . . . . . . . . . . . . . . . . . . . 21

4.1 Initial State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Investigation of Model Based Adaptive Cyber Physical System for ix

A.1 Lattice Time Bounded Astar from [23] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

x Investigation of Model Based Adaptive Cyber Physical System for

1 seudocode for Astar Algorithm23 2

Investigation of Model Based Adaptive Cyber Physical System for xi

5.1 Original Proposal and its Deviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

B.1 List of Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

xii Investigation of Model Based Adaptive Cyber Physical System for

Investigation of Model Based Adaptive Cyber Physical System for 1

Figure 1.1: Netherlands Road-map in the Automotive Industry [25]

Figure 1.2: Evolution of Vehcile Automation from [19]

2 Investigation of Model Based Adaptive Cyber Physical System for

Figure 1.3: Functional Architecture of a Vehicle Centric Architecture from [18]

Investigation of Model Based Adaptive Cyber Physical System for 3

4 Investigation of Model Based Adaptive Cyber Physical System for

Figure 1.5: Cyber Physical System from [32]

Investigation of Model Based Adaptive Cyber Physical System for 5

6 Investigation of Model Based Adaptive Cyber Physical System for

Investigation of Model Based Adaptive Cyber Physical System for 7

2.1 Problem Context

Figure 2.1: Truck Semitrailer example from [22]

Investigation of Model Based Adaptive Cyber Physical System for 9

Different from on road driving by the following account

10 Investigation of Model Based Adaptive Cyber Physical System for

2.2.1 Model Based Software Development

• Early identification of bugs [13].

Figure 2.4: Modelling Spectrum from [20]

Investigation of Model Based Adaptive Cyber Physical System for 11

Figure 2.5: Formal Model Based Development Steps from [13]

12 Investigation of Model Based Adaptive Cyber Physical System for

Figure 2.6: Layered Model OSGI Architecture from [37]

Investigation of Model Based Adaptive Cyber Physical System for 13

14 Investigation of Model Based Adaptive Cyber Physical System for

˙ = x˙0 + L0b ∗ sin(θ0 ) ∗ θ˙0

x˙1 = x˙0 + L0b ∗ sin(θ0 ) ∗ θ˙0 + L1f ∗ sin(θ1 ) ∗ θ˙1 (2.9)

y˙1 = y˙0 − L0b ∗ cos(θ0 ) ∗ θ˙0 − L1f ∗ cos(θ1 ) ∗ θ˙1 (2.10)

2.2.4 Motion Primitives

where p denotes the states [24].

Investigation of Model Based Adaptive Cyber Physical System for 15

16 Investigation of Model Based Adaptive Cyber Physical System for

Figure 2.8: UNITY Simulation Setup

2.2.6 ArUco Markers