\chapter{Conclusions}

During the present Chapter, a final and conclusive analysis of the developed hardware and software solutions proposed and executed during this work will be made. The objectives that were fully accomplished will be presented, and the ones which did not match the initial expectations will also be exposed. Some proposals about possible future tasks and new work fronts will also be proposed.

\section{Conclusions}

One of the main objectives of this work was to project and build a robust and reliable control board to drive both DC motors, as well as performing all the auxiliary tasks, like the potentiometer's reading system, the digital decoders, the 7-segment display and the manual or automatic selector switch. This objective has been fully accomplished, since the circuit has proven to be robust enough to withstand the laboratory tests, along with all the demanding firmware code development process. Note that only one printed circuit board version was manufactured and used throughout the whole development process, which is precisely the same one that is still driving the gear selector mechanism on the present day. There were no amendments made on the original design, whose drawing can be observed in the Annexes, and no electronic components had to be replaced due to damage during the execution of this work.

The \textit{Arduino}-based control system also turned out to be a good option. Although its frequency limitations, and the higher rigidity of the system when compared to the Microchip PIC-based systems for example. The easy code development functionalities and the huge community developing new and more effective libraries, provided by the \textit{Arduino}, have proven to be very helpful during the execution of this project.

In what concerns to the firmware programming itself, the Dijkstra's algorithm was successfully implemented on the \textit{Arduino} firmware with the expected results, and the initial objective of a less rigid, non-sequential gear selector system could be reached. This firmware programming showed to be suited for the mechanism to successfully reach all the necessary gear positions.

The communication process between the firmware and the control software, which uses an Ethernet cable and the TCP/IP protocol, has proven to be very stable as initially expected. The messaging system used both to control the gear selector mechanism and to read its current state is very complete, and this characteristic has been achieved without the need do sacrifice the simplicity of the message sent and received by the device.

Other software modules were also developed and tested to aid the use of the gear selector mechanism. The calibration software created has shown to be particularly useful, allowing the recalibration of the system to new conditions without editing the \textit{Arduino} code directly by hand. The existence of such calibration software is important within projects involving many people, like the AtlasCar project, since other people in the project do not need to know or understand everything about the gear selector mechanism's programming to use it and calibrate it.

The ROS Node, also developed during this work, allows the communication with the gear selector mechanism using the mew ROS architecture, which is currently the one present in the AtlasCar control PC. This Node was created to facilitate the future mounting of the device in the Atlascar vehicle, and its integration with the already developed software.

The simplified Hardware-in-the-Loop simulator, written in Matlab, also allowed the further testing of the gear selector mechanism. This simulation was useful to anticipate some particular situations or problems that may occur when the mechanism is mounted on the AtlasCar vehicle, and correct them.

The AtlasCar gear selector mechanism's power transmission system, using the belts and pulleys, may not be the most adequate to mount it directly on the AtlasCar vehicle. Although the DC motors' planetary gearboxes easily develop the necessary torque in order to move the gear lever, the belts may have not enough grip to drive the lever to its correct place. The original idea of using belts to transmit power was thought to allow the system to skip pulley teeth if the mechanism jammed, or if the controller failed for some reason. The problem is that the belts may fail when exposed to smaller tensions than the ones required to move the gear lever, which was noticed in the laboratory. The use of a more consistent power transmission system, like a chain and sprocket, would probably solve the problem.

\section{Future Work}

The most important future tasks that still need to be performed in the AtlasCar are listed below. These tasks would guarantee the proper operation of the gear selector mechanism on the AtlasCar, and would create the necessary conditions for the development of new and more daring manoeuvres:

\begin{itemize}
\item Mounting of the system in the AtlasCar vehicle's gear lever, and correction of possible problems that will inevitably appear during that process. The replacement of the belt and pulley system by an alternative system, like the chain and sprocket referred in the previous Section, may be necessary;
\item Possible corrections and modifications on the code that controls the DC motors, to ensure the correct positioning of the gear lever. These corrections can only be executed after mounting the gear selector mechanism on the vehicle;
\item Implementation of a closed loop speed control on the vehicle, once the mechanism is working properly;
\item Implementation of certain low-level manoeuvres involving the gearbox, the clutch and the throttle, needed for a particular set of precision driving situations. Some examples are the parking manoeuvre or the start of movement in a steep slope, where the biting point is needed to prevent the vehicle from rolling backwards.
\end{itemize}
