\chapter{Partial Gearbox Simulator} \label{chap:partial_gearbox_simulator}

\section{The Power Train System} \label{sec:the_powertrain_system}

In order to perform laboratory tests on the gear selector mechanism described on Chapter \ref{chap:automatic_gearbox}, prior to its installation in the AtlasCar vehicle, a simplified partial power train and car physics simulator was created using Matlab. The purpose of this simulator is to test the robustness of the \textit{Arduino} programming, the shifting logic used, the communication protocol implemented and to evaluate shift times.

The simulator is built in a way that allows the gear selector mechanism to be tested using the Hardware-in-the-Loop (HIL) simulation technique. This technique is used to simulate the real-time behaviour of a particular embedded system which is only a component of a more complex system. This more complex system, where the embedded component will be inserted, is usually emulated using representative mathematical models.

In the context of this study, the gear selector mechanism represents the embedded component, and the systems that will be mathematically modelled are the power train system and some aspects of the vehicle's physics. Note that the aim of this simulator is not to obtain a very accurate representation of the vehicle's dynamics, or even to reproduce the precise behaviour of the engine, clutch or other key power train components.

The power train system of a vehicle is the set of all the components necessary to generate, transform and transmit power, in order to move it. The most important parts on the power train system are:

\begin{itemize}
\item The Engine;
\item The Clutch;
\item The Transmission;
\item The Drive Shafts;
\item The Differential;
\item The Wheels.
\end{itemize}

Figure \ref{figure:power_train_interactions} shows the energy flow between the elements of the power train. Even today, some of the elements represented have no accurate representative mathematical model, or the existing models require a lot of computational power to run in real-time applications, like the one at hand. Other elements have non-linear behaviour, like the clutch or the interaction between the wheels and the road. New and more accurate physical and mathematical models for some of the vehicles' main components are constantly being developed and improved \cite{simulation dry clutch}.

\begin{figure}[h!]
\centering
\epsfig{file=Images/power_train.eps,width=100mm}
\caption{Power Train movement flow scheme between parts.}
\label{figure:power_train_interactions}
\end{figure}

On the next Subsections, the physical model of the car is presented, and a description on how the various systems are simulated, and the way how they interact with each others, is detailed.

\section{Car Physics} \label{sec:car_physics}

In order to model the car physics, a simple two dimensional model of the vehicle was created. This model of the car takes into account the five main forces acting on a car while it is in motion \cite{Game Physics}. The considered forces are the following:

\begin{itemize}
	\item Engine Force $(F_{eng})$
	\item Drag Force $(F_{drag})$
	\item Force of Gravity $(F_{g})$
	\item Rolling Resistance Force $(F_{rr})$
	\item Braking Force $(F_{b})$
\end{itemize}

Figure \ref{figure:forcediagram} shows the forces used in this model, as well as the coordinate system used.

\begin{figure}[h!]
\centering
\def\iangle{30} % Angle of the inclined plane
\def\down{-90}
\def\arcr{5mm} % Radius of the arc used to indicate angles
\begin{tikzpicture}[
force/.style={>=latex,draw=blue,fill=blue},
axis/.style={densely dashed,gray,font=\small},
M/.style={rectangle,draw,fill=lightgray,minimum size=5mm,thin},
m/.style={rectangle,draw=black,fill=lightgray,minimum size=3mm,thin},
plane/.style={draw=black,fill=blue!10},
string/.style={draw=red, thick},
pulley/.style={thick},
]
\matrix[column sep=10mm]{
%% Sketch
    \draw[plane] (0,-1) coordinate (base)
                     -- coordinate[pos=0.5] (mid) ++(\iangle:3) coordinate (top)
                     |- (base) -- cycle;
    \newdimen\mydimx
    \newdimen\mydimy
    
    \path (mid) node[M,rotate=\iangle,yshift=2.5mm] (M) {};
    
    \pgfextractx{\mydimx}{M.center};
	\pgfextracty{\mydimy}{M.center};
	
    % Draws the Center of Mass:
    
    \draw[thick] (M.center) circle(1mm);
    \fill[black] (M.center) -- (\mydimx+1mm,\mydimy) arc (0:90:1mm) -- (M.center) -- cycle;
    \fill[black] (M.center) -- (\mydimx-1mm,\mydimy) arc (0:90:-1mm) -- (M.center) -- cycle;
    
    %arc (0:-90:1mm) -- (M.center) -- cycle    
    
    \draw[->] (base)++(\arcr,0) arc (0:\iangle:\arcr);
    \path (base)++(\iangle*0.5:\arcr+5pt) node {$\alpha$};
&
    %% Free body diagram of M
    \begin{scope}[rotate=\iangle]
        \node[M,transform shape] (M) {};
        % Draw axes and help lines
        {[axis,->]
            \draw (0,-1) -- (0,2) node[right] {$+y$};
            \draw (M) -- ++(2,0) node[right] {$+x$};
            % Indicate angle. The code is a bit awkward.
            \draw[solid,shorten >=0.5pt] (\down-\iangle:\arcr)
                arc(\down-\iangle:\down:\arcr);
            \node at (\down-0.5*\iangle:1.3*\arcr) {$\alpha$};
        }
        % Forces
        { [force,->]
            % Assuming that Mg = 1. The normal force will therefore be cos(alpha)
            \draw (M.center) -- ++(0,{cos(\iangle)}) node[above right] {$N$};
            \draw (M.west) -- ++(-1,0) node[left] {$F_{b}$};
            \draw (M.north west) -- ++(-1,0) node[above left] {$F_{rr}$};
            \draw (M.south west) -- ++(-1,0) node[below left] {$F_{drag}$};
            \draw (M.east) -- ++(1,0) node[above] {$F_{eng}$};
        }
    \end{scope}
    % Draw gravity force. The code is put outside the rotated
    % scope for simplicity. No need to do any angle calculations. 
    \draw[force,->] (M.center) -- ++(0,-1) node[below] {$F_{g}$};
    \draw[thick] (0,0) circle(0.1);
    % Draws the Center of Mass:
    %\filldraw[fill=black, draw=black](0,0) -- (0.1,0) arc (0:30:3mm) -- cycle;
    \fill[black] (0,0) -- (0.1,0) arc (0:90:0.1) -- (0,0);
    \fill[black] (0,0) -- (-0.1,0) arc (0:90:-0.1) -- (0,0);
    %%
\\
};
\end{tikzpicture}
\caption{Force Diagram used in the vehicle simulator.}
\label{figure:forcediagram}
\end{figure}

The resulting force acting on the car is the sum of all the above:

\begin{equation}
\label{eq:force_sum}
F_{r} = F_{eng} + F_{drag} + F_{g} + F_{rr} + F_{b}
\end{equation}

Each of these forces must be calculated separately, and then the resulting force acting on the vehicle is computed. With the force acting on the vehicle and its mass, it is possible to calculate the acceleration value at a given time. The vehicle speed value on the next iteration of the simulator can then be calculated using the Euler method for numerical integration,as shown in Equation \ref{eq:speed_formulae}:

\begin{equation}
\label{eq:speed_formulae}
v(t+t_{step}) = v(t) + t_{step} \times a
\end{equation}

Where:

\begin{itemize}
	\item $v \longrightarrow$ The vehicle speed $[m/s]$;
	\item $t \longrightarrow$ Current time value $[s]$;
	\item $t_{step} \longrightarrow$ The time step of the integrator $[s]$;
	\item $a \longrightarrow$ Last acceleration value, calculated using the resulting force $[m/s^{2}]$.
\end{itemize}

The next Subsections explain in detail how each one of these forces, used to compute the resulting force acting on the vehicle, are calculated.

\subsection{The Drag Force} \label{subsec:the_drag_force}

The drag force is the main responsible for the loss of speed experienced by an object when it's travelling at higher speeds. The following equation gives a relatively reasonable value for the force exerted by the wind in the car, while in motion. It is also assumed that the fluid where the car is immersed, air in this case, is in a stationary sate. The force can be calculated using the Drag Equation \cite{fluid dynamics}:

\begin{equation}
\label{eq:drag_force}
F_{drag}=\dfrac{1}{2}\times \rho\times C_{d}\times A\times v^{2}
\end{equation}

Where:

\begin{itemize}
	\item $\rho \longrightarrow$ The density of the involving fluid $[kg/m^{3}]$;
	\item $C_{d} \longrightarrow$ The Drag Coefficient, a dimensionless quantity characteristic of the vehicle;
	\item $A \longrightarrow$ Frontal Area of the vehicle $[m^{2}]$;
	\item $v \longrightarrow$ Current speed of the vehicle $[m/s]$.
\end{itemize}

The sign of this force is opposite to the current speed vector direction. When the car is stopped, its value is zero. When the driver is driving forward, the force is exerted pointing to the back of the car, and vice-versa.

\subsection{The Rolling Resistance Force} \label{subsec:the_rolling_resistance_force}

The rolling resistance force is the force experienced by the car caused by the friction between the tires' rubber and the surface of the road. This force is calculated using the normal force and a dimensionless coefficient, called the "rolling resistance coefficient". This is the most notorious resistant force acting on the vehicle while it is travelling at lower speeds. The rolling resistance force equation is as follows \cite{tires and passengers}:

\begin{equation}
\label{eq:road_resistance_force}
F_{rr}=C_{rr}\times N
\end{equation}

Where:

\begin{itemize}
	\item $C_{rr} \longrightarrow$ The "rolling resistance coefficient";
	\item $N \longrightarrow$ Normal Force $[N]$;
\end{itemize}

The Normal Force can be easily calculated using the weight of the car, the angle of the road and the acceleration of gravity, using the following expression:

\begin{equation}
\label{eq:normal_force}
N=m\times g\times \cos(\theta)
\end{equation}

Where:

\begin{itemize}
	\item $m \longrightarrow$ Car mass $[kg]$;
	\item $g \longrightarrow$ Acceleration of Gravity $[m/s^{2}]$;
	\item $\theta \longrightarrow$ Angle of the ground plane.
\end{itemize}

For pneumatic tire vehicles, the rolling resistance coefficient can be estimated using an empirical expression. This expression depends on the tires' pressure and the current vehicle speed \cite{handbook for rolling resistance}:

\begin{equation}
\label{eq:rolling_resistance_coefficient}
C_{rr}=0.005+\dfrac{1}{P}\times \Bigg (0.01+0.0095\times \bigg (\dfrac{v}{100}\bigg )^{2}\Bigg )
\end{equation}

Where:

\begin{itemize}
	\item $P \longrightarrow$ Tire Pressure $[bar]$;
	\item $v \longrightarrow$ Current speed of the Vehicle $[km/h]$.
\end{itemize}

Merging these three equations, a reasonable approximation of the rolling resistance force can be computed. The sign of this force is also given relatively to the direction of the speed vector. Similarly to what happened with the drag force, if the car is driving forward, this force is pointing backwards, and vice-versa.

\subsection{The Braking Force} \label{subsec:the_braking_force}

The braking force can be calculated by predefining a maximum braking force. In order to simplify the approach, it is assumed that the slip between the tires and the road is non-existent, and that the actual force exerted by the brakes at a certain time is proportional to an user input, which represents the percentage of the brake pedal pressed. The maximum braking force is left as a configurable parameter, and should be defined prior to running the program. The equation that represents this proportional behaviour is the following:

\begin{equation}
\label{eq:braking_force}
F_{b}=percent\times F_{b_{max}}
\end{equation}

Where:

\begin{itemize}
	\item $percent \longrightarrow$ Percentage of the brake pedal pressed;
	\item $F_{b_{max}} \longrightarrow$ Maximum Braking Force $[N]$.
\end{itemize}

The braking force is also always pointing in the opposite direction of the speed, and it assumes a zero value when the car is stopped.

\subsection{The Gravity Force} \label{subsec:the_gravity_force}

The gravity force is calculated simply by projecting the weight of the vehicle on the $x$ direction, and can be expressed by the following equation:

\begin{equation}
\label{eq:gravity_force}
F_{g}=m\times g\times \sin(\theta)
\end{equation}

Where:

\begin{itemize}
	\item $m \longrightarrow$ Car mass $[kg]$;
	\item $g \longrightarrow$ Acceleration of Gravity $[m/s^{2}]$;
	\item $\theta \longrightarrow$ Angle of the ground plane.
\end{itemize}

Note that there is a negative sign on the equation, because when the angle is negative, it means that the car is descending a road, so the force exerted on the car is positive.

\subsection{The Engine Force} \label{subsec:the_engine_force}

The internal combustion engine is the power source for the whole car system. The engine is responsible for the conversion of the chemical energy, stored in the vehicle's fuel, into rotational movement. The interaction between all the thermodynamic and mechanical processes that occur inside an internal combustion engine make it a particularly difficult system to model, as a whole.

The engine simulation is another subject still being developed and studied further, and there are some works in the subject, but the model systems proposed are too complex to be applied to the subject at hand. Because of all the complexities associated with the modelling the internal combustion engine itself \cite{engine simulator}, the approach used in this simulator is a very simplified model, and it requires the user to know or measure some parameters about the engine itself, as well as some parameters regarding the transmission process itself. Although the engine simulation used is simplified, it is obtained using a single function, that can easily be replaced by a more complex simulation process, if necessary.

\begin{figure}[h!]
\centering
\epsfig{file=Images/torque_rpm_curve.eps,width=100mm}
\caption{Torque vs RPM of a 1999 Dodge Neon DOHC engine.}
\label{figure:torque_rpm_curve}
\end{figure}

First, there is the need to define the Torque versus RPM curve for the engine. This curve is obtained performing a dynamometer test on the engine, and it allows the knowledge about the maximum torque value that can be achieved by a certain internal combustion engine at a given RPM value. A 1999 Dodge Neon DOHC engine curve is represented in Figure \ref{figure:torque_rpm_curve} \cite{allpar website}. The problem in using the values from this curve is that the dynamometer test is driven at the maximum load of the engine, meaning that the throttle is fully opened. In this simulator, and in order to simplify the system as much as possible, the torque value for a given RPM is assumed to be proportional to the percentage of throttle pedal pressed, so:

\begin{equation}
\label{eq:tau}
\tau=throttle\_percent\times \tau_{max}@RPM
\end{equation}

Where:

\begin{itemize}
	\item $throttle\_percent \longrightarrow$ Percentage of throttle pressed;
	\item $\tau_{max}@RPM \longrightarrow$ Maximum Torque at a given RPM, directly interpolated from the Torque versus RPM curve $[N\cdot m]$.
\end{itemize}

The RPM value is calculated directly from the vehicle speed, using the gear ratios and assuming that there is no slip between the tires and the road.

At this point, the engine force can be calculated using the following equation:

\begin{equation}
\label{eq:engine_force}
F_{eng}=\dfrac{\tau\times x_{g}\times x_{d}\times \eta_{trans}}{R_{tire}}
\end{equation}

Where:

\begin{itemize}
	\item $\tau \longrightarrow$ Current Torque $[N\cdot m]$;
	\item $x_{g} \longrightarrow$ Current Gear Ratio;
	\item $x_{d} \longrightarrow$ Differential Ratio;
	\item $\eta_{trans} \longrightarrow$ Transmission efficiency;
	\item $R_{tire} \longrightarrow$ Tire Radius $[m]$.
\end{itemize}

\section{The Simulator GUI} \label{sec:the_simulator_gui}

Although the use of a SIMULINK model was initially considered, the simplicity of the physics involved on this simulator, along with the nature of the simulation itself, did not justify its usage, since the aim of this simulator is not physical accuracy. The values used to calculate some of the forces described above are based on standard values, and they do not correspond to the real AtlasCar vehicle values. Some examples of this are the gear ratios or the engine Torque versus RPM curve. Extensive research has been performed in pursuit of such values, both on-line, in car catalogues, magazines and even through the vehicle manufacturer, but no information was found or provided about this particular car model. However, the simulator was written in such a way that the main force calculations are performed in separate functions, which can easily be replaced at any time when more realistic values are available, or more accurate models are developed and implemented.

A Graphical User Interface (GUI) was created to allow the user to change some real-time driving parameters, and to show the current state of the simulator. When the program starts, a first Graphical User Interface is displayed, the Parameters Graphical user Interface, as shown in Figure \ref{figure:parameters_gui_simulator} . This first Graphical User Interface allows the user to change the simulator starting values, physical conditions and parameters or vehicle specifications that are constant throughout the simulation.

\begin{figure}[h!]
\centering
\epsfig{file=Images/parameters_gui_simulator.eps,width=80mm}
\caption{Parameters Graphical User Interface of the simulator.}
\label{figure:parameters_gui_simulator}
\end{figure}

The values that can be modified in this Graphical User Interface are divided in two main categories: the \textit{Physical Characteristics}, which are physical values and quantities of the environment where the car is inserted, and the \textit{Car Characteristics}, that represent attributes of the vehicle itself. The corresponding units, that allow the simulator to work correctly, are also displayed in front of each editable text fields.

The \textit{Physical Characteristics} that can be changed in the scope of this simulator are the following:

\begin{itemize}
\item The maximum road angle, which corresponds to the angle between the road plane and the plane tangent to the theoretical earth curvature at this exact point;
\item The gravity acceleration, as this value is not constant along all points on the surface of the planet;
\item The density of air, that can also vary according to the altitude, temperature and humidity;
\item The drag coefficient of the vehicle, which is a representative dimensionless quantity;
\item The initial speed of the car, which is the starting speed of the simulator;
\end{itemize}

The \textit{Car Characteristics} that can be edited and changed in order to vary the response of the simulator to the user actions are the following:

\begin{itemize}
\item The clutching time, which represents the time in seconds that the clutch takes to go from the engaged state to the disengaged one, or vice-versa;
\item The car total mass, including the load mass;
\item The maximum brake force, which is the force exerted by the brakes on the car if the brake pedal is completely pressed;
\item The tire pressure in $bar$, assuming that all the tires are at the same pressure.
\item The frontal area of the vehicle, which is used to compute the Drag Force, caused by the movement of the car in the surrounding air;
\item The transmission efficiency, which corresponds to the ratio of usable energy, or the fraction of energy not lost during the movement of the transmission;
\item The wheel radius, or the radius of the car tires;
\item The differential ratio;
\item The gear ratio for all the seven different gears of the car.
\end{itemize}

The main Graphical User Interface, depicted in Figure \ref{figure:main_gui_simulator}, has a set of vertical bars that allows the user to manually change some of the driving variables. Real-time graphics are constantly updated accordingly to the changes. The user can also override the values present in the vertical bars at each time, in order to impose specific values to the system.

\begin{figure}[h!]
\centering
\epsfig{file=Images/gui_simulator.eps,width=120mm}
\caption{Main Graphical User Interface of the simulator.}
\label{figure:main_gui_simulator}
\end{figure}

The meaning of each of the Graphical User Interface fields and elements is explained in detail, according to the numeration in Figure \ref{figure:main_gui_simulator}.

\begin{enumerate}
\item \textit{Angle} bar $\rightarrow$ This vertical sliding bar allows the user to make the road angle vary overtime. This bar's default value is a zero, corresponding to a perfectly horizontal road. The \textit{Angle} bar has a maximum and a minimum value, the last being the symmetric of the first. As described in Subsection \ref{subsec:the_gravity_force}, a negative angle means that the car is descending a road, thus accelerating;
\item \textit{Throttle} bar $\rightarrow$ The \textit{Throttle} vertical bar allows the user to vary the percentage of throttle, and consequently increase or decrease the force exerted by the engine. The default value for this bar is zero, corresponding to the bottom position. The top position corresponds to the maximum throttle;
\item \textit{Brake} bar $\rightarrow$ The \textit{Brake} vertical bar allows the user to change the force exerted by the car brakes. This force is proportional to the maximum brake force of the car, defined previously in the parameters Graphical User Interface, as described in Subsection \ref{subsec:the_braking_force};
\item \textit{Angle} override $\rightarrow$ The \textit{Angle} override editable text box allows the user to impose a specific value for the road angle. The value must be between the maximum and minimum road angle values, or it is ignored;
\item \textit{Throttle} override $\rightarrow$ The \textit{Throttle} override editable text box allows the user to impose a specific percentage value for the throttle; If the value is greater than 100\%, a 100\% value is assumed, and if the value is negative, a 0\% value is assumed;
\item \textit{Brake} override $\rightarrow$ The \textit{Brake} override editable text box works in a similar way to the \textit{Throttle} override editable text box, only it affects the brake percentage value;
\item \textit{Override} push-button $\rightarrow$ The \textit{Override} push-button collects the values from the override editable text fields and applies them to the respective variables, and updates the vertical bars. If a field is left blank, its value remains unchanged;
\item \textit{Reverse} button $\rightarrow$ The \textit{Reverse} button is used only when the car is in a stationary position, and informs the simulator about the user's intention of direction. This button is a particular kind of button called "Toggle Button", and it visually informs about its state. If the button is pressed, it means that the "reverse" is selected, and that the car will start moving backwards. If the button is not pressed, the car will start moving forward;
\item \textit{Speed} graph $\rightarrow$ The \textit{Speed} graph is constantly being updated and shows the current speed of the car, in $km/h$. The numerical value of the car is also represented in the \textit{Speed} graph title.
\item \textit{Clutch} graph $\rightarrow$ The \textit{Clutch} graph shows the position of the clutch overtime. This graph is continuous and varies between 0 and 1. While clutching the graph is a parametrizable ramp, as the time the clutch needs to actuate can be changed in the initial Parameters Graphical User Interface. The clutch state can also be seen in the \textit{Clutch} graph title;
\item \textit{Gear} graph $\rightarrow$ The \textit{Gear} graph is a stepped line that shows the gear on the gear selector mechanism overtime.  The current gear can also be seen in the \textit{Gear} graph title.
\end{enumerate}

This simulator is based on a state machine, whose states and possible transitions between them are represented in Figure \ref{figure:simulator_scheme}. The vehicle is considered to be stopped when its speed is too low for the engine to stay mechanically connected to the wheels, preventing it from stalling. The default value considered on this simulator for the minimum vehicle speed is 5 $km/h$ when the car is moving forward, or -5 $km/h$ when the car is moving backwards. In the stopped state, the clutch is fully pressed, in order to keep the engine from stalling, and the gear selector mechanism is set to Neutral, for safety reasons. The \textit{Vehicle Stopped} state is in fact an indetermination, from the system's point of view, since there are three possible situations that can be experienced by the system:

\begin{itemize}
\item The car continues stopped;
\item The car starts moving forward;
\item The car starts moving in reverse.
\end{itemize}

The condition that needs to be fulfilled in order for the simulator to resolve this undetermined state is the increasing of throttle input from the user. If the user presses more than a certain percentage of the throttle pedal, 30\% being the default value, the systems assumes the user's intention to start moving. In order to choose between the forward or reverse situations, the simulator uses the information read from the \textit{Reverse} button.

\begin{figure}[h!]
\centering
\epsfig{file=Images/simulator_schematic.eps,width=140mm}
\caption{State Machine scheme used for the simulator.}
\label{figure:simulator_scheme}
\end{figure}

If the system evolves in the forward direction, the first gear is set on the gear selector mechanism, and when the gear shift is complete, the system releases the clutch while a pre-programmed start routine is imposed to the system, increasing the speed inversely proportional to the clutch movement. This simple routine happens inside the state called \textit{Start Moving Forward} in the scheme from Figure \ref{figure:simulator_scheme}. When the system ends the \textit{Start Moving Forward} state, enters automatically on the \textit{Moving Forward} state, which corresponds to the normal behaviour of the car, shifting gears as it seems fit, according to the gear shifting logic applied.

If, on the other hand, the system evolves in the Reverse direction, the Reverse gear is set on the gear selector mechanism, and the clutch is released while a pre-programmed start routine, similar to the one described above for the \textit{Start Moving Forward} state, is imposed to the system, only this time the speed increases in the negative sense. When this routine ends, the system automatically enters the \textit{Moving in Reverse} state, allowing the user do accelerate or brake normally, but having only the Reverse gear available. If the user needs to start driving forward again, and similarly to what happens on the real semi-automatic transmissions, the vehicle must first enter the \textit{Vehicle Stopped} state.

\section{Shifting Logic} \label{sec:shifting_logic}

The gear shifting is a complex decision process performed in a very different way from driver to driver. Some people constantly look to the information displayed in the car's tachometer to decide if a gear shift is needed, others base this decision solely on the speed of the car, or even the engine sound. A machine, such as the controlling computer in the AtlasCar does not currently have such a high level of perception, even with the variety of sensors currently installed in the car.

In order to decide the most appropriate gear ratio for the car, at a certain time, the most obvious inputs of this control system would be the current vehicle speed, the throttle pedal position or the engine RPM value. Many other inputs could be used to improve the process, such as:

\begin{itemize}
\item The road angle, between its plane and the horizontal plane;
\item Inertial information;
\item Engine sound pitch;
\item Constantly updated information about the engine torque;
\item Environment information, such as the relative position to other cars;
\item Information about the car trajectory, such as bumps or tight corners.
\end{itemize}

Although some of these inputs are currently present in the vehicle, its usage is complex because they are still under a development stage. It is the case of the inertial information or the environmental data collected from the lasers and cameras.

The sifting model explained in this work, and the one implemented in the Hardware-in-the-Loop simulator, only uses the information about the vehicle current speed and throttle pedal position. A similar model is used in other works of the same type, to decide which gear the vehicle should be running on. One of these examples is a Matlab SIMULINK Demo called "Modeling an Automatic Transmission Controller" \cite{mathworks website}, in which a gear schedule is implemented for a four-speed vehicle. Another similar approach can be observed on the article "Control of Integrated Powertrain With Electronic Throttle and Automatic Transmission" \cite{gearbox shifting logic}, with the slight difference that the power percentage is used instead of the throttle pedal position.


%Although some of these inputs are currently present, its usage is complex, so only the car speed and engine RPM will be used to complete this approach. The two different shifting models proposed in this work are:

%\begin{itemize}
%\item Shifting model using the Car Speed
%\item Shifting model using the RPM's and the Car Speed;
%\end{itemize}
%
%The following subsections describe each one of these distinct models.

%\subsection{Shifting model using the Car Speed} \label{subsec:shifting_model_using_the_car_speed}

The first and simpler way to determine the current gear, at which the vehicle should be running, is to build a fixed shifting schedule. This shifting schedule can be represented as a two dimensional space, where one dimension's values correspond to the percentage of throttle pressed at a given moment, and the other dimension's values correspond to the car speed at that same moment. Although the percentage of throttle pressed and the car speed are time-dependent quantities, the schedule itself is pre-programmed in the car, and time-independent.

The only purpose of this two dimensional space is to determine the appropriate gear for the car to be running on at a given time, according to the percentage of throttle and the vehicle speed at this given time. A graph representative of this approach, and the first that was used to determine the gear shifts in earlier versions of the Hardware-in-the Loop simulator, is depicted in Figure \ref{figure:gear_shifting_schedule_1}. 

\begin{figure}[h!]
\centering
\epsfig{file=Images/gear_shifting_schedule_1.eps,width=140mm}
\caption[Simplified Gear Shifting Schedule]{Simple Gear Shifting Schedule used on the earlier versions of the HIL Simulator.}
\label{figure:gear_shifting_schedule_1}
\end{figure}

The abscissa's values in the graph of Figure \ref{figure:gear_shifting_schedule_1} correspond to the percentage of throttle pressed, and the ordinates' values represent the current vehicle speed. At each iteration of the simulator, the function that implements the shifting schedule determines the point on the graph that corresponds to that iteration's throttle percentage and car speed values, which corresponds to the gear that should be imposed on the gear selector mechanism. The coloured curves represent the points of vehicle speed and throttle position at which a gear shift should take place.

Note that when the driver is not pressing the throttle pedal, the percentage of throttle corresponds to zero, and the speed at which the car would shift corresponds to the values directly over the ordinates' axis. Another interesting characteristic of this approach is that, for a constant vehicle speed value, the gear communicated to the gear selector mechanism can be different, depending on the throttle percentage input from the user, hence the characteristic shape of the curves represented. For example, if the vehicle is running at 80 Km/h pressing the throttle pedal at only 20\%, the car should be running on a $5^{th}$ gear, according to the graph from Figure \ref{figure:gear_shifting_schedule_1}. If, for some reason, the driver suddenly presses the throttle until 80\%, the system interprets this abrupt throttle percentage change as a driver's desire for a fast increment on the car speed, and automatically shifts to a $4^{th}$ gear, in order to respond to this request.

The value of the AtlasCar vehicle speed is measured with good precision using the rotary encoder attached to the rear right wheel. There is also no problem in using the percentage value of the throttle, because the AtlasCar throttle is already a fully electronic system, and this value is used in order to actuate the throttle valve. This method is also able to compute the current gear very fast, because it uses simple linear interpolation to build the gear shifting lines present in the graph.

Although the graph from Figure \ref{figure:gear_shifting_schedule_1} easily illustrates the approach used on the simulator's gear shifting schedule, and allowed it's earlier versions to produce relatively good results, a problem was detected while simulating a particular kind of situation: the neighbourhood of the gear shifting lines. When slight variations on the values of throttle percentage or vehicle speed are made near the gear shifting lines between only a few iterations of the simulator, thus making the calculated point go over and under these lines, there was the risk of provoking gear shifts that were not really necessary. This situation was corrected by creating up-shift lines in different positions than the down-shift ones, which did not happen in the gear shifting schedule described above, and depicted in Figure \ref{figure:gear_shifting_schedule_1}, where there is only one line to determine both the up-shift and the down-shift. This new gear shifting schedule is depicted in Figure \ref{figure:gear_shifting_schedule_2}.

\begin{figure}[h!]
\centering
\epsfig{file=Images/gear_shifting_schedule_2.eps,width=140mm}
\caption[Hysteresis Gear Shifting Schedule]{Hysteresis Gear Shifting Schedule used on the HIL Simulator, contemplating the different speeds between the process of shifting up and shifting down.}
\label{figure:gear_shifting_schedule_2}
\end{figure}

In order to obtain a better and more realistic response from this kind of shifting schedule, an alternative shifting schedule is proposed. This second shifting schedule, depicted in Figure \ref{figure:gear_shifting_schedule_2}, works in a very similar way to the one on Figure \ref{figure:gear_shifting_schedule_2}, but is more complex in the way it uses distinct lines to determine the up-shift and the down-shift. As shown in Figure \ref{figure:gear_shifting_schedule_2}, the lines with the upward-pointing triangle markers and the continuous line represent the combination of throttle percentage and vehicle speed used as an up-shifting criteria, and the ones with the downward-pointing triangle markers and dashed lines represent that same combination of throttle percentage and vehicle speed used for the down-shifting criteria. The coloured spaces on the graph correspond to throttle percentage and vehicle speed combinations with a single gear solution.

A double gear solution happens in the white spaces, between two lines corresponding to symmetric transitions, like the one existing between the dashed line that represents the down-shift from $2^{nd}$ gear to the $1^{st}$ gear and the continuous line representing the up-shift from the $1^{st}$ gear to the $2^{nd}$ gear. This double solution problem is solved by passing the current gear into the second version of the function implementing the gear shifting schedule. This function compares the current gear value with the two possible gear solutions. This is handled in two different ways:

\begin{itemize}
\item If the current gear value is greater than, or equal to the greatest value of both possible gear solutions, the greatest of these solutions is chosen and imposed to the gear selector mechanism;
\item If the current gear value is smaller than, or equal to the smallest value of both possible gear solutions, the smallest of these solutions is chosen and imposed to the gear selector mechanism.
\end{itemize}

Tendentiously, the driver shifts down at lower car speeds than he shifts up. This is contemplated in this second gear shifting schedule, as the shift down curve is always represented below the shift-up one for gear changes between the same gear numbers, which also adds more realistic behaviour to this model, making it more similar to a gear shift performed by a human driver.

Another consideration about this mode is that, at the time of adapting the system to the AtlasCar vehicle itself, all the point values used to build the curves depicted in Figure \ref{figure:gear_shifting_schedule_2} must be conveniently calibrated, in order to obtain the best vehicle response and behaviour.













%\subsection{Shifting model using the RPM's and the Car Speed} \label{subsec:shifting_model_using_the_rpm_of_the_car}
%
%The previous shifting model, based only on the vehicle speed, assumes that the engine is connected to the gearbox at all time, and that more complex interactions, like the sliding between the vehicle's tires and the road, are non-existent. The response of the RPM value is also not directly related with the percentage of throttle pedal pressed, because the non-linearity of the real internal combustion engine.
%
%At the time of mounting and controlling the gear selector mechanism on the vehicle, the RPM value should be considered together with the gear shifting logic presented above to improve its quality. One way to do so would be to define a graph similar the one presented for the previous logic, but instead of using solely the throttle percentage and the vehicle speed as criteria to change the gear, a combination of both graphs' information should be used to decide the gear the vehicle should be running on. The gear change takes place only when both graphs' conditions are met.
%
%This gear schedule involving the engine RPM was not used in the simulator, because the information about the vehicle speed is used in a cycle to calculate directly the RPM value of the engine, through the current gear ratio, as explained in Section \ref{sec:car_physics}. This RPM value is then used to calculate the maximum engine torque, and the current torque using the information about the percentage of throttle pedal pressed. The torque allows the calculation of the engine force, which corresponds to a certain acceleration value since the mass of the system is constant. This acceleration value is used to compute the vehicle speed, which is then used to calculate a new RPM value.  


