\chapter{Experimental Setup}\label{chapter:setup}
\thispagestyle{myheadings}
% -------------------------------------------------------------
% intro
% -------------------------------------------------------------
In this chapter, the primary hardware and software setup that was necessary for the implementation of the haptic demonstrations is presented, detailing the servomotor wiring scheme, mechanical modifications introduced and the chosen haptic joystick and programming libraries. When this work was initiated, the PHUA platform robot could not accommodate the desired implementation for haptic teleoperation and data logging. Some hardware issues were undefined and had to be resolved to allow a correct software implementation.
% -------------------------------------------------------------
% servo comms
% -------------------------------------------------------------
\section{Servomotor Wiring and Communication}\label{sec:alter_servo_comm}
One challenge in this work was to come up with a solution for the robot actuation wiring and communication. Some solutions were already explored before \cite{ribeiro_desenvolvimento_2010, lage_algoritmos_2011}, based on distributed control architectures, but unfortunately none of them were installed as a final version. The implementation of a low-level hardware control system for the whole robot was not an objective of this dissertation, so another alternative had to be devised.

The HITEC servomotors possess a proprietary protocol called \textit{Hitec} \textit{Multi-Protocol} \textit{Interface} (HMI), that allows communication to be established in three different modes \cite{ribeiro_desenvolvimento_2010}:

\begin{itemize}\itemsep3pt \parskip1pt \parsep1pt
\item \textit{Standard Pulse}
\item \textit{Extended Pulse}
\item \textit{Bidirectional Serial Interface}
\end{itemize}

The first two are \textit{PWM} based communication protocols, requiring dedicated hardware. The \textit{Bidirectional Serial Interface} is an RS-232 based communication, using a 7 byte command frame represented on Table \ref{table:setup_servocomm_bsi2}, configured as the Table \ref{table:setup_servocomm_bsi1} shows. The last 2 bytes of the word contain the answer from the servomotor controller. Different answers from multiple servos on one communication line will result in a bus collision. This type of communication allows not just the position and velocity command of the servomotor, but also its internal programming.

{\centering
\begin{table}[H]
\caption[The HITEC BSI RS-232 7 byte word.]{The HITEC \textit{BSI} RS-232 7 byte word \cite{ribeiro_desenvolvimento_2010}.}
\label{table:setup_servocomm_bsi2}
\centering
{\small
\begin{tabular}{c|c|c|c|c|c|c|c}
\hline
\textbf{byte} & 1 & 2 & 3 & 4 & 5 & 6 & 7\\ 
\hline
\textbf{Controller} & Startbyte & Command & Param1 & Param2 & Checksum & 0x00 & 0x00\\
\hline
\textbf{Servomotor} & \multicolumn{5}{|c|}{High-Impedance} & Return1 & Return2\\
\hline
\end{tabular}}
\end{table}}

The checksum byte adds up the sum of bytes 1 through 4 to a multiple of 256, as shown on expression \eqref{equation:checksum}:

\begin{equation}
Checksum = 256 - \left(0x80 + Command + Param1 + Param2\right)\:\%\: 256
\label{equation:checksum}
\end{equation}

{\centering
\begin{table}[H]
\caption[The HITEC BSI RS-232 configuration.]{The HITEC \textit{BSI} RS-232 configuration \cite{ribeiro_desenvolvimento_2010}.}
\label{table:setup_servocomm_bsi1}
\centering
\begin{tabular}{c|c}
\hline
\textbf{Parameter} & \textbf{Value}\\ 
\hline
Baudrate & 19200\\
\hline
Data Bits & 8\\
\hline
Stopbits & 2\\
\hline
Parity & (none)\\
\hline
Handshake & (none)\\
\hline
\end{tabular}
\end{table}}

These servomotors perform their own motion control, having the low-level control already implemented in the Atmega micro-controller circuit inside their casing. The controller's trajectory planner generates a linear trajectory (constant angular velocity) starting from the last trajectory set point $p_0$ to the actual target position $p_1$, using the input position,defined in an integer range of 1800 positions [600-2400], and the velocity value, defined in an integer range from 1 to 255, it receives. The control loop then ensures the motor reaches the desired position by monitoring its error value. The planned trajectory parameters are stored in a different memory block from the one used for planning. This different block is read by the PD controller at every control loop to define the motor PWM pulse. This mechanism assures the trajectory can be changed at every loop without having to stop the motor, allowing for continuous operations.

\begin{figure}[H]
  \centering
    \includegraphics[width=0.49\textwidth]{Imagens/servo_controller.png}
	\includegraphics[width=0.49\textwidth]{Imagens/trajectory_planning.png}
  \caption[Servomotor controller motion control and trajectory planner.]{Servomotor controller motion control (left) and trajectory planning (right) (adapted \cite{ribeiro_desenvolvimento_2010}).}
  \label{fig:setup_motion_control}
\end{figure}

Closed-loop customized motor control is difficult with the current hardware. There was already a distributed control architecture strategy presented in a previous work \cite{ribeiro_desenvolvimento_2010} that tried to compensate this with local micro-controller units actuating small clusters of servomotors and communicating between them through a CAN type protocol.

It was decided that, having the possibility to define a unique identification number (ID) for each digital servomotor, the best solution was to implement a single direct line to connect all digital servomotors using the \textit{BSI} protocol for communications. However, this had the inconvenient of leaving out the analogue servomotors, since they require dedicated hardware. As it would be very time-consuming to make the hardware structure necessary to include those motors in the line, for this dissertation it was decided to drop those DOFs, and work with all the others. Further, using a digital protocol also meant that the low-level control of the servomotors was definitely set-aside for the work, and any commanding methodology had to take into account the controller's trajectory generator limitations.

The servomotor programming was conducted using the ''HMI Servo Programmer'' software, supplied by HITEC (for Windows 32bits). It defined the whole robot's ID number logic, depicted in Figure \ref{fig:setup_servocomm_ids}, as well as the reset of their internal controller to the factory defaults, so it could be tested for optimal performance. The numbering logic defines a range of numbers specific for each limb, so that the ID number quickly identifies the joint. With this method it is also possible to introduce new servomotors in the platform without major modifications to the control structure.

\begin{figure}[H]
  \centering
    \includegraphics[height=95mm]{Imagens/ids.jpg}
  \caption[Servomotor identification numbering.]{Servomotor ID numbering.}
  \label{fig:setup_servocomm_ids}
\end{figure}

The servomotor internal controller can be configured in terms of proportional and derivative gains parameters (\textit{P-Gain} and \textit{D-Gain}) as well as their \textit{Dead Zone} parameter. The proportional gain defines the speed and acceleration properties of the motor, and the derivative gain defines the servomotor's stopping behaviour. A small current consumption test showed that carrying heavy loads over great distances made the motors consume a considerable current. As advised by the manufacturer in the data sheets, the gain parameters were set to the their lowest setting in the controllers to avoid damage and wear throughout the course of the works. The \textit{Dead Zone} parameter defines the inactive range of a stop point, or the ''still tolerance''. There was no noticeable change while varying this parameter, and it was decided to keep it to the lowest setting, again for servomotor preservation reasons.

To allow for the platform's mobility, this common line had to be installed on the robot and not restrain any DOF. Thus, it was decided to design small connector boards where the servomotors could be easily plugged/unplugged. These boards were then placed on each leg, on the trunk and on the shoulders, connecting all the servomotors together. These boards, as well as the connection diagram \cite{ribeiro_desenvolvimento_2010}, are depicted on Figure \ref{fig:setup_servocomm_line_boards}.

\begin{figure}[H]
  \centering
  \includegraphics[width=0.4\textwidth]{Imagens/comm_scheme}\hspace{1mm}
  \includegraphics[width=0.4\textwidth]{Imagens/shoulder_connector}\\\vspace{2mm}
  \includegraphics[width=0.39\textwidth]{Imagens/leg_connector}\hspace{2mm}
  \includegraphics[width=0.4\textwidth]{Imagens/belly_connector}
  \caption[The servomotor line connection diagram and connector boards.]{The servomotor line connection diagram \cite{ribeiro_desenvolvimento_2010} and connector boards.}
  \label{fig:setup_servocomm_line_boards}
\end{figure}

Using the HITEC servomotor connection scheme, another small board was designed to connect the RS-232 connector and the power line to the robot's common line. These parts are represented in Figure \ref{fig:setup_servocomm_scheme_board}. 

\begin{figure}[H]
  \centering
    \includegraphics[width=0.4\textwidth]{Imagens/comm_board}
  \caption{The designed servomotor communication converter board.}
  \label{fig:setup_servocomm_scheme_board}
\end{figure}

The common line allows for full robot control, with the exception of the analogue motors, and the connector board allows to separate the power line from the RS-232 communication line. It is also possible to control any kinematic chain separately, or a single servomotor, if necessary. The cables installed on the platform are not definitive and will require maintenance in the future, although perfectly fitting the purpose of testing.

% -------------------------------------------------------------
% Mechanical changes
% -------------------------------------------------------------
\section{Mechanical Modifications}\label{sec:alter_mech_parts}
Due to the wiring solution, the analogue servomotors on the arms and in the thighs were left unactuated. In order to stabilize them, it was decided to take one of two possible solutions: to power up the servos at zero position or to mechanically immobilize them. The later was the choice, given that it was unpredictable if the static torque of the analogue motors was enough to support the internal forces of the limbs while in operation, besides the fact that being powered up could eventually deteriorate them. So, the solution was to design small parts to restrain those DOFs and avoid possible problems. These parts, represented in Figure \ref{fig:setup_mech_pecas_cad}, were initially developed to be of low mass/dimensions, so that the limb's inertia matrices were not affected by them. However, the robot's dimensional restraints and the assembly/disassembly problems of the platform conditioned the design to its final geometry and position.

\begin{figure}[H]
  \centering
    \includegraphics[width=0.85\textwidth]{Imagens/pecas_teste}
  \caption{Designed parts for the servomotor fixation.}
  \label{fig:setup_mech_pecas_cad}
\end{figure}

As the parts in the arms were developed with a considerable volume, the choice in material was made of aluminium. Although this material allowed for a small mass in the arm parts, it made the legs component frail around the bolt tightening phalanx. Even though the leg parts are slightly deformed, their mechanical performance is the same, and no problems are to be expected from al the parts while the robot is in operation. The mechanical drawings for the designed parts, shown Figure \ref{fig:setup_mech_parts_installed}, are submitted on Appendix \ref{appendix_mech_drawings}.

%\begin{figure}[H]
%  \centering
%    \includegraphics[width=0.325\textwidth]{Imagens/arm_part}
%    \includegraphics[width=0.325\textwidth]{Imagens/arm_part2}
%    \includegraphics[width=0.325\textwidth]{Imagens/leg_part}
%  \caption{Designed parts installed on the robot.}
%  \label{fig:setup_mech_parts_installed}
%\end{figure}
\begin{figure}[H]
        \centering
        \begin{subfigure}[b]{0.32\textwidth}
                \centering
                \includegraphics[width=\textwidth]{Imagens/arm_part}
                \caption{}
                \label{fig:arm_part}
        \end{subfigure}
        %add desired spacing between images, e. g. ~, \quad, \qquad etc. 
          %(or a blank line to force the subfigure onto a new line)
        \begin{subfigure}[b]{0.32\textwidth}
                \centering
                \includegraphics[width=\textwidth]{Imagens/arm_part2}
                \caption{}
                \label{fig:arm_part2}
        \end{subfigure}
        %add desired spacing between images, e. g. ~, \quad, \qquad etc. 
          %(or a blank line to force the subfigure onto a new line)
        \begin{subfigure}[b]{0.32\textwidth}
                \centering
                \includegraphics[width=\textwidth]{Imagens/leg_part}
                \caption{}
                \label{fig:leg_part}
        \end{subfigure}
        \caption[Designed parts installed on the robot.]{Designed parts installed on the robot, for the arms on the left and middle, and for the legs on the right.}\label{fig:setup_mech_parts_installed}
\end{figure}

% -------------------------------------------------------------
% rubber band changes
% -------------------------------------------------------------
\section{Elastic Elements Review}\label{sec:alter_elastic}
In the previous works on this platform \cite{sabino_estrutura_2009, ribeiro_desenvolvimento_2010, godinho_desenvolvimento_2011, lage_algoritmos_2011}, there was no indication  left about the mounting of the elastic elements of the ankle and hip joints elastic elements. Although there was some calculations regarding the mounting of the trunk and knee's rubber bands, no indication was given for any other joint or joint groups. The review of these mechanical elements was not an objective for the dissertation, but it quickly became clear that the experience gained over the course of this work was an interesting addition to the project's documentation.

The previous work and solutions on the mounting of these elements was not significantly altered, as the goal was to improve the current implementation. For that, the rubber band mounting on the knee flexion joint and on the trunk's flexion and lateral flexion joints was initially performed as previously defined.

On the robot's ankle flexion/extension and abduction/adduction joints, the mounting points were all previously defined, but were not tested. The placement of the rubber bands proved successful on maintaining the joint around it's home position, with the servomotors powered down, and with no apparent stress induced on them while in operation. Figure \ref{fig:setup_elastic_ankle} shows the rubber bands mounting on the ankle.

\begin{figure}[H]
  \centering
    \includegraphics[width=0.49\textwidth]{Imagens/ankle_elastics_1}\hspace*{3mm}
    \includegraphics[width=0.48\textwidth]{Imagens/ankle_elastics_2}
  \caption{Elastic elements on the robot's ankle joints.}
  \label{fig:setup_elastic_ankle}
\end{figure}

New mounting points had to be created to apply the rubber bands on the hip flexion/extension and abduction/adduction joints, in order to fulfil the goal of the hybrid actuation system. As there was very little geometric/dimensional margin for a mechanical modification, the solution was to remove some screws and replace them with metric screw hooks, similarly to what had been done before in trunk \cite{godinho_desenvolvimento_2011}, as shown in Figure \ref{fig:setup_elastic_hip}.

However, the results were not satisfying. It was observed that, when the tested courses started on a joint limit (where the elastic force is greater), the joints accelerated up to a point were the servomotor could no longer stop at its destination point, due to lack of stopping torque. Diminishing the number of rubber bands was not a good solution either, for their presence became redundant due to very low exerted force.

The torques developed on these joints make the hybridization very complex. A simple approach as the one taken is not sufficient to assure the rubber band's force vector is applied in favour of the energy minimization required. It is necessary to achieve a compromise between the rubber bands stiffness and the increase in joint torques.

\begin{figure}[H]
  \centering
    \includegraphics[height=58mm]{Imagens/hip_elastics_1}\hspace*{5mm}
    \includegraphics[height=58mm]{Imagens/hip_elastics_2}
  \caption[Elastic elements on the robot's hip joints.]{Elastic elements on the robot's hip joints, viewed from the front (left) and from the back (right).}
  \label{fig:setup_elastic_hip}
\end{figure}

As for the trunk joints, there was considerable amount of testing done, because of their critical nature on the robot's self balancing tasks, or even for it's operation while standing still. The first event of notice was the failure of the flexion/extension joint (forward/backward torso tilting). Due to the overweight of the upper-body (chest + head + arms), the servomotor assigned to this joint is severely under-dimensioned and fails to tilt the torso at any position or posture. The natural outcome is that the task of maintaining the torso upright falls completely on the elastic elements. The overweight problem was the result of unpredicted mechanical insertions to the upper-body \cite{godinho_desenvolvimento_2011} combined with a small margin in design tolerance after the design of the leg system \cite{sabino_estrutura_2009}.

In this sense, the solution determined was to over-supply the trunk's joints with rubber bands in such a way that they would remain almost locked. The trunk's lateral flexion motor has enough torque to move itself around 10\degup, at most upright postures, so the rubber bands must not restrict it in that range. As for the torso rotation joint, the low-end servomotor installed (see Table \ref{table:sota_phua_dofs}) fails to rotate the joint more than a mere 5\degup due to its lack of torque.

As the Figure \ref{fig:setup_elastic_trunk} shows, the final solution is able to maintain the joints around the robot's home position, even with a small tilting. Unfortunately, rapid movements or big tilts are not possible with this strategy due to the intrinsic nature of elastic elements and the robot's upper-body overweight problem.

\begin{figure}[H]
  \centering
    \includegraphics[height=60mm]{Imagens/trunk_elastics_1}\hspace*{5mm}
    \includegraphics[height=60mm]{Imagens/trunk_elastics_2}
  \caption[Elastic elements on the robot's trunk joints.]{Elastic elements on the robot's trunk joints.}
  \label{fig:setup_elastic_trunk}
\end{figure}
\clearpage
% -------------------------------------------------------------
% the haptic device
% -------------------------------------------------------------
\section{The Haptic Device}\label{sec:setup_haptic_device}
The haptic device used in this work is a SensAble PHANToM OMNI haptic joystick, as shown in Figure \ref{figure:phantom_omni_dofs}, which is a 6DOF impedance-based joystick capable of rendering three-dimensional force vectors at high frequencies. The OMNI model connects to the PC \textit{via} IEEE-1394a (\textit{FireWire}) ports and it can be connected in chain to another identical equipment. This equipment requires proprietary drivers to function properly, with specific requirements and dependencies that must be met. Therefore, its installation procedures are described in detail in Section \ref{sec:appendix_software_pdd} for future reference.

\begin{figure}[H]
  \centering
    \includegraphics[width=0.6\textwidth]{Imagens/montagem_phantom.png}
  \caption[The PHANToM OMNI device used and its six degrees-of-freedom.]{The PHANToM OMNI device used and its six degrees-of-freedom.}
  \label{figure:phantom_omni_dofs}
\end{figure}

Although the device possesses 6DOF, from which it is possible to retrieve a correspondent three-dimensional Cartesian position, only three of these are active (actuated) joints, meaning it is only possible to render force vectors and not possible to render torques (directly) with the last 3DOF. This is mainly due to its mechanical construction. This device is built with a capstan drive actuating two out of three base degrees-of-freedom, as the Figure \ref{fig:phantom_omni_capstan} illustrates, allowing for its compact form-factor and good force feedback level on its actuated workspace, coupled with high precision optical encoders. The last three DOFs are unactuated joints equipped with potentiometers, allowing for a compact mounting. A more extensive list of specifications is shown on Table \ref{table:phantom_specs}.

\begin{figure}[H]
  \centering
    \includegraphics[width=0.65\textwidth]{Imagens/phantom_capstan}
  \caption[The PHANToM OMNI capstan drive mechanism illustration.]{The PHANToM OMNI capstan drive mechanism illustration \cite{silva_phantom_2009}.}
  \label{fig:phantom_omni_capstan}
\end{figure}

Before exploring the software solution offered by SensAble, the kinematics and manipulability of the device were consulted \cite{silva_phantom_2009}, to determine the possibility of developing a in-house control method for the device, avoiding proprietary libraries . However, it quickly became clear that implementing a such low-level control offered no real advantage to this work. The software supplied by SensAble, described ahead on Section \ref{sec:setup_openhaptics}, is well endowed with quickly deployable solutions to address the device's control.\\

%% start of table
\begin{table}[H]
\caption[PHANToM OMNI device specifications.]{PHANToM OMNI device specifications \cite{_phantom_2008}.}
\label{table:phantom_specs}
\centering
\begin{tabular}{c|c}
\begin{tabular}{c}
\textbf{Force Feedback}\\
\textbf{Workspace}\\
\end{tabular}
&
\begin{tabular}{c}
160 W X 120 H X 70 D [mm]\\
\end{tabular}\\ 
\hline
\begin{tabular}{c}
\textbf{Footprint}\\
(Physical area the base\\
 of the device occupies)\\
\end{tabular}
&
\begin{tabular}{c}
168 W x 203 D [mm]\\
\end{tabular}\\
\hline
\begin{tabular}{c}
\textbf{Weight}\\
(device only)\\
\end{tabular}
&
\begin{tabular}{c}
3 lb 15 oz\\
(aprox. 1.786 kg)\\
\end{tabular}\\
\hline
\textbf{Range of Motion} & 
\begin{tabular}{c}
Hand movement\\
pivoting at wrist\\
\end{tabular}\\
\hline
\begin{tabular}{c}
\textbf{Nominal}\\
\textbf{Position Resolution}\\
\end{tabular}
& 
\begin{tabular}{c}
450 dpi\\
(aprox. 0.055 mm)\\
\end{tabular}\\
\hline
\begin{tabular}{c}\textbf{Backdrive}\\\textbf{Friction}\end{tabular} & 0.26 N\\
\hline
\begin{tabular}{c}
\textbf{Maximum}\\
\textbf{Exertable Force}\\
(at nominal position)\\
\end{tabular}
&
\begin{tabular}{c}
3.3 N\\
\end{tabular}\\
\hline
\begin{tabular}{c}
\textbf{Continuous}\\
\textbf{Exertable Force}\\
(24 hrs.)\\
\end{tabular}
&
\begin{tabular}{c}
0.88 N\\
\end{tabular}\\
\hline
\textbf{Stiffness} &
\begin{tabular}{c}
X axis : 1.26 N/mm\\
Y axis : 2.31 N/mm\\
Z axis : 1.02 N/mm\\
\end{tabular}\\
\hline
\begin{tabular}{c}
\textbf{Inertia}\\
(apparent mass at tip)\\
\end{tabular} &
\begin{tabular}{c}
45 g\\
\end{tabular}\\
\hline
\begin{tabular}{c}\textbf{Force}\\\textbf{Feedback}\end{tabular} & x, y, z\\
\hline
\begin{tabular}{c}
\textbf{Position Sensing}\\
(with stylus gimbal)\\
\end{tabular}
&
\begin{tabular}{c}
- x, y, z\\
(digital encoders)\\
- roll, pitch, yaw\\
($\pm$5\% linearity potentiometers)\\
\end{tabular}\\
\hline
\textbf{Interface} &
\begin{tabular}{c}
IEEE-1394 FireWire port\\
(6-pin to 6-pin)\\
\end{tabular}
\end{tabular}
\end{table}
%% end of table
\clearpage

% -------------------------------------------------------------
% openhaptics
% -------------------------------------------------------------
\section[OpenHaptics Toolkit]{OpenHaptics Toolkit}\label{sec:setup_openhaptics}
Developed in \textit{C/C++}, the OpenHaptics toolkit is the proprietary programming solution offered by SensAble to build haptically enabled applications. Currently on version 3.0 and available for Linux, Windows and MacOS X operating systems, it includes \cite{_programmers_2008, _api_2008}:

\begin{itemize} \itemsep2pt \parskip1pt \parsep1pt
\item QuickHaptics micro API;
\item Haptic Library API (HLAPI);
\item Haptic Device API (HDAPI);
\item PHANTOM Device Drivers (PDD);
\item Utilities;
\item Source code examples;
\item Documentation.
\end{itemize}

The typical application structure under OpenHaptics is depicted in Figure \ref{fig:openhaptics_scheme}. Its usual implementation points towards object virtualization and virtual environments (VE), usage for which it is exceptionally well prepared. Due to its long installation procedures, the relevant steps are described in detail in Section \ref{sec:appendix_software_pdd} for future reference.

\begin{figure}[H]
  \centering
    \includegraphics[width=\textwidth]{Imagens/scheme_openhaptics}
  \caption[A typical OpenHaptics application structure.]{A typical OpenHaptics application structure \cite{_programmers_2008}.}
  \label{fig:openhaptics_scheme}
\end{figure}

Benefiting from the advances in this research field over the later years, these toolkits allow to ease programming by encapsulating the some of the steps common to all haptics/graphics applications in the \textit{C++} classes of the QuickHaptics micro API, making use of the Standard Template Library (STL). By anticipating typically used scenarios and using built-in geometry parsers and intelligent default parameters, it is possible to set up haptics/graphics scenes with a minimal amount of code.

The HLAPI is designed for high-level haptic rendering and it is designed to be familiar to OpenGL API programmers. It is targeted for advanced OpenGL developers who are less familiar with haptics programming, but desire to quickly and easily add haptics to existing graphical applications.

The HDAPI (the most explored in this work) is the foundational layer for haptics, providing low-level access to the haptic device. It is best suited for developers who are already familiar with haptic paradigms and have to send forces directly. It enables haptics programmers to render forces directly, offers control over configuring the runtime behavior of the drivers and provides convenient utility features and debugging aids. Experts can
still use HLAPI and HDAPI in conjunction with QuickHaptics to take advantage of all SDKs.

The HDAPI requires the developer to manage direct force rendering for the haptic device, whereas HLAPI handles the computations of haptic rendering based on geometric primitives, transforms, and material properties. Direct force rendering with HDAPI requires efficient force rendering/collision detection algorithms and data structures coding. This is due to the high frequency of force refreshes required for stable closed-loop control of the haptic device.

The HLAPI prevents the developer from having to implement efficient force rendering algorithms and managing the synchronization of servo loop thread-safe data structures and state. The servo loop refers to the tight control loop used to calculate forces to send to the haptic device. In order to render stable haptic feedback, this loop must be executed at a consistent 1 kHz rate or higher. In order to maintain such a high update rate, the servo loop is generally executed in a separate, high priority thread. This thread is referred to as the servo loop thread \cite{_programmers_2008}.

Diagram \ref{fig:openhaptics_diag} illustrates the relationship between the QuickHaptics micro API and the existing HD and HL layers of OpenHaptics.\\[8mm]

\begin{figure}[H]
  \centering
    \includegraphics[width=0.95\textwidth]{Imagens/diag_quickhaptics}
  \caption[The OpenHaptics structure diagram.]{The OpenHaptics structure diagram \cite{_api_2008}.}
  \label{fig:openhaptics_diag}
\end{figure}\clearpage
% -------------------------------------------------------------
% ROS
% -------------------------------------------------------------
\section[ROS Framework]{\textit{ROS} (Robot Operating System) Framework}\label{sec:setup_ROS}
Even though it was not in the original objectives, specific components of this work are running under the \textit{Robot Operating System} (ROS) framework. Created in 2007, ROS started as an open-source programming platform for robots, designed for the development of the Stanford Artificial Intelligence Robot project (STAIR) \cite{quigley_stair:_2007}. The platform is now maintained by the open-source community and Willow Garage, responsible for the Personal Robots Program (PR/PR2 robots). ROS was created with the intent of fulfilling a series of objectives \cite{quigley_ros:_2009}:

\begin{itemize}\itemsep5pt \parskip2pt \parsep2pt
 \item Build a lightweight and robust operating system;
 \item Ease modular software deployment;
 \item Build a free and open-source platform;
 \item Supply tools for code implementation as a configuration parameter server, message viewer, documentation auto-generation, etc \ldots;
 \item Multi-lingual (currently \textit{C++}, \textit{Python}, \textit{Octave} and \textit{LISP});
 \item Support for \textit{peer-to-peer} connections.
\end{itemize}

Designed to run under Unix/Linux, ROS eases the interaction of hardware and software, using a modular architecture. This architecture allows the creation and management of software modules and assures the communication between them in a very well structured and robust form. The platform is organized in \textit{nodes}, \textit{messages}, \textit{topics} and \textit{services}  \cite{quigley_ros:_2009}.

The \textit{nodes} are processes that compute the system, being part of the software modules. With this modular architecture, these processes need to communicate among them. This communication is made by means of \textit{messages}, which are data structures with the respective languages primitive data types which can be recorded in logs. An interesting fact about ROS is that the data in these logs can be later reproduced as if the real system is online, making it possible to record real world events and develop code for them in the laboratory with real event data playback information.

However, for a module to subscribe (or publish) a message, it must know its ''name'', called a \textit{topic}. It is possible to have several ROS nodes that subscribe or publishe the same topics, or one node that does it for several topics, so in the ROS constitution we find \textit{services}, which are synchronous transactions ''watchers''. They prevent the wrong node from getting the wrong message at the wrong time.

For humanoid robots, ROS hardware abstraction and low-level device control, are very handy tools, saving up the strenuous task of programming low-level functions for kinematics, dynamics, sensor/actuator communication, etc \ldots

ROS is an asset of invaluable worth in the programming of robots. Although it may not be the best solution overall, it is certainly the best documented due to the large online community and the distribution under a \textit{BSD} license (permissive free software license). The ROS community creates and maintains software repositories for drivers and algorithms, making the software very flexible and malleable to a variety of systems.

The inclusion of ROS in the PHUA project will represent the next milestone completed. In that sense, after having tested some of preliminary versions of this work's systems, it was decided that using ROS would allow for a more efficient robot system construction and maintenance. The software developed in that sense is fully described in Chapter \ref{chapter:demos}. The ROS tool ''RViz'' was used to create graphical visualizations of the haptic environments, the robot/joystick frames and other debugging constructions.

%\clearpage
%~\\[5mm]
%\thispagestyle{empty}