Cloud Incubator Car : A Reliable Platform for Autonomous Driving

It appears clear that the future of road transport is going through enormous changes (intelligent transport systems), the main one being the Intelligent Vehicle (IV). Automated driving requires a huge research effort in multiple technological areas: sensing, control, and driving algorithms. We present a comprehensible and reliable platform for autonomous driving technology development as well as for testing purposes, developed in the Intelligent Vehicles Lab at the Technical University of Cartagena. We propose an open and modular architecture capable of easily integrating a wide variety of sensors and actuators which can be used for testing algorithms and control strategies. As a proof of concept, this paper presents a reliable and complete navigation application for a commercial vehicle (Renault Twizy). It comprises a complete perception system (2D LIDAR, 3D HD LIDAR, ToF cameras, Real-Time Kinematic (RTK) unit, Inertial Measurement Unit (IMU)), an automation of the driving elements of the vehicle (throttle, steering, brakes, and gearbox), a control system, and a decision-making system. Furthermore, two flexible and reliable algorithms are presented for carrying out global and local route planning on board autonomous vehicles.


Introduction
It appears clear that the road transport will be going through enormous changes in the near future (intelligent transport systems), although, presumably, gradual, in which new technologies will have a prevailing role [1].Thus, in the Horizon 2020 EU work program, smart, green, and integrated transport are placed as the main pillars for transport in the future.Among the program lines the following can be distinguished: "Safe and connected automation in road transport, where specific requirements are imposed on simple automation, limiting its foreseeable scope in the short term."Without a doubt the most disruptive technological challenge is focused on the so called autonomous vehicle and, the next step, autonomous cooperative vehicles [2].However, some issues need to be addressed: (1) the operation must be completely reliable and safe [3]: this specification is a highly demanding requirement, which usually complies with limiting the application of these vehicles to controlled scenarios, simple applications, or at reduced speeds of operation.Thus, it is understood that autonomous driving is viable in dedicated lanes or areas in situations of congestion or in parking manoeuvres, which is already a reality in many cases.Collision avoidance safety systems are more complex, especially those that take control of the vehicle in emergency manoeuvres; (2) the cost of sensors and control hardware must comply with what the market can assume, so that the mass production of vehicles can be economically affordable [4]; (3) much work is still necessary concerning legal and social issues, i.e., the question of liability where an automated vehicle is involved in an accident causing property damage or personal injury [5].
Regarding the above, it can be said that fully automated driving is not a technological utopia, but its practical implementation on the roads should be carefully analysed [6].Researchers and manufacturers advocate for automation in successive stages, firstly approaching longitudinal control, then simple side controls, to reach complete automation in scenarios of increasing complexity.In a few words, the change from conventional to assisted driving is now a reality, and the leap is being made towards automated driving in its different stages: partial, high, or fully automated.
Intelligent vehicles (IV) are one of the key elements within intelligent transport systems.When an IV has intelligence-understood as the fact that the control relies on the onboard vehicle processing systems, it can move autonomously.The onboard vehicle intelligence becomes aware of the situation of the vehicle in its environment and performs all the necessary control actions to proceed towards its destination.
Driving automation-considered a low-risk activity for humans-is a matter that needs the continuous evaluation of two main factors: (a) the current vehicle state (position, velocity, acceleration, direction) and (b) the environmental conditions (nearby vehicles, obstacles, pedestrians, etc.).To the extent that these two factors are accurately assessed, appropriate decisions can be taken towards reliable autonomous driving, and we will be closer to a vehicle-centric [6] approach to autonomous driving, where the main goal is the safe movement of the vehicle.
It is not an easy task to define what an IV with autonomous abilities is, although it is possible to describe its capacities, as detailed in Table 1 [7].

Capacity Means to Achieve That Capacity
Acquisition of information about the environment (at different distances) Onboard sensors (self-positioning, obstacle detection, driver monitoring) Network connection for long-distance information

Vehicular interconnection
Processing of environment information Onboard software for critical analysis Cloud processing for route planning, traffic control, etc.

Cognitive systems
Agent systems

Evolutionary algorithms
But, what exactly does autonomous driving mean?Following the policy defined by the NHTSA (National Highway Traffic Safety Administration, USA) [8], the International Society of Automotive Engineers (SAE) has set three categories of advanced driving automation, which imply the automation of both the driving actions (steering, throttle, and break) and the monitoring of the driving environment (see Table 2) [9].

Platforms for Autonomous Driving Development
The mass production of autonomous vehicles still has to wait because of different concerns, such as reliability, safety, cost, appearance, and social acceptance, to say just a few [10].Advances in the state-of-the-art of sensing and control software have allowed great improvements in the reliability and safe operation of autonomous vehicles in real-world conditions, in part thanks to a great variety of development platforms [7,[11][12][13].Table 3 shows the main features of some of the prominent ones.The latest approach to autonomous driving is the so-called cloud-based autonomous driving [14,15].These clouds provide essential services to support autonomous vehicles.Currently, these services include simulation tests for new algorithm deployment, offline deep learning model training, and High-Definition (HD) map generation.Autonomous driving clouds have infrastructures that include distributed computing, distributed storage, as well as heterogeneous computing.When driving algorithms and strategies are ready, they must be implemented in real control systems for adjusting and testing purposes before getting the car into real traffic conditions.Reliable control systems will be very useful for this purpose.This implies the interest of having a hardware-software development platform for control purposes that can be easily adapted to any car, thus allowing the autonomous driving system developers to concentrate exclusively on the sensory and algorithmic aspects of the prototypes.On the other hand, it is interesting to continue integrating new sensing techniques that allow a better and faster characterization of the environment, thus making possible to develop driving algorithms with a more precise behaviour.
The rest of the manuscript has been divided into three sections.Section 2 details the mechanical, electrical, and electronics modifications carried out to create the CICar platform.Section 3 shows the three components of high-level architecture proposed: a control system, a perception system, and a decision-making system.Furthermore, two novel algorithms are presented and used by the decision-making system for global and local path planning.Finally, Section 4 presents our conclusions.

Cloud Incubator Car Platform
As described above, autonomous driving technologies are making the transition from laboratories to the real world, and so must the vehicle platforms used to test and develop them.Research teams develop their own experimental platforms and also develop proprietary control systems.
In the Intelligent Vehicles Lab at the Technical University of Cartagena we have developed a comprehensible and reliable platform for autonomous driving technology development as well as for testing purposes: the CICar (Cloud Incubator Car, Figure 1a).This platform allows a complete experimentation of the aspects related to the integration of third-party sensors (laser range finders, global positioning systems, vision cameras, etc.), control of devices (motors, actuators, etc.), and industrial buses for communication.Software development has been made a comprehensible task by using a well-known hardware-software development platform for control purposes: RIO architecture and LabVIEW [16].
The aforementioned platform is based on an electric commercial vehicle-Renault Twizy-that has been conveniently modified in order to meet the specifications mentioned above.The modifications compound the low label architecture and include: (a) automation of driving elements (throttle, brake, steering, gearbox); (b) installation of external anchors capable of holding a wide variety of sensors; (c) installation of interior racks to accommodate the different control and processing systems (Figure 2b); (d) installation of electrical facilities and communication buses to feed and connect the different sensors and the control and processing hardware.

Modification of the Steering System
The modification of the steering system is a basic mechanical solution, as shown in Figure 1b, which consists of acting on the steering column or axis.A mechanical gear motor assembly is fixed to the steering column with gears, allowing the axis to turn.The original axis has not been modified, and this allows both steering control modes: automatic and manual.The mechanical implementation of the steering automation complies with the requirements of angular position range and precision, in addition to those of axis movement maximum speed (60 rpm).The steering system actuator is composed of an electronic driver EPOS2 and a motor from MAXON (EC60fl-GP52C-1024IMP-100W from Maxon Motor, Sachseln, Switzerland, acquired in Spain delegation).

Modification of the Braking System
The modification of the braking system, in the same way as that of the steering system, is not invasive of the original system.It has been implemented using a mechanical assembly with a motor comprising a gear coupled to a cam that presses the brake pedal by means of a short displacement of about 15 • with force control (see Figure 1c).The braking system actuator is composed of an electronic driver EPOS2 and a motor from MAXON (EC60fl-GP52C-1024IMP-100W from Maxon Motor, Sachseln, Switzerland, acquired in Spain delegation).

Throttle and Gearbox Modifications
We have devised an electronic solution for the throttle and gearbox automation.After scanning the control signals, it is possible that the electronic device, which is attached to the throttle pedal, exchanges data with the vehicle's ECU (Electronic Control Unit).In the same way, it is possible to select PDNR (P=Park, D=Driver, N=Neutral, R=Reverse) in the gearbox by means of the control system.We have developed a software module which emulates its operation through an analogue card.It works in parallel with the original system, so both manual and automatic throttle control are offered (see Figure 1d).
system.We have developed a software module which emulates its operation through an analogue card.It works in parallel with the original system, so both manual and automatic throttle control are offered (see Figure 1d).

Sensor Holders
We have installed on the CICar vehicle a varied set of supports capable of holding different types of sensors (cameras VIS, Time of Flight cameras, LIDAR 2D and 3D, IMU, GPS, etc.).For this, quick coupling devices have been used together with electrical connectors and secure communications.

Electrical and Communications Infrastructure
New electrical facilities have been installed that allow the electrical supply of both the sensors and the control and processing systems.The communication infrastructure is composed of: (1) A serial Controller Area Network (CAN bus), because of its suitability for high-speed applications using short messages, its robustness, and reliability [17].(2) A gigabyte Ethernet Network which allows the implementation of TCP and UDP protocols.
They are used by the 2D [18] and 3D LIDAR [19], respectively.(3) A point-to-point set communications, such as RS232 and USB.
Figure 2a shows all the components which compound the low-level architecture.

Sensor Holders
We have installed on the CICar vehicle a varied set of supports capable of holding different types of sensors (cameras VIS, Time of Flight cameras, LIDAR 2D and 3D, IMU, GPS, etc.).For this, quick coupling devices have been used together with electrical connectors and secure communications.

Electrical and Communications Infrastructure
New electrical facilities have been installed that allow the electrical supply of both the sensors and the control and processing systems.The communication infrastructure is composed of: (1) A serial Controller Area Network (CAN bus), because of its suitability for high-speed applications using short messages, its robustness, and reliability [17].(2) A gigabyte Ethernet Network which allows the implementation of TCP and UDP protocols.
They are used by the 2D [18] and 3D LIDAR [19], respectively.(3) A point-to-point set communications, such as RS232 and USB.

High-Level CICar Architecture
From a higher abstraction layer point of view, the architecture of the CICar is divided into: (1) a control system, (2) a perception system, and (3) a decision-making system.Figure 3 shows the distribution of the high-level architecture components of the CICar.

Control System
The goal of the control system is to translate the actions generated by the decision-making system into actuations of the elements which govern the vehicle.The control system has been implemented with a compactRIO 9082 (from National Instruments).The compactRIO processing unit is composed of two processors: an INTEL i7 and a Xilinx FPGA, which confer high performance capacities and flexibility for the testing and implementation of algorithms in the control system.The compactRIO allows soft and hard real-time processes to be run.The INTEL processor allows less critical processes to be executed, while FPGA allows time-critical processes to be executed with higher clock frequencies.The control system is governed by a Real-Time Operating System

High-Level CICar Architecture
From a higher abstraction layer point of view, the architecture of the CICar is divided into: (1) a control system, (2) a perception system, and (3) a decision-making system.Figure 3 shows the distribution of the high-level architecture components of the CICar.

High-Level CICar Architecture
From a higher abstraction layer point of view, the architecture of the CICar is divided into: (1) a control system, (2) a perception system, and (3) a decision-making system.Figure 3 shows the distribution of the high-level architecture components of the CICar.

Control System
The goal of the control system is to translate the actions generated by the decision-making system into actuations of the elements which govern the vehicle.The control system has been implemented with a compactRIO 9082 (from National Instruments).The compactRIO processing unit is composed of two processors: an INTEL i7 and a Xilinx FPGA, which confer high performance capacities and flexibility for the testing and implementation of algorithms in the control system.The compactRIO allows soft and hard real-time processes to be run.The INTEL processor allows less critical processes to be executed, while FPGA allows time-critical processes to be executed with higher clock frequencies.The control system is governed by a Real-Time Operating System

Control System
The goal of the control system is to translate the actions generated by the decision-making system into actuations of the elements which govern the vehicle.The control system has been implemented with a compactRIO 9082 (from National Instruments).The compactRIO processing unit is composed of two processors: an INTEL i7 and a Xilinx FPGA, which confer high performance capacities and flexibility for the testing and implementation of algorithms in the control system.
The compactRIO allows soft and hard real-time processes to be run.The INTEL processor allows less critical processes to be executed, while FPGA allows time-critical processes to be executed with higher clock frequencies.The control system is governed by a Real-Time Operating System (VxWorks from WindRiver).The kernel of the CICar is designed with Finite State Machines implemented in C++ through the QS framework [20].

Perception System
The perception system is divided into two subsystems: short-(SRS) and long-range (LRS).The perception system forms two concentric rings overlapping around the vehicle (Figure 4).The SRS allows objects to be detected up to 10 m from the front and the rear of the vehicle (2D LIDARs) and around 3 m from the right and left side of the vehicle (ToF cameras).ToF cameras are a seldom used technology in autonomous vehicles but they result to be a very attractive solution for the vehicle for short-range detection.ToFs allow 3D object detection with a high frame rate, are less affected by light conditions and shadows, and have an acceptable cost [21,22].The objects that enter into the short-range ring suppose an inherent risk and danger for the actions of the CICar.For this reason, the sensors involved in the SRS are commanded by the RT processing unit.On the other hand, the LRS perception is based on a 3D High-Definition LIDAR (HDL64SE from Velodyne) [19].Its 64 laser beams turn at 800 rpm and can detect objects up to 100 m away with an accuracy of 2 cm.The 3D LIDAR allows trajectories to be established (lane change, obstacle avoidance, speed reduction depending on the traffic conditions, etc.), object tracking, object classification, and behaviour prediction of other drivers.The information from the two subsystems is fused and processed to detect obstacles such as: cars, bikes, pedestrians, traffic lights, and so on.A colour camera is placed on the roof of the vehicle and is used to detect the road, lanes, road lines, and traffic signs.The CICar has a localization system based on an RTK unit (Real-Time Kinematic), an IMU (Inertial Measurement Unit), and a relative position encoder installed on the wheel of the vehicle.RTK satellite navigation consists of a technique used to enhance the precision of the position data derived from satellite-based positioning systems (global navigation satellite systems, GNSS) such as GPS, GLONASS, Galileo, and BeiDou.The RTK is composed of a base station and a mobile unit (or rover) and it supplies an accuracy from 20 cm to 1 cm.The localization system cancels out the RTK positioning when the number of satellites detected is less than or equal to four or when the HDOP (Horizontal Dilution of Precision) is greater than five [23,24].In these cases, the IMU and the positioning encoder installed on the vehicle are used for the localisation task.Table 4 presents a summary of the onboard sensors in the CICar.

Decision-Making System
To operate reliably in the real world, an autonomous vehicle must evaluate and make decisions about the consequences of its possible actions, anticipating the intentions of other traffic participants.The new Intelligent Decision-Making Systems are based on cognitive systems [25], agent systems [26], fuzzy systems [27], neural networks [28], evolutionary algorithms [29], multi-criteria [30] or rule-based methods [31].The main element of the CICar is a Decision-Making System which incorporates a new local trajectory planner [32] based on Bezier curves [33].

Path-Planning System (PPS)
The main task of the PPS is to establish a global route for short or medium distance from the initial position of the vehicle until the goal.The PPS is composed of a global planner (Figure 5) and a local planner (Figure 6).

Global Planner
Global planners are a key element in autonomous navigation systems.The development of intelligent transport systems and autonomous vehicles has increased the demand for route planners that allow dynamic route generation, capable of adapting to the varying aspects of the road, such as traffic, roadworks, roads that have been cut off, or unexpected events.The initial requirements for the CICar global planner are listed below: (1) It must be able to create global routes using digital map sources (2) It should allow an easy introduction of traffic restrictions or unplanned events.
(3) It should be executed in an agile manner and produce results in an acceptable time.
For the map source used for the global route planning, Google maps was selected, the reasons for this being: (1) It has an easily accessible Application Programming Interface (API) and is multiplatform.
(2) The maps can be downloaded with different layers of information.
(3) It allows georeferencing of the map points.(4) It is constantly updated and is available for free.The first algorithm evaluated for global route generation was the A* Algorithm [34,35].The following disadvantage was reported with the use of the A* algorithm: the algorithm was not capable of generating routes in a reasonable time using the 512 × 512 resolution binary maps tested.To increase the performance, the size of the binary maps was reduced by a constant factor (2, 3, or 4).The size reduction of the binary map speeded up the calculation time, but, because of the pixelisation effects, the following problems occurred: (1) the destruction of narrow roads, (2) the deterioration of main roads, and, as a result, (3) the routes generated were not smooth and were very abrupt.
As a solution to the problems reported, a new heuristic search algorithm for global route planning, called SCP (Search for Cross Points for obtaining global routes), was developed.
The SCP algorithm is based on a binary map of nxm pixels where the navigable routes are given a value of "1" and the non-navigable areas a value of "0", and an initial point p 0 , a goal point p g , and an initial angle θ 0 are set.
The stages performed by the SCP algorithm to obtain the global route are: 1.
A search direction is chosen ('N'-North, 'S'-South, 'E'-East, 'W'-West) according to the position of the angle between the positions p g and p 0 .Equation ( 1) shows how the search directions are obtained by the algorithm in function of the angle θ 0g Appl.Sci.2018, 8, x FOR PEER REVIEW 9 of 20 of generating routes in a reasonable time using the 512 × 512 resolution binary maps tested.To increase the performance, the size of the binary maps was reduced by a constant factor (2, 3, or 4).The size reduction of the binary map speeded up the calculation time, but, because of the pixelisation effects, the following problems occurred: (1) the destruction of narrow roads, (2) the deterioration of main roads, and, as a result, (3) the routes generated were not smooth and were very abrupt.As a solution to the problems reported, a new heuristic search algorithm for global route planning, called SCP (Search for Cross Points for obtaining global routes), was developed.
The SCP algorithm is based on a binary map of nxm pixels where the navigable routes are given a value of "1" and the non-navigable areas a value of "0", and an initial point p0, a goal point pg, and an initial angle θ0 are set.
The stages performed by the SCP algorithm to obtain the global route are: 1.A search direction is chosen ('N'-North, 'S'-South, 'E'-East, 'W'-West) according to the position of the angle between the positions pg and p0.Equation ( 1 2. A clear path is chosen from p0 to the goal pg.A route is considered clear if all the points that form the line that joins p0 and pg have a value equal to '1′.
2.1 If the path is not free: a.The SCP algorithm searches for the first pair of cross points [CPi; CPi+1] according to the search direction set as shown in Equation (1).To achieve this, the algorithm goes through the map, starting from p0 according to an angle θ1, until it finds a value equal to '0′.The point found is labelled as the first cross point CPi.Starting from CPi, and according to the search angle θ2, the algorithm searches for the next point with a value of '0′.This new point is labelled as the second cross point CPi+1.The angles θ1, θ2 are calculated according to the search direction and the following table.
During the search for the cross points [CPi; CPi+1], the candidate points pi(xi,yi) are calculated by alternating the values of θ = θ1 and θ = θ2, based on Equation ( 2): (2) with (xi−1, yi−1) being the previous value calculated, and d a constant that allows the CPi search to advance more quickly.
b.The Euclidean distance between two consecutive cross points CPi and CPi+1 is calculated. i.
If the distance is 0, the search direction is changed by evaluating the position of pg with respect to the last CPi+1 that was calculated, p0 is set to p0 = CPi+1, and the algorithm goes to step 2. ii.
If the distance is not equal to 0, p0 is set to p0 = CPi+1, and the algorithm goes to step 2. A clear path is chosen from p 0 to the goal p g .A route is considered clear if all the points that form the line that joins p 0 and p g have a value equal to '1'.

2.1
If the path is not free: a.
The SCP algorithm searches for the first pair of cross points [CP i ; CP i+1 ] according to the search direction set as shown in Equation (1).To achieve this, the algorithm goes through the map, starting from p 0 according to an angle θ 1 , until it finds a value equal to '0'.The point found is labelled as the first cross point CP i .Starting from CP i , and according to the search angle θ 2 , the algorithm searches for the next point with a value of '0'.This new point is labelled as the second cross point CP i+1 .The angles θ 1 , θ 2 are calculated according to the search direction and the following table.
During the search for the cross points [CP i ; CP i+1 ], the candidate points p i (x i , y i ) are calculated by alternating the values of θ = θ 1 and θ = θ 2, based on Equation (2): with (x i−1 , y i−1 ) being the previous value calculated, and d a constant that allows the CP i search to advance more quickly.b.
The Euclidean distance between two consecutive cross points CP i and CP i+1 is calculated. i.
If the distance is 0, the search direction is changed by evaluating the position of p g with respect to the last CP i+1 that was calculated, p 0 is set to p 0 = CP i+1 , and the algorithm goes to step 2.
ii.If the distance is not equal to 0, p 0 is set to p 0 = CP i+1, and the algorithm goes to step 2.

2.1
If there is a clear route, the algorithm finishes, and the path is composed of the points [p 0 ,pm 1 , . . .,pm n−1 ;p g ], with pm 1 , . . .,pm n−1 being the midpoints obtained from the pairs of points from the cross-point vector [p 0 ,CP 1 ,CP 2 , . . .,CP n ;p g ].
Figure 5 shows a binary map in the form of a square which will demonstrate the SCP algorithm in operation.Figure 5a shows how the SCP algorithm generates the cross points in the direction 'N', given the information (p 0 , p g , θ 0 ).In the example with θ 0 = 60 • and Table 5, the angles θ 1 y θ 2 are −120 • and −60 • respectively.Figure 5 shows a binary map in the form of a square which will demonstrate the SCP algorithm in operation.Figure 5a shows how the SCP algorithm generates the cross points in the direction 'N', given the information (p0, pg, θ0).In the example with θ0 = 60° and Table 4, the angles θ1 y θ2 are −120° and −60° respectively.
As shown in Figure 5a, the cross points CP i are generated in a zigzag in the direction 'N' until a direct path to the destination is found.Figure 5b shows the route generated between the midpoints of the segments from the set [p 0 CP 1 ; CP 1 CP 2 ; CP 2 CP 3 ; CP 3 CP 4 ; CP 4 p g ].In Figure 5c, a more complex scenario with a different p g is shown.In this case, when the SCP algorithm reaches CP 5 , an end of route occurs when it no longer follows the 'N' direction.At this point, the Euclidean distance between CP 4 and CP 5 is 0, and the algorithm changes the search direction from 'N' to 'E', with θ 1 = 60 • and θ 2 = −60 • .With the change of direction, it is possible to calculate a new CP 5 .Figure 5d shows the route generated between the midpoints of the segments from the set [p 0 CP 1 , . . ., CP 14 p g ].
The SCP algorithm can increase the number of routes calculated with a greater number of initial starting angles.Figure 6a shows a real map of the Technical University of Cartagena where an initial point p 0 and a final point p g (blue and red crosses) have been selected.
The SCP algorithm has been executed with initial angles θ 0 from 20 to 80 degrees, with 2-degree increments.After its execution, the SCP has calculated three possible trajectories.Figure 6b shows the cross points found, and Figure 6c the trajectories created from the set of midpoints from the three calculated trajectories.Figure 6d shows the optimal path calculated as the shortest between points p 0 and p g .
The optimal path is partitioned in waypoints (WP 0 , . . ., WP i , . . ., WP n ).The waypoints will be used by the CICar to establish short missions between them using the local planner module.The CICar location is provided by a DGPS unit on board the vehicle.scenario with a different pg is shown.In this case, when the SCP algorithm reaches CP5, an end of route occurs when it no longer follows the 'N' direction.At this point, the Euclidean distance between CP4 and CP5 is 0, and the algorithm changes the search direction from 'N' to 'E', with θ1 = 60° and θ2 = −60°.With the change of direction, it is possible to calculate a new CP5. Figure 5d shows the route generated between the midpoints of the segments from the set [p0CP1,…, CP14pg].
The SCP algorithm can increase the number of routes calculated with a greater number of initial starting angles.Figure 6a shows a real map of the Technical University of Cartagena where an initial point p0 and a final point pg (blue and red crosses) have been selected.
The SCP algorithm has been executed with initial angles θ0 from 20 to 80 degrees, with 2-degree increments.After its execution, the SCP has calculated three possible trajectories.Figure 6b shows the cross points found, and Figure 6c the trajectories created from the set of midpoints from the three calculated trajectories.Figure 6d shows the optimal path calculated as the shortest between points p0 and pg.
The optimal path is partitioned in waypoints (WP0,…, WPi,…, WPn).The waypoints will be used by the CICar to establish short missions between them using the local planner module.The CICar location is provided by a DGPS unit on board the vehicle.

Local Planner
The local planner uses a pair of waypoints (WPi, WPi+1) supplied by the global planner to generate a set of possible trajectories to reach WPi+1 from WPi (see Figure 7).
For that, the perception system supplies a local map of up to 100 meters around the vehicle (Figure 8a), which is completed with three constraint types: (a) the constraints that the vehicle detects on the way by means of the perception system (vehicles, pedestrian, bikes, curbs, and so on), (b) the limitations inherent in the vehicle characteristics (wide, high, kinematic model), c) the constraints derived from the traffic rules (one way, bidirectional way, traffic signs, etc.).To decrease the number of computations and to increase the performance, the perception system supplies a set of keypoints which are a representation of the surroundings of the vehicle.The keypoint set is obtained after applying a filtering process composed of two stages: 1. Distance filter.All XYZ points beyond a maximum distance (dmax) will be rejected.2. High filter.All Z points higher than a maximum value (Zmax) will be discarded.
As shown in Figure 8b, we have simplified the initial XYZ local map to obtain a compact profile of the XYZ representation of the objects in the scene.

Local Planner
The local planner uses a pair of waypoints (WP i , WP i+1 ) supplied by the global planner to generate a set of possible trajectories to reach WP i+1 from WP i (see Figure 7).
For that, the perception system supplies a local map of up to 100 m around the vehicle (Figure 8a), which is completed with three constraint types: (a) the constraints that the vehicle detects on the way by means of the perception system (vehicles, pedestrian, bikes, curbs, and so on), (b) the limitations inherent in the vehicle characteristics (wide, high, kinematic model), c) the constraints derived from the traffic rules (one way, bidirectional way, traffic signs, etc.).To decrease the number of computations and to increase the performance, the perception system supplies a set of keypoints which are a representation of the surroundings of the vehicle.The keypoint set is obtained after applying a filtering process composed of two stages: 1.
Distance filter.All XYZ points beyond a maximum distance (d max ) will be rejected.2.
High filter.All Z points higher than a maximum value (Z max ) will be discarded.
As shown in Figure 8b, we have simplified the initial XYZ local map to obtain a compact profile of the XYZ representation of the objects in the scene.After this, the corners of the objects in the scene are computed using the Harris algorithm [36].The Harris algorithm is applied over an ROI (Region of Interest) in the forward direction of the vehicle.Figure 9 shows the results of corner detection in the ROI of two scenarios extracted from  After this, the corners of the objects in the scene are computed using the Harris algorithm [36].The Harris algorithm is applied over an ROI (Region of Interest) in the forward direction of the vehicle.Figure 9 shows the results of corner detection in the ROI of two scenarios extracted from  After this, the corners of the objects in the scene are computed using the Harris algorithm [36].The Harris algorithm is applied over an ROI (Region of Interest) in the forward direction of the vehicle.Figure 9 shows the results of corner detection in the ROI of two scenarios extracted from Figure 9b.This group of points calculated by the Harris algorithm are called keypoints (KP i ) and will be used in the next stage of the PPS to create a set of trajectories.In Figure 9, green crosses represent the keypoint set, a triangle with a 2 metre base represents the vehicle, a rectangle shows the ROI where the Harris detector is computed, and two red circles represent the origin and goal locations (WPi, WPi+1).
The trajectory generator module receives two waypoints (WPi, WPi+1) and a set of keypoints {KP0,…,KPk} representative of the environment around the vehicle for computing a set of trajectories between a pair of waypoints.The module uses the Bezier curves to generate possible trajectories between the waypoints, using the keypoints as control points.
A Bezier curve of grade n can be generalized by the Equation (3) [33]: For example, the second-grade curve (n = 2) is (see Equation ( 4)): Being P0, P1, and P2 the control points, and t a real value between 0 and 1.A higher step of t allows a higher number of points to be obtained in the Bezier curve generation B(t).
The trajectory generator module implements a set of second-grade Bezier curves displaced along the X-axis control point P1.The development algorithm is shown in Algorithm box, where nCurves indicates the number of trajectory candidates which have been calculated.However, only one set will pass the security distance constraints and will be adopted as the trajectory (Ti[]).For each of them, a new control point P1 is defined, one half to the left of the midpoint between P0 and P2, and the other half to the right.In Figure 9, line 1.2., a control point displacement increment equal to 3.0 is defined.fB is a function that generates a second-grade Bezier curve between P0 and P2.The function fP1 searches for the Pi point with the lowest Euclidean distance to set the Bezier points of B(t).
After a set of trajectories is obtained Ti = {B(t)0,..., B(t)m}, the optimal trajectory can be established under different criteria depending on the conditions in each moment during autonomous driving.In this work, we have implemented three criteria to select the optimal trajectory: (a) the minimum distance travelled, (b) the maximum angle travelled, and (c) the medium trajectory.In Figure 9, green crosses represent the keypoint set, a triangle with a 2 metre base represents the vehicle, a rectangle shows the ROI where the Harris detector is computed, and two red circles represent the origin and goal locations (WP i , WP i+1 ).
The trajectory generator module receives two waypoints (WP i , WP i+1 ) and a set of keypoints {KP 0 , . . .,KP k } representative of the environment around the vehicle for computing a set of trajectories between a pair of waypoints.The module uses the Bezier curves to generate possible trajectories between the waypoints, using the keypoints as control points.
A Bezier curve of grade n can be generalized by the Equation (3) [33]: For example, the second-grade curve (n = 2) is (see Equation ( 4)): Being P 0 , P 1, and P 2 the control points, and t a real value between 0 and 1.A higher step of t allows a higher number of points to be obtained in the Bezier curve generation B(t).
The trajectory generator module implements a set of second-grade Bezier curves displaced along the X-axis control point P1.The development algorithm is shown in Algorithm 1, where nCurves indicates the number of trajectory candidates which have been calculated.However, only one set will pass the security distance constraints and will be adopted as the trajectory (Ti[]).For each of them, a new control point P1 is defined, one half to the left of the midpoint between P0 and P2, and the other half to the right.In Figure 9, line 1.2., a control point displacement increment equal to 3.0 is defined.fB is a function that generates a second-grade Bezier curve between P0 and P2.The function fP1 searches for the Pi point with the lowest Euclidean distance to set the Bezier points of B(t). Figure 11 shows the behaviours of the trajectory generator when other criteria and parameters of the algorithm are chosen.In Figure 11a and Figure 11b, the maximum angle criteria and medium trajectory criteria have been selected from scenario 1, respectively.It is possible to observe that the change in the selection criteria affect the smoothness of the trajectory.In Figure 11c,d, the number of possible trajectories was set to 25.With this change in criteria, the trajectory generator cannot avoid the obstacle and cannot supply any solution in this scenario (see Figure 8c).Nevertheless, a decrement of the safety distance to 0.5 m allows four reliable trajectories to be generated (see Figure 11d).Figure 11 shows the behaviours of the trajectory generator when other criteria and parameters of the algorithm are chosen.In Figure 11a,b, the maximum angle criteria and medium trajectory criteria have been selected from scenario 1, respectively.It is possible to observe that the change in the selection criteria affect the smoothness of the trajectory.In Figure 11c,d, the number of possible trajectories was set to 25.With this change in criteria, the trajectory generator cannot avoid the obstacle and cannot supply any solution in this scenario (see Figure 8c).Nevertheless, a decrement of the safety distance to 0.5 m allows four reliable trajectories to be generated (see Figure 11d).Unlike other platforms presented, which use proprietary control systems, in the Intelligent Vehicles Lab we propose an approach based on well-known hardware-software development platforms for control purposes: RIO architecture and LabVIEW.This means that the current software development approach for self-driving can be easily transferred to control actions on any vehicle equipped with the general purpose control hardware proposed for the CICar.
The sensing infrastructure includes ToF cameras for lateral surveillance.This sensing technology offers advantages compared with the current 2D LIDAR, since a better characterization of the scene is possible, thus offering better capabilities such as: 3D object detection with a high frame rate, lower influence of the light conditions and shadows, and acceptable cost.
As a proof of concept, this paper shows a case study where the implementation of a PPS (path-planning system) on the CICar platform is presented.The implemented PPS uses a map to establish a global route and a local planner to solve the usual traffic issues.The global planer has been resolved by means of the development of a new heuristic algorithm based on a search for cross points (SCP) using binary maps.The SCP algorithm has improved the flexibility, the computing time, and the performance in global route computation.Furthermore, a local planner has also been presented in this work, which implements a trajectory generator based on Bezier curves, which supplies high flexibility during the resolution of unforeseen situations.The trajectory generator allows the setting of: (a) the number of possible trajectories to generate; (b) a safety distance; (c) a criterion to select the optimal trajectory.The CICar autonomous vehicle offers a comprehensible and reliable platform for autonomous driving technology development and testing, which greatly facilitates the development of technology for autonomous driving.
Concerning the PPS, we currently continue to work towards increasing the intelligence to implement it on board the vehicle.We focus our developments on: (a) the improvement of the evaluation criteria for the optimal trajectory; (b) the dynamic modification of the ROI, depending on external driving factors; (c) the incorporation of machine learning technology for the classification of the objects detected by the perception systems.

Figure
Figure2ashows all the components which compound the low-level architecture.

Figure 2 .
Figure 2. (a) Low-level architecture; (b) rack to host the control and decision making systems.

Figure 3 .
Figure 3. Distribution of the high-level architecture components of the CICar.

Figure 2 .
Figure 2. (a) Low-level architecture; (b) rack to host the control and decision making systems.

Figure 2 .
Figure 2. (a) Low-level architecture; (b) rack to host the control and decision making systems.

Figure 3 .
Figure 3. Distribution of the high-level architecture components of the CICar.

Figure 3 .
Figure 3. Distribution of the high-level architecture components of the CICar.

Figure 4 .
Figure 4. (a) CICar 3D model with reference frames; (b,c) plant and side views of the perception system ranges and components.

Figure 5 .Table 4 .Figure 5 .
Figure 5. Example of the Search for Cross Points (SCP) working between p0 and pg with initial angle θ0 = 60°.(a) Scenario without change of direction; (b) Obtained trajectory in scenario without change of direction; (c) Scenario with change of direction; (d) Obtained trajectory in scenario with change of direction.

Figure 6 .
Figure 6.SCP applied on a real map.(a) Selection of the initial point on the real map; (b) cross points found on a binary map; (c) possible trajectories on a binary map; (d) optimum trajectory on the real map.

Figure 6 .
Figure 6.SCP applied on a real map.(a) Selection of the initial point on the real map; (b) cross points found on a binary map; (c) possible trajectories on a binary map; (d) optimum trajectory on the real map.

20 Figure 9b .Figure 9 .
Figure 9b.This group of points calculated by the Harris algorithm are called keypoints (KPi) and will be used in the next stage of the PPS to create a set of trajectories.

Table 2 .
Three categories of advanced driving automation.

Table 3 .
Some platforms for autonomous driving development.

Table 4 .
Sensors features of the perception system.
) shows how the search directions are obtained by the algorithm in function of the angle .