























\subsection{The MIR-Vehicle}
The motor control module takes care of the low-level motor control tasks such as counting a motor encoder’s signal pulses and sending motor driving Pulse Width Modulation (PWM) signals. The laptop does all the high-level computational service, reads the data from sensor packages using ROS nodes, and runs all algorithms created for testing on the platform. A schematic diagram of the architecture of the MIR Vehicle platform is shown in Fig.~\ref{fig-mir-vehicle-architecture}. This research platform supports hierarchical, modular, and scalable design. Each component is discussed in the following sections in more details. The platform is based on ROS compatible packages using Python. The ROS provides a distributed computing environment by which all communication between components in the system is seamlessly possible. The MIR Vehicle platform offers capabilities to develop perception and control algorithms and deploy them to a vehicle model. Sensor packages are connected via a USB port to a laptop computer in which perception and control algorithms execute. The laptop computer hosts the ROS core that is a meta package to aggregate the packages required to use publish and subscribe services. A ROS node runs in the motor control module to receive control messages from the main computer and send the information of encoders to the ROS nodes in the laptop computer. More details will be given in the Software Design Overview section. The motor control unit takes care of motor driving and feedback of the motors using the encoders. Two motor controllers are used to handle two DC motors. Also, two microcontrollers are deployed to the unit to count motor revolutions. One of them is used to execute a ROS node that sends encoder values to and receives commands from the laptop computer.

\input{fig/mir-vehicle-architecture.tex}

\subsection{Car Platform}
Several considerations were made in the car platform selection. First, the ride-on-car must be large enough to hold a GPU enabled laptop computer with sensors and small enough to be easily carried. Second, steering and driving must be able to be controlled by PWM signals. Third, there must be enough space where encoders can be installed to measure both the angles of the steering wheel and the speed of the driving motor. Our choice of car is the electric ride-on-car from \citet{bmw-z4-roadster_bmw_2009}. The product dimension is 1.11 x 0.57 x 0.47 meters. The weight is 14.15 kg. The wheel’s diameter is 0.2 meters. The maximum speed is 1.12 m/s. The maximum load is 30 kg. The driving motor is DC 6 V, 25 Watt. The original battery is 6 V and 7 Ah. We replaced the battery with two separate batteries: a 9 V, 2000 mAh battery for the driving motor and a 9 V 600 mAh battery for the steering wheel motor to separate power source for each motor. Using two separate batteries are beneficial since they are lighter than the original battery and easier to recharge.

\subsection{Mechatronics Design}
The transformation process of the ride-on-car into an autonomous ROS based platform requires both mechanical and electrical adjustments. 

\subsubsection{Mechanical Design}
We designed a windshield replacement that is used to hold sensors and wiring harness. Additional electric wires from motors to the two motor drivers must be connected. The rigid acrylic fixtures are used to hold sensors as well as the motor control box. The laptop computer holder is also necessary to have a stable position for the laptop computer. See Fig.~\ref{fig-rigid-acrylic-fixtures} for more details. 

\input{fig/rigid-acrylic-fixtures.tex}

Both driving and steering gearboxes are required to be modified. We examined each of the gearboxes and modified them to properly read the motor rotations. A 17 teeth spur gear was attached to each shaft of the encoders. The exact position of the spur gear in the encoder shaft is as follows. For the steering, the spur gear must be affixed with a 7 mm gap from the encoder outer casing. The spur gear is mounted, for the driving encoder, with no gap from the casing. See Fig.~\ref{fig-spur-gear-assembled} for more details.

\input{fig/spur-gear-assembled.tex}

\paragraph{Gearbox Modification}: The modified gearboxes are shown in Fig.~\ref{fig-gearbox-open}. These two gearboxes are in different positions in the vehicle. Due to the limitation of space, the position of the encoder gear’s teeth must be carefully chosen. The following sections have the details of it.

\input{fig/gearbox-open.tex}
The steering motor gearbox modification is relatively simple for the steering motor gearbox since there is enough room around the steering wheel shaft. We made a hole in the top center of the gearbox to affix the encoder to the largest gear in the gearbox. See Fig.~\ref{fig-gearbox-steering-modification} for more details. 

\input{fig/gearbox-steering-modification.tex}
The driving motor gearbox needed a support structure. Due to the close distance between the driving wheel and gearbox, there was no space to place the encoder. A support fixture was designed and attached to the gearbox as shown in Fig.~\ref{fig-gearbox-drive-modification} and Fig.~\ref{fig-gearbox-drive-support-fixture}. A rear wheel is affixed to the hole via a shaft, and this blocks most of the gearbox. Not enough space is available to affix the motor encoder in the driving motor gearbox. Thus, we designed a fixture to hold the encoder that can be affixed to a gear inside the gearbox.

\input{fig/gearbox-drive-motification.tex}
\input{fig/gearbox-drive-support-fixture.tex}

\subsubsection{Electrical Design}

\paragraph{Encoders}: 
The ride-on-car is equipped with two electrical brushed motors. One motor is attached to the rear-left wheel and controls vehicle speed (Fig.~\ref{fig-encoder-drive-attached}), and the other attached to the steering wheel controls the direction of the vehicle (Fig.~\ref{fig-encoder-steering-attached}). To read the current speed and the direction of the car, two incremental encoders are attached to each of the motors. We used an incremental rotary encoder with a 6 mm shaft that has 600 pulses per revolution \citep{hn3806-ab-600n_hn3806-ab-600n_2016}. The size of the encoder is 38 x 35.5 mm and its shaft size is 6 x 13 mm. The size is small enough to be located in the gearbox of the driving motor and the shaft length is long enough to reach to the gears in the original gearbox. We implemented a quadrature decoder to convert the encoder signals into the direction and count. 

\input{fig/encoder-steering-attached.tex}
\input{fig/encoder-drive-attached.tex}

\paragraph{Microcontroller}:
Instead of using a high-performance microcontroller, we chose to use two Arduino Uno’s since it has a broad user community and simplicity of the use. Each of the microcontrollers is responsible for reading pulses from the incremental encoder since one microcontroller has only two interrupt pins that read Phase A and B signals from one encoder. These two microcontrollers are coupled via Inter-Integrated Circuit (I2C) in which the master/slave configuration is used. One I2C slave reads the encoder for the driving motor, and the other I2C master is responsible for not only reading the encoder for the steering wheel motor but also for sending PWM signals to control the speed and direction of the motors. For more details, see Fig.~\ref{fig-wiring-motors}.

\paragraph{Motors and Motor Controllers}:
This ride-on-car is equipped with two DC brushed motors (DC 6 V 25 W); one specified for controlling the platform steering angle and the other for controlling the speed of the platform. Two H-bridge motor controllers (MegaMoto Shield \citep{}) are used to deliver a continuous current (13 A). This motor controller is selected for its desirable characteristics of linear relationship between PWM signals and the output DC voltage. This linearity makes it easier to control the motors. 

\paragraph{Power and Wiring}:
The original vehicle has a control board to actuate motors. The wires from the motors must be connected to the MIR Vehicle’s motor control unit. The electric wiring diagram of motors and batteries are shown in Fig.~\ref{fig-wiring-motors}. 

\input{fig/wiring-motors.tex}
Two MegaMoto H-bridge motor controllers are used to drive the DC brushed motors in both forward and reverse motions. We use a 9 V rechargeable battery for the steering motor and a 9.6 V (2 Ah) rechargeable battery for the driving motor. Each of the motor controllers is responsible for a specific motor. The jumpers on each board must be properly set. The details of the jumper settings are shown in Fig.~\ref{fig-motor-controller-jumpers}. Two motor encoders are used to read the driving motor speed and steering motor angle based on the motor revolution. One microcontroller is used to handle one motor encoder signals. So two microcontrollers are used and connected each other through the I2C interface to handle the two encoders. See Fig.~\ref{fig-wiring-encoders} for the details. The USB connector communicates with the laptop computer to send and receive data.

\input{fig/motor-controller-jumpers.tex}
\input{fig/wiring-encoders.tex}

\subsection{Sensor Suite Design}

We tested two different RGB cameras and one RGBD camera for vision sensors. Two options of LIDAR sensors were analyzed and one was tested with the platform. An IMU is also an essential part of the vehicle to measure the vehicle platform’s movement and direction. We tested one 9 Degree of Freedom (DOF) IMU. All sensors we tested are integrated with the ROS.

\subsubsection{Camera Sensor}
Two USB cameras are used for evaluation purpose of the proposed system. More cameras can be attached to have rear views and/or side views. Our choice for a front view camera is Logitech C922X pro \citep{c922-specifications_c922_2016}. This camera has a high frame rate (60 fps in 720p) and wide horizontal and vertical Field of Views (FOV) (70.42 degrees and 43.3 degrees, respectively). The primary purpose of this front camera is to detect lane markings and other floor markings so that the proposed platform can be used to train a deep artificial neural network to clone a driver’s behavior. The second camera is Logitech C310 \citep{logitech-c310-hd-webcam_logitech_2019}. This camera was used to take videos from the car’s first-person perspective camera view.  

\subsubsection{RGBD Camera}
RGB with Depth (RGBD) cameras can be a viable option. We shortlisted RealSense depth cameras \citep{pruitt_choosing_2018},  D415 and D435. The major between the two is related to their specifications of the FOV and resolution. The D415 has a FOV or degrees with 1920 x 1080 pixels resolution, while the D435 has a FOV of 90 degrees with 1280 x 800 pixels resolution. 

\subsubsection{LIDAR}
LIDAR is one popular way to detect obstacles for ADAS and autonomous driving. We propose to use the Neato XV series laser distance sensor. There is no official vendor to sell this product since this sensor is being used for a robot vacuum cleaner. But this small 2D laser scanner is popular due to the affordability and ROS community supports compared to other small scale LIDAR products. The Neato XV laser can give five Hz in scanning with a range of five meters. Another viable option is to use YDLIDAR X4 \citep{ydlidar-x4_ydlidar_2016}. This gives the proposed platform enough scanning speed and range since it is used in indoor environment at low driving speed. YDLIDAR can scan in 6 ~ 12 Hz with up to around 10 meters range.

\subsubsection{IMU}
Razor 9 DOF IMU is a module with multiple sensors packed in one package \citep{sparkfun-9dof-razor-imu_sparkfun_2018}. The IMU is used to provide the platform with a sense of its linear acceleration, angular velocity, and magnetic field vectors. To calibrate the IMU module, each sensor (the accelerometer, magnetometer, and gyroscope) needs to be calibrated separately. The difference between the standard and the extended magnetometer is that the standard compensates only for the hard iron errors while the extended one compensates for hard and soft iron errors. The hard iron is created by the objects generating a magnetic field while the soft is the alterations in the existing magnetic field. To carry out the calibration process, Processing \citep{reas_environment_2001}, an Integrated Development Environment (IDE) for the electronic and visual design, is needed. It is recommended to mount the sensor on your platform to accommodate any magnetic field noise. For calibrating the extended magnetometer you may need to download a Processing library named EJML. These instructions are available at the beginning of the processing script  \citep{razor_imu_9dof_razor_imu_9dof_2018}.

\subsection{Software Design}

\subsubsection{Environment}
We use Ubuntu 16.04 LTS since the ROS Kinetic officially supports only Ubuntu 16.04 LTS. The ROS is not an operating system even if the name implies. It is middleware on top of an operating system (Ubuntu 16.04 LTS). The ROS provides device drivers, libraries, message-passing, and package management so that developers can create robot applications easily. Autonomous vehicles are basically intelligent robots that happen to have four wheels and steering. 

\subsubsection{Install ROS Packages}

The ROS packages for the sensors previously mentioned can be installed with the following commands.

\begin{verbatim}
$ sudo apt install ros-$ROS_DISTRO-usb_cam 
$ sudo apt install ros-$ROS_DISTRO-xv_11_laser_driver
$ sudo apt install ros-$ROS_DISTRO-razor-imu-9dof
$ sudo apt install ros-$ROS_DISTRO-joystick-drivers
\end{verbatim}

Some of the packages are not part of ROS Kinetic. For example, \verb|realsense2_cam| ROS package must be used for RealSense D415 and D435. The package, however, is not released with ROS Kinetic. The installation process is as follows. Clone the git repository from \citet{ros-wrapper-intel-realsense-devices_intelr_2019}, and copy the \verb|realsense-2.x.x| folder to \verb|mir_vehicle/src| to make it as a ROS package of the MIR-Vehicle workspace. To build this package, Intel RealSense SDK 2.0 must be installed. The details of the SDK installation can be found at \citet{intel-realsense-sdk-2.0_librealsense/distribution_linux.md_2019}. Two libraries (\verb|librealsense2-dkms| and \verb|librealsense2-utils|) must be installed, and one additional library, \verb|librealsense2-dev| must be installed to build the \verb|realsense2_cam| ROS package.
An available ROS package for the IMU is part of ROS Kinetic. If you use this package, there is no need to translate the coordinates. When you need to use the IMU in ROS with your own implementation, it is better to convert the roll, pitch, and yaw angles generated by the IMU to quaternions as to be in \verb|geometry_msgs/Quaternion| ROS message format \citep{quaternion_message_geometry_msgs/quaternion_2010}. The reason behind using quaternions is that two coordinates out of x, y, and z can be aligned. This is called gimbal lock that may occur and interfere with your readings. According to REP-103 \citep{rep-103_rep_2010}, ROS is using a right-handed coordinate system that uses x-axis for pointing forward and y-axis for pointing to left and z-axis for pointing up. Razor IMU, however, uses x-axis for pointing forward and y-axis pointing to right and z-axis pointing down. Therefore, necessary action needs to be taken to translate correctly the coordinate frames in your ROS node. 

\paragraph{Troubleshootings}:
Laser sensors are considered as a ttyACM or ttyUSB device. When you have the access denial error from the device, what you can do is as follows. Note that in case of \verb|ttyUSB|, use verb|ttyUSB| instead.

\begin{verbatim}
$ sudo chmod a+rw /dev/ttyACM<port_number>  
\end{verbatim}

What this does is to add read and write permission to the specified device.

\subsubsection{3D Vehicle Model}
We also created a Unified Robot Description Format (URDF) \citep{urdf_urdf_2019} model of the vehicle and sensor packages. This allows us to use the MIR Vehicle platform in a simulated environment. Fig.~\ref{fig-urdf-model-gazebo} shows that the MIR Vehicle is placed on a simulated environment.

\input{fig/urdf-model-gazebo.tex}

\subsubsection{Microcontroller}

Two microcontrollers are used in the control unit. Each microcontroller supports up to two interrupt pins that are needed to read two channels from one encoder. One is for reading the driving motor encoder, and the other is not only for reading the steering motor encoder but runs a ROS node to communicate with the laptop. These two microcontrollers are connected via I2C interface. The ROS node is shown as \verb|serial_node| that publishes the \verb|encoder_pulse| topic and subscribes to the \verb|vehicle_control| topic. The \verb|joy2vehicle| node translates joystick control commands to the \verb|vehicle_control| topic that actuates the physical platform. The source code can be found at the \verb|arduino_driver| folder at \citet{kwon_mir_2019}.

\subsubsection{Laptop Computer}
A GPU powered laptop computer is the main computing source that runs the ROS core and complex perception and control algorithms based on Deep Learning libraries. Our recommendation for the GPU is GTX 1060 6 GB GDDR5 or above in terms of performance and GPU memory size. 

\paragraph{Remote Control}:
A 2.4 GHz wireless controller is used to send joystick commands that are translated to the vehicle control signals. We implemented a ROS node named joy2vehicle that can be found at the \verb|src/joy_control| folder at \citet{kwon_mir_2019}.  

\paragraph{Data acquisition}:
To develop autonomous vehicle applications, the vehicle platform must allow the users to collect data from sensors and the information from actuators. The MIR Vehicle platform offers the \verb|data_acquisition| package by which the users can collect images from cameras, distance measurements from a LIDAR, orientation and position from an IMU, and the speed and steering angles of the vehicle from motor encoders. The collected data location can be configured through \verb|rosparam|. We prepared a YAML file to configure that can be found at the \verb|src/data_acquisition/launch/| folder at \citet{kwon_mir_2019}. 

\subsubsection{Communication}
The motor control unit communicates with the laptop through \verb|rosserial|\citep{ros-serial_rosserial_2018} that is for interfacing with various microcontrollers through serial communication. Note that the ROS node inside the microcontroller is shown as \verb|/serial_node|. The ROS Master that is a computing platform running the ROS core is in the laptop computer where all other ROS nodes run. The ROS offers distributed computing architecture so no assumptions are made about the location of nodes and how they communicate with each other. 

\subsubsection{Set up ROS on the MIR-Vehicle}
An additional remote Git repository is prepared to install the ROS Kinetic with dependent packages \citep{kwon_ros_2019} for the proposed research platform.
Fig.~\ref{fig-node-graph-data-acquistion} shows the data acquisition node tree. Joystick commands are sent through the \verb|/joy| topic to the \verb|joy2vehicle| node. Then, the \verb|joy2vehicle| node translates the joystick commands to the MIR Vehicle’s control commands as a ROS topic named \verb|vehicle_control|. The \verb|/serial_node| subscribes to the \verb|/vehicle_control| topic and publishes the \verb|encoder_pulse| topic.  With the ROS graph (\verb|rqt_graph|), we can visualize how the nodes are communicating through ROS topics.    
\input{fig/node-graph-data-acquisition.tex}



\section{Introduction}
\input{main/introduction.tex}

\section{Related Works}
\input{main/related-works.tex}

\section{Methods}
\input{main/methods.tex}

\section{Results}
\input{main/results.tex}

\section{Conclusion}
\input{main/conclusions.tex}

\section{Appendix}
\input{end/appendix.tex}

\section*{Acknowledgment}
\input{end/acknowledgment.tex}

\input{end/references.tex}

\end{document}