Project Topics
Get Complete Project Material File(s) Now! »
Chapter 3 Experimental Platform Design and Development
The simulation results show that the model-free event-triggered trajectory tracking control algorithm works well. But experimental validation on a physical platform is necessary to make sure that the proposed method works in practice.
A previously developed Unmanned Ground Vehicle (UGV) platform was studied in an effort to validate the simulation results in experimentation. The vehicle platform considered is approximately 1/10th the size of a standard car. This platform was originally designed and developed by Samuel Mitchell and Daniel Dunn. But I and Kevin Kawecki have made few major changes to this system according to the requirements of this research. This chapter mainly focuses on the design of two major segments of an experimental platform, which are hardware and software.
The following sections talk about the hardware and software of the vehicle platform, and the major changes made to the already existing system.
Hardware
The vehicle studied and used for experimental validation was purchased from Battlekits [1]. It is capable of moving at speeds of up to 10m/s which satisfies the requirement of the platform being analogous to a standard highway vehicle. Also, the vehicle is collision tolerant which makes experimentation more feasible. Using this kind of a scaled vehicle rather than a full-scale one will be cost effective keeping in mind the collisions that might happen while testing.
More details about the hardware are discussed in Appendix A
Software
Robot Operating System (ROS)
Robot Operating System (ROS) is a collection of software frameworks for the development of software on robots [44]. It is a middle-ware usually written in Python/C++ which al-lows the passing of messages between tasks (nodes), flexibility in hardware and scheduled implementation of tasks. It was chosen for this work because of its open-source nature, huge community support, flexibility, and simple interface. The software system structure implemented in ROS is shown in Figure 3.2.
Initially, the software system used to operate on a low-cost, community-supported devel-opment platform called BeagleBone Black with the Ubuntu distribution of Linux. It had an AM335x 1GHz ARM Cortex-A8 processor. But recently, the development platform was changed to UP-Board with 1.92GHz Intel ATOM x5-Z8350 processor on which the system currently operates, the main reason for this change is the better processing speed of the UP-board. The UP-board also has an on-board Graphics Processing Unit (GPU) which can come handy when performing image processing in the future, for example, to detect lanes and objects.
Nodes/Tasks
Inside ROS various tasks like reading and processing data from a sensor, using sensor data in the control algorithm to calculate required control input, writing PWM signals to actuators are done in the form of Python/C++ scripts called as nodes. This sub-section describes tasks performed in various nodes of the software system. This collection of tasks to execute on the vehicle are placed in a package called sats_car_ros. Links called as topics are used to send information from one node to another in the form of messages so that their respective tasks can be performed.
Controller Node The controller node executes the code for both the high-level trajec-tory tracking controller and the low-level PID controller. It accepts information about the vehicle’s position and speed in x,y-directions which are required by the high-level controller to calculate the desired left and right wheel speeds. This node also needs information about the preceding vehicle’s position and speed in the case of platooning. In addition, it takes in the current wheel speeds and uses them together with the desired wheel speeds produced by the high-level controller to implement the low-level PID controller which calculates the required PWM output. The PWM duty-cycle value is read by the motors from files to which the controller node writes the calculated PWM value.
Detailed information about the implemented high-level and low-level controllers is in Chapter 2. The controller node gathers all the information required by the high-level and low-level controllers from the Sensor node and GPS node. In the case of platooning, the lead vehicle follows a GPS path which is predefined while all the other vehicles follow a reference path generated by their respective preceding vehicles as will be discussed in Chapter 5.
Sensor Node The sensor node reads information from the sensor hub (Tiva C), verifies and processes the received information, and publishes it onto various topics to which the controller node subscribes. The sensor hub (Tiva C) receives information from the Quadra-ture Encoders which measure the wheel velocities and for use in the platooning case, the Lidar-Lite units which measure relative distance and speed between vehicles.
Each message from the sensor hub has three sections: start code 1Byte, sensor data 24Bytes, and CRC 2Bytes. The checksum is calculated on the first 25Bytes using the CRC-CCITT method.
When a proper message which satisfies the checksum is received by the sensor node, it processes the data and publishes it onto a topic in the form of a formatted message. The controller node subscribes to this topic to receive some of the required measurements. When an erroneous message is received by the sensor node, it is discarded.
GPS Node This node provides information about the vehicle’s GPS coordinates and speed in x,y-directions to the controller node. It accesses and processes data from the GPS module through USB. The package which implements this node was taken directly from the internet [3], which is one of the major advantages of ROS. ROS packages for almost any robotic ap-plication can be found online. The package used basically parses NMEA [4] strings produced by the GPS module and publishes a very simple GPS message.
Safety
The controller node on the vehicle subscribes to a common topic called ”/master”. This topic contains a bool type variable using which the PWM values can be forced to a value that results in switching off the motors and stopping of the vehicle even though the desired PWM values are being calculated by the controller.
In order to safely stop the vehicle when ROS execution is halted, the PWM values are set to stationary by making use of a ROS functionality which enables to run commands when exiting a node. This also provides safety when the controller node encounters an error and exits but the motors maintain their most recent speeds.
An emergency shutdown function was also implemented using XBee modules which can come handy when the wireless connection is weak/lost and the vehicle continues to operate without commands from the command station.
Command Station
A command station which is a MacBook Pro running Ubuntu distribution of Linux oper-ates the vehicle through a wireless connection. The vehicle and the command station are connected to an ASUS router wirelessly. The command station is also used to obtain and visualize data from the vehicle.
The vehicle receives configuration commands from the base (command station), which ini-tialize the ROS nodes on the vehicle. Once the nodes are initialized, the vehicle performs all the required calculations on its board. In case of emergency, the base station can send user commands to stop the vehicle from moving as described in Subsection 3.2.3.
Wi-Fi Router
An ASUS AC1900 Dual Band 802.11ac Gigabit wireless adapter is used as the Wi-Fi access point which can operate at both 2.4 GHz and 5 GHz. The 5 GHz operating frequency was chosen in this work because of its faster data rates at shorter distances compared to 2.4 GHz. It has three detachable 9 dB antennas which expand the network’s range and deliver signal to required areas. Signal strengths of up to 92% could be obtained at a distance of 10m using this wireless adapter at 5 GHz. And no internet is needed while configuring the vehicle from the command station using this access point.
Miscellaneous
Earlier, the electronics power system and the motor electrical system used to be powered by the same set of batteries and so were not isolated from each other, which made the Beaglebone shut down when the motors drew a large amount of current or when the battery voltage was low. A new Printed Circuit Board (PCB) was designed by Kevin Kawecki for the UP-board in which the systems are powered by their own set of batteries making them isolated and avoiding the shutdown issue.
The ROS package sats_car_ros has a collection of tasks/nodes required to operate the vehicle and provides a simple interface. The rqt framework in ROS can be used to visualize real-time control and sensor data from the vehicle on the command station.
With all the required hardware and software components to implement the trajectory track-ing control algorithm, this experimental platform allows the testing of the simulations in Chapter 2.
Experimental Validation
A testing platform of scaled autonomous vehicle as discussed in Chapter 3 was developed to validate the simulation results experimentally. Providing a means of testing the theoretical findings on a physical system is the purpose of this platform. As mentioned in Chapter 2, the vehicle is similar to a differential drive system driven by DC motors and can reach speeds of up to 10m/s. The wheel velocities were determined using Quadrature encoders. The vehicle had an onboard micro-controller to implement the control algorithm.
A split-controller structure was used where the trajectory tracking controller in the form of a high-level controller commands desired speeds for left and right wheels while a low-level (PID) controller converts these desired speeds into PWM duty cycles to write to the motor controller so that the commanded speeds can be tracked. The vehicle obtains its precise position and speed in each direction using an onboard RTK-GNSS module which employs the RTK positioning technique. The idea is to validate the control algorithm on a single vehicle first and then move on to platooning like in the case of simulations.
Single Vehicle Experiments
To start with, the 3rd-floor corridor of Whittemore Hall was chosen to perform the trajectory tracking experiments. A path was chosen in the corridor as shown in Fig. 4.1 and its GPS coordinates were taken to provide a reference to the vehicle in order to track it. Length of the path is approximately 24m. The vehicle is supposed to track the updating targets in x and y-direction independently resulting in 2D trajectory tracking.
The experiment is run for a duration of 22s with high-level and low-level controller rates at 5 Hz and 10 Hz respectively. The target update rate is 2.5 Hz in both directions and the desired constant linear speed is set to 1 m/s which makes the look-ahead distance to be 0.4m. The initial position of the vehicle is shown in Fig. 4.1 by the cross mark and it starts with zero initial speeds in both directions.
Initial critic and actor weights are chosen randomly in the range [−1, 1]. The user defined parameters are chosen as L = 17, β = 0.6, γ = 2, R = 0.01, Q = 0.001I2, and the weights tuning gains as αa = 0.001, αc = 10. Probing noise is added to the control inputs during the first 5.5s of the simulation. The linear speed of the vehicle is saturated to 1.1m/s for the initial testing phase.
The sensor hub reports data at a rate of 50 Hz and the RTK-GNSS module at a rate of 5Hz. The length of the vehicle’s wheelbase is 0.319m.
Values of the low-level controller gains kp, ki and kd are shown in Table 4.1. It was realized during the experimentation that the chosen GNSS module does not report speed measure-ments when the rover is moving at linear speeds less than 0.5m/s in which case the speed measurements are assumed to be equal to the last measured values for now. Because the length of the path (24m) is not long enough for the ideal weights to be learned in one itera-tion, multiple iterations of the experiment are performed using the weights learned from one iteration as the initial weights for the next iteration.
The experimental tracking results obtained are as shown in Fig. 4.2 for multiple iterations. The figure also shows the simulation results obtained in MATLAB for the same scenario with experimental constraints included.
The path plots show that the results get better with iterations but for yet unknown reasons the actual path of the vehicle is oscillating close to the reference path. Further iterations above three didn’t improve the experimental results. The plots of actual and desired positions in x and y-directions are in Fig 2.3 for iteration 3. Going ahead, the idea is to choose a reference path that is longer, avoiding the discontinuity in learning and also to do more research into finding the reasons for the oscillations.
Contents
List of Figures
List of Tables
1 Introduction
1.1 Background
1.2 Intermittent Model-free Trajectory Tracking
1.3 Experimental Platform
1.4 Platooning and String Stability
1.5 Thesis Outline
2 Model-free Event-triggered Optimal Tracking Control
2.1 Overview
2.2 Problem Formulation
2.3 Event-triggering Condition
2.4 Model-free Online Tuning
2.5 Simulations
3 Experimental Platform Design and Development
3.1 Hardware
3.2 Software
3.3 Command Station
3.4 Miscellaneous
4 Experimental Validation
4.1 Single Vehicle Experiments
5 Platooning Control
5.1 Overview
5.2 Reference Trajectory Estimation for Following Vehicles
5.3 Inter-vehicle Communication
5.4 Multi-Vehicle Simulations
6 Conclusion
GET THE COMPLETE PROJECT
Trajectory Tracking Control of Unmanned Ground Vehicles using an Intermittent Learning Algorithm
