Wheeled Ground Robots

This section of the course dealt with fundamentals relating to wheeled ground robots and car-like mobile robots. The first part involved using the kinematic bicycle model and simulating various steering inputs to observe effects on vehicle trajectory. In particular, the pepy bicycle model shown below was used to study the performance of the vehicle.

Pepy Model where the Position is Measured at the Rear Wheels

The model was evaluated for three different steering inputs, a constant steering angle, a sinusoidally varying steering input and square wave steering input. The results are shown below.

The Plots above show State Change with Time. The Plots below Shown Vehicle Co-ordinates in the XY Plane. All Plots drawn for Constant Steering Inputs

With a constant steering input, it is seen that the car traces a curve. As the steering angle is increased, the curvature of the curve increases with the car finally being able to perform a closed loop within the simulation time at large steering angles.

The results using a sinusoidal input are shown below.

Vehicle Performance with Sinusoidal Steering Inputs. Upper Row – State vs Time, Lower Row – Position in XY Plane

Sinusoidal steering inputs can be seen to make the vehicle traverse a wavy path. It is to be noted that the steering angle is measure form the center line of the vehicle. The first row shows the state vs time while the bottom row shows the vehicle position in the XY plane. In the first sample, the vehicle is moving at 1 m/s with a Sine steering angle amplitude of 0.1 radians. In the second plot, the steering angle amplitude is 1.5 radians and a vehicle velocity of 50 m/s. The final plots show the same amplitude of 1.5 radians but starting in the opposite direction. The results of the plots show the expected behavior with the car deviating from the x-axis towards the direction that the steering is initiated in after which the opposite lock brings the car back to its original orientation.

Below are the plots after applying a sqaure wave to the steering inputs.

State vs Time shown Above and Vehicle XY Coordinates Shown Below

Again, the behavior is as expected. The car begins moving in the direction of initial steering input after which the car reverts back to its original orientation since the opposite steering input acts for the same duration. This model of inputs is unrealistic for the fact that instantaneous steering changes are not possible.

The next portion of the assignment involved implementing a lane-change maneuver using the dynamic bicycle model. The open loop system based on the dynamics model was an unstable system, however it was made stable by implementing an appropriate state feedback on the steering input. The gain on the state feedback was selected using pole-placement. The dynamic bicycle model controller in terms of the lateral offset error and yaw error is written as shown below:

Dynamic Bicycle Model Controller – From Dr. John Dolan’s Slides in 16-665 Robot Mobility at CMU

The desired positions were extracted from the requested trajectory which had the car moving along y = -5 towards the positive x-axis direction until reaching x = 5 m after which the car began the lane change and moved towards the y = 0 line over 90 meters along the x-axis and finally traversing 5 meters along the x-axis after attaining y = 0. The constraints that had to be met were that the steering input rate had to be less than 25 rad/sec with maximum thresholds on the error and maximum settling times. The results are summarized below:

The desired motion was achieved by an appropriate gain on the errors with a realistic steering rate. The transient errors were also kept below the required thresholds by ensuring that the max abs(e2) was below 0.02 rad and that abs(e1)≤0.002 m and abs(e2)≤0.0007 rad within 1 second at the transition points.


Air Mobility

In this project, the goal was to implement a finite state machine that would simulate the performance of a quadcopter and enable certain motions based on the user specified state. The functional architecture that was drawn up for this implementation is shown below.

State Machine Architecture for the Simulated Quadcopter

The state of the quadcopter was represented using a 16-vector whose elements were the x, y and z positions, x’, y’, z’, ϕ (roll), θ (pitch), ψ (yaw), ϕ’, θ’, ψ’ and the four motor RPMs. The control system for the quadcopter was implemented using a cascaded control system. The position controller was the outer most element of the cascaded controller which would take an input state from the desired trajectory at each timestep. For a given desired input to the position controller, a simple PD gain on the position and velocity state errors was used to compute an acceleration. The 3-vector acceleration was then used to determine the force vector out of which the z-component was extracted. The 3-vector acceleration term was simply the error in position and velocity times the PD gains. This acceleration term was then fed to the attitude planner which computed the desired roll, pitch and yaw angles as well as the respective roll, pitch and yaw angular rates. Finally, the attitude controller was once again a simple PD controller on the error in angular position and angular rates. These gain-multiplied error terms were used as the input angular accelerations from which the desired moment was determined using the inertia of the quadcopter.

Using the lift thrust obtained from the position controller and the moment from the attitude controller, the quadcopters mixing matrix (which is the transformation that takes the individual motor RPMs to forces and moments on the quadcopter) was used to compute the desired motor RPMs needed to generate the thrust and moment. The motor constant was also used to determine the rate of change of motor RPM. The thrust, moment and rate of change of motor RPM was used to determine the actual state update and was passed as a function to the ODE45 solver in MATLAB.

This core simulator and cascaded controller was then wrapped within a high-level state machine to perform the desired movements in space. The state-machine was implemented such that the user could select from a list of pre-defined motions as shown in the figure below:

State Machine Options

Between the hover and landing sequence, the user is free to select between a pre-defined in-plane star trajectory or a trajectory using user-specified timestamps and coordinates. A sample tracking output is shown below for the star trajectory tracking case.

In-plane Star Trajectory

The hovering performance in z (at z = 2 meters) and the orientation tracking at zero heading was quite good for this purpose. The x and y tracking showed a poorer tracking performance using the given gains particularly near transition points between trajectory segments. This could be improved with some more tuning of the PD controller.