% -------------------------------------------------------------
% Secção sobre tretas 1
% -------------------------------------------------------------
\section{Resultados Experimentais}\label{sec:result_exp}



Neste capítulo serão abordados os diferentes testes realizados, aos diferentes módulos e será feita uma análise crítica aos mesmos. 
O trajeto escolhido para testar o funcionamento destes equipamentos no AtlasCar está ilustrado na figura \ref{fig:traj_test}. Este percurso situa-se em Aveiro, foi realizado em aproximadamente 7:40 minutos e tem cerca de 3,3 km.

\begin{figure}[h!]
\begin{center}
	\includegraphics[width=0.6\textwidth]{imagens/troco_testes.eps}
\caption{Trajeto efetuado para testes dos dois Arduínos.}
\label{fig:traj_test}
\end{center}
\end{figure}


\subsection{Módulo Arduíno da monitorização}\label{sec:modu_hard}
Após a implementação dos dois sistemas de hardware no AtlasCar, descritos no capítulo \ref{ch:sis_monito_velo}, foram realizados testes para aferir o bom funcionamento dos dois módulos.
Um dos objetivos deste trabalho é a monitorização do habitáculo para tal era necessário que este fosse constantemente monitorado.
%Por este motivo foram analisados os gráficos com as frequências de receção de mensagens do módulo da monitorização e da velocidade, figuras \ref{fig:frq_monit} e  \ref{fig:frq_velo}, respetivamente. 
%O gráfico \ref{fig:frq_monit}, mostra a variação da frequência ao longo do percurso, da figura \ref{fig:traj_test}.
O módulo de monitorização apresentou uma frequência média de publicação das mensagens de 58 Hz e variância de 6.82$\times 10^{-3}$ Hz.
Se tivermos em conta a frequência a que este sistema publica uma mensagem, considera-se esta diferença irrelevante para o bom funcionamento dos módulos que subscrevem esta mensagem.
De notar que este sistema é o que publica as mensagens com a frequência mais alta.

%\begin{figure}[h!]
%\begin{center}
%	\includegraphics[width=0.8\textwidth]{imagens/freq_monit.eps}
%\caption{Frequência de publicação da mensagem pelo módulo Arduíno da monitorização.}
%\label{fig:frq_monit}
%\end{center}
%\end{figure}



\subsection{Módulo Arduíno da velocidade}\label{sec:modu_vel}

%\begin{figure}[h!]
%\begin{center}
%	\includegraphics[width=0.8\textwidth]{imagens/freq_velo.eps}
%\caption{Frequência de publicação da mensagem pelo módulo Arduíno da velocidade.}
%\label{fig:frq_velo}
%\end{center}
%\end{figure}

A frequência de atualização do valor da velocidade é semelhante ao tempo definido no programa do Arduíno.
Como referenciado no capítulo \ref{ch:sis_monito_velo}, a cada 100 ms o Arduíno lê as portas do contador de velocidade, daí que a frequência de atualização da mensagem seja cerca de 10 Hz.
% Este valor não chega a 10 Hz pois o Arduíno da velocidade demora um certo tempo a ler o valor da contagem do HCTL-2022.
Contudo esta frequência de atualização da velocidade demonstra ser bastante rigorosa ao longo do tempo, com uma variância de 4.5909$\times 10^{-6}$. 
Um dos problemas encontrados no sistema antigo, quando a leitura da velocidade era feita pelo PLC, consistia na irregularidade e falha nos valores da velocidade AtlasCar. Tal evento já não se verifica neste novo sistema. (Figura \ref{fig:velo_traj}).

\begin{figure}[h!]
\begin{center}
	\includegraphics[width=1\textwidth]{imagens/velocity_traj.eps}
\caption{Velocidade do veículo ao longo do trajeto da figura \ref{fig:traj_test}.}
\label{fig:velo_traj}
\end{center}
\end{figure}

Para testar a robustez das comunicações de cada sistema, foi desligado o cabo Ethernet do Arduíno: este teste serviu para garantir que caso exista uma falha na comunicação, nenhum dos sistemas colapse e que o utilizador seja informado da falha de comunicação, evitando assim o colapso do sistema.
Da mesma forma que quando o cabo é ligado este volta a estabelecer ligação com o computador automaticamente.
A velocidade do carro no trajeto da figura \ref{fig:traj_test} pode ser visualizada na figura \ref{fig:velo_traj} onde a) e e) correspondem a situações típicas em que o condutor abranda a velocidade, mas não imobiliza o veículo.
Nas situações b), c) e d) o carro está parado. De relevo a situação c) onde verificamos que o AtlasCar apresenta velocidade negativa, isto acontece, pois o carro estava num cruzamento onde a inclinação do terreno levou a um pequeno recuo deste. 


\subsection{Módulo de deteção das diferentes situações de risco}\label{sec:modu_sit_risk}


Como já referido no capítulo \ref{ch:detec_sit_risk}, o algoritmo deteta as várias situações de risco durante a condução, contudo devido a algumas imposições de hardware, não é possível:
\begin{itemize}
\item Detetar situações onde o condutor do Atlascar provoque uma colisão na parte traseira do veículo, devido a uma travagem brusca do mesmo. Este problema é criado pela falta de equipamento sensorial na zona traseira do veículo.
\item Distinção entre um peão e uma bicicleta, ou em algumas ocasiões um camião de um carro, devido ao tipo de laser utilizado.
\item Detetar os limites da faixa onde circula. Que caso fossem conhecidos não criariam avisos ao condutor como o da figura \ref{fig:det_risk} onde é representado como obstáculo a vegetação que separa as duas vias, induzindo o condutor em erro, e criando falsos registos no ficheiros de texto, gerado pelo módulo.
\end{itemize}

\begin{figure}[h!]
\begin{center}
	\includegraphics[width=1\textwidth]{imagens/ultra_auto.eps}
\caption{Exemplo de uma melhoria a fazer ao algoritmo.}
\label{fig:det_risk}
\end{center}
\end{figure}


Outro dos problemas encontrados, embora pouco frequente, é a deteção de uma mensagem de risco de colisão em situação de arranque e paragem do veículo, como ilustrado na figura \ref{fig:det_erro}. De reparar que não existe nenhum objeto na zona indicada pelo algoritmo. 
A resposta a estas situações está na inclinação que o veículo sofre neste tipo de situações.  
Apesar destas pequenas contrariedades o módulo apresentou uma eficácia superior a 88,9\% no reconhecimento das situações propostas no capítulo \ref{ch:detec_sit_risk}, como pode ser visto na tabela \ref{tab:statistic}  

\begin{table}[h!]
\centering
  \begin{tabular}{  c c c c}
    \hline   \hline
     \textbf{Nome do ficheiro} & \textbf{Situações} & \textbf{Nº deteções corretas} & \textbf{\%} \\ \hline   \hline     
     avenida\_1.bag & 9 & 8 & 88.89\\ \hline
     avenida\_2.bag & 5 & 5 & 100\\ \hline
	 avenida\_3.bag & 12 & 11 & 91.67\\ \hline     
     avenida\_4.bag &  4 & 4 & 100\\   
  \hline   \hline
  \end{tabular}
   \caption{Repetibilidade do algoritmo em vários percursos.}
  \label{tab:statistic}
\end{table}

\begin{figure}[h!]
\begin{center}
	\includegraphics[width=1\textwidth]{imagens/erro.eps}
\caption{Erro na leitura de valores do laser, devido à inclinação do carro.}
\label{fig:det_erro}
\end{center}
\end{figure}



\subsection{Módulo de deteção de diferentes condutores}\label{sec:modu_condu}

Como já anteriormente explicado no capítulo \ref{ch:det_driver}, dos seis ficheiros existentes para cada condutor quatro são utilizados para fazer uma base de referência que contém todos os descritores. 
O quinto ficheiro foi utilizado para a escolha dos melhores descritores. 

Deste modo foram feitas combinações dos 23 descritores 2 a 2 e 3 a 3, destas combinações foram escolhidas aquelas que mais destacam o condutor escolhido dos restantes, isto corresponde ao  valor máximo de P. Após a aplicação do algoritmo, chegou-se ás melhores combinações 2 a 2 e de 3 a 3 ilustradas na tabela \ref{tab:comb_3}, onde é possível reparar que os descritores 17 e 18, correspondentes ao pedal do acelerador estão sempre presentes.

Na figura \ref{fig:graf_combin}, está representada a variação do número de combinações calculada pelo algoritmo com a diminuição da variância dos descritores. De notar que a quantidade destes descritores é constante para valores de P superiores a 0,05.

\begin{figure}[h!]
\begin{center}
	\includegraphics[width=1\textwidth]{imagens/comb_2_3.eps}
\caption{Relação entre o número de combinações F e o número P, ou seja, a variância dos vários descritores utilizados.}
\label{fig:graf_combin}
\end{center}
\end{figure}



\begin{table}[h!]
\centering
 \begin{minipage}[t]{0.26\linewidth}
      \centering
\begin{tabular}{ c}
% \hline 
 \begin{math} k_i \end{math} = 3\\
   \hline \hline
     10 - 17 - 18 \\  \hline
     12 - 17 - 18 \\   \hline
     13 - 17 - 18  \\ \hline
     17 - 18 - 21  \\   
  \hline \hline
 \end{tabular}
  \end{minipage}
	 \hspace{0.7cm}
  \begin{minipage}[t]{0.26\linewidth}
      \centering
 \begin{tabular}{ c}
 \begin{math} k_i \end{math} = 2\\
   \hline \hline
     17 - 18  \\   
  \hline \hline
 \end{tabular}
 \end{minipage}
\caption{Conjunto das melhores combinações de $k_{i}$= 3 a 3 e $k_{i}$=2 a 2.}
\label{tab:comb_3}
 \end{table}



 Após o processo de validação das combinações escolhidas pelo algoritmo, como referido no final do capítulo \ref{ch:det_driver}; foi possível comprovar a veracidade da última das combinações arranjadas 3 a 3 ($k_i=3$), descartando assim o resto das combinações, inclusive a combinação com arranjos de $k_i=2$.
Esta combinação de descritores 17-18-21, corresponde ao número de vezes que o acelerador está premido com "força média-leve"\ e "muita força"\ e ao número de vezes que o travão está premido com força "leve-média" .



%Para validar as combinações presentes na tabela \ref{tab:comb_3} foi utilizado o sexto ficheiro. 
%Deste modo foram escolhidos os descritores correspondentes a cada linha de cada tabela, quer na base de referência quer no último ficheiro de teste e em seguida calculada a distância euclideana.
%Em seguida foi verificado se as combinações escolhidas pelo algoritmo continuavam a distinguir os diferentes condutores.
%O resultado desta última fase de testes revelou ser possível distinguir os três condutores com a última das combinações de \begin{math} k_i \end{math} =3 presente na tabela \ref{tab:comb_3}.

Estes resultados são bastante bons, contudo o reduzido número de amostras dita um processo de seleção de condutor algo limitado, pois dos 23 descritores disponíveis só foram feitos arranjos de 3 a 3 e 2 a 2 devido à reduzida quantidade de amostras recolhidas, não sendo por isso viável fazer o estudo para arranjos de descritores superiores a 3.

%face ao número de descritores total,




\section{Conclusões }\label{sec:fuot}


Os dois objetivos principais eram o desenvolvimento de dois módulos de Software.
Um com capacidade de identificar o condutor do veículo e outro capaz de detetar as situações de risco presentes durante o exercício da condução. Para que estes dois objetivos fossem atingidos foi necessário equipar o AtlasCar com módulos de hardware dignos de recolher dados do habitáculo do veículo, como descrito no capítulo \ref{ch:sis_monito_velo}. 

Desta forma, foram então desenvolvidos com sucesso as duas placas para os Arduínos, bem como o código para comunicar com os mesmos em Ambiente ROS. O Arduíno de monitorização da condução e o Arduíno de medição da velocidade do carro não apresentaram problemas de comunicação ou falha de envio de dados durante o processo de testes, fazendo deles uma excelente ferramenta de desenvolvimento para o projeto AtlasCar. O seu custo associado à sua robustez fazem dele a escolha ideal para este tipo de projetos.


Os resultados no algoritmo de deteção das diferentes situações de risco foram muito bons, na deteção das falhas dos indicadores luminosos ligados, na recompensa visual ao condutor pela manobra de ultrapassagem bem feita e por fim no aviso de risco de colisão.

Os resultados obtidos no módulo de reconhecimento do condutor mostram que é possível distinguir os três condutores utilizando apenas uma combinação de três descritores, bastando para isto monitorar os pedais do acelerador e travão do AtlasCar. Apesar de existir uma limitação em termos do número de bases de dados e indivíduos, o algoritmo está parametrizado de modo a que só seja necessário definir o número de ficheiros testes e indivíduos existentes, para posterior cálculo, não havendo necessidade de alterar o código.

O desenvolvimento dos diferentes módulos em ambiente \textit{R.O.S.} facilitou bastante a organização e integração de trabalhos desenvolvidos anteriormente por outros membros do projeto Atlas.



\section{Trabalho Futuro}

Com o desenvolvimento deste trabalho surge então uma nova frente de trabalho neste tipo de sistemas de apoio à condução;

\begin{itemize}

\item Desenvolvimento de módulos específicos para deteção automática de condutores do AtlasCar.% este tipo de módulos deveriam de funcionar com algoritmos mais robustos.

\item  Câmara traseira. A utilização deste sistema seria importante para fazer um levantamento dos tempos de colisão que outros condutores mantêm em média do nosso veículo.

\item Deteção de todos os sinais de trânsito existentes de modo a informar o condutor para o exato cumprimento da sinalização imposta.

\item Deteção dos limites da estrada, como o tipo de linhas presentes.



\end{itemize}





