\chapter{Conclusões e trabalho futuro}\label{chapter:conclusions}
\thispagestyle{myheadings}
% -------------------------------------------------------------
% intro
% -------------------------------------------------------------
The final conclusions of this dissertation will be detailed in this chapter, detailing the success or unsuccess of the initially proposed objectives. For future works, a wide range of proposals are detailed, to suggest future approaches to haptic rendering applications, enriched data logging, software solutions and hardware modification suggestions.
% -------------------------------------------------------------
% conclusions
% -------------------------------------------------------------
\section{Conclusions}\label{sec:conclusions}
The main objective of this dissertation was to develop a force feedback haptic control and sensing mechanism, aiming at robot perception~/~actuation data logging for learning purposes.

The proposed approach can effectively bridge together the robot teleoperation and kinesthetic teaching fields if the world and robot current state are correctly fed back to the user. With the introduction of more dedicated hardware, this approach will still maintain its validity, and naturally allow for a deeper and truer user immersion in haptic control.

It was also proposed the development of a robot SimMechanics simulator, so it would suit the purpose of a predictive and testing tool for locomotion and other intricate humanoid tasks. Although mechanically correct, it was verified that the SimMechanics simulator was not able to describe the dynamic behaviour of the hybrid actuation system, and requires an enormous effort to correctly build a humanoid robot as the PHUA robot.

It was found during the course of this work that the SimMechanics suite possesses yet another limitation for the simulation of the PHUA robot platform. Although the simulation of the dynamical behaviour of the ankle joints with the elastic elements in placed produced the expected results, the same cannot be said about the knee joint. When the knee flexes, the model solver sees the two end points of the spring becoming closer to each other, and so it assumes the spring is being pressed instead of pulled, producing erroneous results for the hybrid actuation system analysis.

Also, as this MATLAB toolkit does not provide any tool for calculating kinematics or perform any kind of trajectory planning within the models, it falls to the user to generate and feed that information into them, increasing the overall computational cost of the simulation (associated with MATLAB scripting) and diminishing the simulator's user-friendliness.

The servomotor wiring was deemed suitable, and it served the purpose without failing. The cable gauge chosen was enough to handle all testing runs without issues of note, and should hold future demands sufficiently well. The connector boards developed also performed well, without overheating. The locations chosen for the installation of these boards was also satisfactory, minimizing cable bending issues in the legs and not restricting the arms and torso's workspaces.

Concerning the mechanical parts for the analogue servomotor's immobilization, their performance was also deemed satisfactory. The parts installed on the arms were correctly machined, and hold the arm with a single pair of bolts. In the legs, however, although the servomotor immobilization was successful, the gripping mechanism is too thin and bends just with the gripping force from the bolt tightening. The part design was severely restricted by the robot geometry, and the choice of aluminium material was not ideal.

The introduction of new elastic elements to the structure was only significant in immobilizing the torso rotation joint servomotor. There were no visible changes in the servomotor actuation by the introduction of rubber bands in the ankle or hip joints. A coherent and valid test was not possible, but it is recommended nonetheless.

The position control method developed was considered successful. Although it fails to specify end-effector velocity vectors, the velocity can be controlled indirectly by the number of joint angle vectors fed per second. On the velocity control method, due to the velocity measuring problem, the method for the determination of the pen tip velocity is not as exact as the internal joystick controller would be, and due to the mean filtering, the calculated vector is slightly desynchronized from the current one and dampens accelerations. These limitations hinder the control by limiting it to low~/~medium velocity values and acceleration vectors. However, the velocity control method allows to navigate the entire workspace without adding a significant computational weight to the system, hinting towards the possibility of implementing an hybrid control method using inverse differential kinematics with a position incremented vector adjusted by a standard velocity magnitude.

On the PHANToM joystick, the low-level interaction implemented was considered to be very complete, but heavy on calculations and pre-processing routines, dropping the overall performance and thus the computing frequencies. On the testing computer, with an hardware as described on section \ref{sec:appendix_software_hardware}, the heaviest haptic rendering demonstration registered frequencies of approximately 500Hz, below the optimum value of 1kHz but still indistinguishable from the user's perspective if the incrementation of the vector's magnitude is controlled. The joystick data gathering routines alone could be performed at frequencies well above 1.5kHz while controlling the robot.

It was verified that the device can be further explored to enhance the operator's perception of the haptic environment. Although the device does not allow to render torques directly, it may be possible to have that effect emulated if the joystick control frequency is high enough. As the forces are applied on the wrist point, it would be possible to consecutively apply perpendicular forces vectors to the pen tip that would be felt by the user as applied torques, which would be useful for rendering inertial signals (forces and torques), for example.

The haptic demonstrations presented fitted the purpose of showing the potential of the approach but do not represent a final version. They are meant to be the precursors of those that will be used for the actual data logging, destined for the future of the platform.

On the workspace limitations demonstration, using custom force generation algorithms was successful for testing purposes, but these formulations are limited in user perception for a fully functional solution. The force generation expressions shown on this work represented an effort to emulate the solutions already offered by the OpenHaptics toolkit, but failed to meet their complexity and sharpened realism.

The same can be said for the transparent board drawing attempt. The force algorithms failed to offer a real object perception to an experienced user, but were satisfactory for the inexperienced users. The familiarization with these interfaces leads to a refined perception of the haptic object's geometry and other subliminal properties, like surface stiffness and texture.

The leg balancing demonstration presented is scarce in content due to the hardware limitations of the platform, but it never meant to represent an actual approach to the balancing problem. It was showed that rendering a force signal is a useful way to provide the user with a perception-based tool that complements the visual information obtained during the balancing data logging stage.

For all haptic-based human-robot interfaces, refining the underlying properties of the haptic objects and signals will ultimately be needed to enhance the user's perception of the virtualized robot world. Object states will require more advanced haptic signals, so that the user can learn to distinguish and prioritize them correctly when data logging, giving rise to the possibility that after the leaning process the robot does that distinction as well.

% -------------------------------------------------------------
% future work
% -------------------------------------------------------------
\section{Future work}\label{sec:future}
The work in this dissertation was the first of its kind in the PHUA project, therefore probing a number of fields that can now be thoroughly explored. Further, the experience acquired over the course the work allowed to gain a more incisive look on the platform's current issues of note. Future work recommendations are then hereby presented, subdivided by areas of interest, without ever forgetting the project's original goal of enriched data logging for robot learning, on walking and locomotion tasks.

\subsection{Simulation}\label{subsec:future_simul}
For future (dynamic) robot simulations, the \textit{V-REP} software (\url{www.v-rep.eu}) is strongly recommended. This software has a built-in support for \textit{ROS} nodes, automatic kinematics calculations, dynamic simulators, among several other characteristics.

If the \textit{SimMechanics} simulator is deemed appropriate, a different approach must be taken concerning the hybrid actuation. As is, the model is capable of simulating approximate results for the dynamic behaviour of the directly mounted servomotor limbs, as the arms. For the hybrid joint, that is not possible, and is recommended a study on the matter, looking into other \textit{Simulink} blocks that can be used to emulate the elastic elements impact on the motor's torque.

\subsection{Software}\label{subsec:future_software}

The full conversion of this work into the \textit{ROS} framework, allowing for a better development and integration of all the system in the platform, is highly recommend for the future of this project. Any work developed from that point on will largely benefit from all the \textit{ROS} embedded tools.

The developed application can be easily ported to \textit{ROS} and maintain it's full functionality, if required. The three thread logic can be expanded into \textit{ROS} nodes, and the shared data structure can easily become a \textit{ROS} message structure. In this sense, the most significant module to develop would be the robot base module, which takes care of the robot actuation and publishes the robot state messages. This would represent the stepping stone of the \textit{ROS} integration for the project. The joystick base module would also be an important step, along with Ethernet node-to-node communication, for it would mean that dual-device setups would be possible. With the current \textit{PHANToM} driver version, that is not possible.

The \textit{ROS} visualizing software \textit{Rviz} allows for a rapid deployment of visual information that is crucial to the development of any software solution for the platform. \textit{ROS}'s sensor integration will be a major fact for its introduction into the platform. In the future, inertial sensors in the structure, force sensors in the feet and a vision system in the head will allow measuring the centres of pressure for the whole system and will be later used to provide force feedback into the haptic tele-kinesthetic interface, so that the operator is able to ''feel'' the robot's dynamics, improving the data logged towards the goal of walking.

Unfortunately, there is no open-source solution for the low-level pc-to-device communication, other than the OpenHaptics suite, through the \textit{HDAPI}. Even within \textit{ROS} there is no alternative yet. The \textit{phantom\_omni} package uses the \textit{HDAPI} to implement a node that publishes a limited amount of information, but still does not provide the same level of hardware interaction as what was achieved in this work. However, exploring and improving this package may be suitable for the projects long term goals.

\subsection{Haptics}\label{subsec:haptics}
It is clear that haptics and haptic interfaces are the future heading of the PHUA humanoid robot towards the goal of autonomous balancing and locomotion. The presented haptic demonstrations were exploratory of the validity of the approach, but also of the existing programming solutions.

The force rendering schemes presented in this work were not able to provide a "real feel" to the demonstrations, but this can be solved by recurring to the haptic object algorithms that the OpenHaptics suite already possesses. These algorithms are recommended for correctly defining and refining the haptic surfaces and stiffnesses, for these aspects will not be the focus of future works, but merely means to an end. Alternatively, the open-source \textit{H3DAPI} libraries may be recommended for virtual environment creation. An aspect of notice in the OpenHaptics suite is their lack of support for Linux-based programming, which hindered this work heavily.

\subsection{Command}\label{subsec:future_control}

The velocity command methodology presented on this work was not able to establish a coordinate mapping between the joystick and the end-effector positions. The mechanism used, retrieving the joystick end point velocity vectors indiscriminately throughout the workspace, does not make it possible to do so.

In order to solve this issue, a new strategy was conceived that, due to time limitations, was unfortunately not implemented. It consisted of building what was named an haptic three-dimensional analogue velocity controller. This controller was built with a static haptic rigid sphere, with an anchor-point at its center, and filled on the inside by an attractor force field whose force magnitude is proportional to the travelled radius. The sphere surface represented a maximum velocity magnitude, and the anchor point in the middle represents a zero velocity value. Navigating inside this sphere means creating three-dimensional velocity vectors, scaled in magnitude by the travelled radius (felt as the force magnitude). This method allows the creation of dampened velocity vectors, with the user having complete control over their direction and magnitude. As the sphere is static inside the joystick workspace, there is no danger of reaching the joystick physical workspace limits, and thus leaving a margin for the development for an force feedback methodology for the velocity command of the PHUA robot.

\subsection{Hardware}\label{subsec:future_hardware}

On the mechanical aspects, it is still critical the review of the robot's belt and pulley transmission system. Some reductions, as the one on the ankle flexion joint, are too high for the type of belts available, causing the belt's polyurethane body to fail while the robot is in operation. These timing belts pass all the static criteria, and are able to hold the robot in position, but are not able to withstand the robot's dynamic torques for long. In that sense, it is again proposed a revision on the transmission systems of the platform, with a complete survey on available solutions for the belts, as performed on all past and current works on the platform.

The rubber bands that were used as elastic elements do not withstand long exposures to ultra-violet light and thus fail to achieve a satisfactory performance in terms of durability. As the platform still possesses some assembly~/~disassembly constraints, it becomes gruelling to keep replacing parts in the robot after a work session or minor testing run, or even after a few days idle. It is recommended the development of a conditioning or clustering method for the rubber bands, allowing them be easily replaced in bulk. This may allow to keep the low-cost and easiness of access of the rubber-bands as elastic elements.

Ultimately, the robot's torso joint system and structure will require mechanical modifications due to its overweight. It became clear during the course of this work that the leg motors are not capable of performing a wide variety of movements necessary for walking purposes, even though they succeed on maintaining static postures. On squatting, for instance, if the joint velocities are not well defined, the robot fails to return from the squat posture due to lack of torque in the ankle and hip joints.

Using the leg and hip system separated from the rest of the robot may also be a solution for gait training if this problem is not solved. The drawback is that the sensors in the feet will not record actual usable data for the whole assembled robot applications. Moving the battery set from the back to inside the robot torso may help reduce the upper body overweight issues, because it will move the robot's centre-of-gravity forward in the sagittal plane, thus modifying torque requirements in the legs.

If all else fails, reviewing the actuators may be a good endeavour, although of a more complex nature. There are solutions in the market for servomotor actuation without some of the restrictions of the current setup, and that would require small but possible mechanical modifications. Higher torques on the lower limbs would allow for wider operation ranges in full body motion patterns, and refined communication protocols could largely improve robot joint state scanning frequencies. These changes would undoubtedly mean the whole project would need to be reviewed, which would undoubtedly mean the development of a new robot. The cost-benefit relation of such a radical enforcement would have to be well studied and weight all the platform's current limitations versus the current potentialities and long term goals of the project.

Finally, a note is left regarding the robot power supply. Although dangerous by nature, the \textit{LiPo} batteries are superb for the robot power supply. However, it was determined that while in operation, they can drain very quickly and without previous notice, lowering their output voltage to very low, harmful, levels. As there is currently no mechanism to warn the operator of such event, it is proposed the installation of a small, affordable buzzer. These devices, which the battery manufacturers also supply, emit a loud buzz (sound signal) warning when the connected power source's voltage drops below a safety value. Furthermore, as the servomotors have specific power supply specifications, some buzzer models can be programmed to warn at specified levels, i. e., the servomotors minimum supply voltage.

During the course of this work, a 12V/20A DC power supply was acquired to serve the purpose of a tabletop power supply for workbench testing runs, in an effort to avoid unnecessary battery wear. Unfortunately, due to a shortage of DC-DC converters on the supplier that goal was not achieved. In that sense, the completion of this workbench power supply could prove to be an invaluable tool for future works, and it is thus recommended.
\clearpage
~\\
\thispagestyle{empty}