CHAPTER [3] REAL TIME HARDWARE AND SOFTWARE ARCHITECTURE

[3.1]-Real Time Hardware Architecture:

Modern Cars have distributed embedded system. So many tasks can run at the same
time to achieve parallelism. This strategy is applied in our ROV design. We have used 4
MCUs and 1 DSP in this design. All processors are interconnected using Controller Area
Network (CAN) bus. The selection of processors will be discussed later in this chapter. We
have 3 parts in our ROV hardware design, Sensors and Communication, Signal processing
and motor controlling. The Figure below shows the complete architecture of ROV design.

Fig. 3.1 Design of Real Time Hardware Architecture of ROV

[3.1.1]-Sensors and Communication Node:

This node communicates with UI, peripheral processors and handles the peripherals.

[3.1.1.1]-Processor Selection:

Texas instrument’s TMS320C28341 is chosen for this part, we need fast processing for this
node of the network. So this can run at 200 MHz, this is the cheapest most processor we
found with this speed is 8.95 US$. It has all the peripherals (Timers, Input Capture Unit) and
communication protocols (i.e. USART, CAN) which are required in our application. The
processor has special features like PIE (peripheral Interrupt expansion) fast interrupt
response, WDT, PWM, ADCs etc.

[3.1.1.2]-Peripherals:

SA-320-5 Hz (Marine GPS Receiver) is chosen for location tracking, altitude and speed
information. Its cost is 64.9 US$, it has WAAS (Wide Area Augmentation System) support
for position accuracy. Sonar transducer is used for target distance detection, MCU sends 40
KHz wave using its timer and receives this wave back to calculate the distance between ROV
and object. Video multiplexer selects different cameras according to the user selection.

[3.1.2]-Signal Processing Node:

This design ROV can achieve 3/6 Degrees of freedom motion, there are inverse and forward
kinematics equations for motion controlling so we need Digital signal processor for
calculating 6/3 Degrees of freedom motion using algorithm. So ROV can achieve motion like
up, down, left, right, roll, pitch , yaw. See Fig. 3.3 for 3-axis view of it. DSP is also used for
pattern recognition of objects underwater by performing correlation etc. We have two sources
of pattern recognition present in our application one is camera and other one is sonar.

[3.1.2.1]-Processor Selection:

DSP from Analog devices ADSP-BF534 is chosen for this application, it runs at 300 MHz, it
has three 16 bit MACs, two 40 bit ALUs, four 8 bit video ALUs, 40 bit shifter. Its cost is
12.68 US$. It supports CAN, I2C, SPI, UART, PPI and many other features. It is qualified
for automotive applications.

[3.1.2.2]-Peripherals:

MMA8450(Accelerometer) from Freescale semiconductor is chosen for finding the

acceleration of ROV in terms of g-force, this is very cheap as it is available in 4.75 US$.
Accelerometer data can be used at GUI for information regarding to the polarization of ROV.

Fig. 3.2 Acceleration v/s Time Fig. 3.3 6 Degrees of Freedom

[3.1.3]-Motor Controlling Nodes:

Motor controller nodes are used for motor controlling using PWM. The position error is
detected using the encoders connected to the shafts of the motors. Higher resolution encoders
will give more accuracy. Since we have used a separate processor for each motor all motors
can run in parallel to achieve 6 DOF. MCU4 is also interfaced with temperature/whether
sensors using 10bit ADC, refer Fig. 3.1.

[3.1.3.1]-Processor Selection
For motor controlling application we don’t require more I/O ports in MCU. PIC18F2480
from Microchip is chosen for motor controlling nodes. It comes in small package of 28 pins
runs at 40 MHz, It possesses Nano-watt technology. It contains Enhanced CAN, 10 bit ADCs
and many other features. It is extremely cheap available in 3.71 US$.

[3.2]-Choice of Communication protocol between nodes

For underwater vehicle we need fast response in case of emergency, parallel processing for
good performance. We have 5 nodes (MCUs) in this design, they all are interconnected, we
need to choose a feasible, efficient, error free, high speed communication protocol. We are
not choosing SPI because SPI cannot send frames to all the nodes at a time. I2c is slow can
work up to 400 KHz. We have selected CAN protocol for interconnecting the nodes, it can
run at 1-2 Mbps, it satisfies all four requirements mentioned above in this paragraph. This is
widely used in automotive applications. We have other options available like LIN and
Flexray. The data rate of LIN is slow and Flexray is expensive.

Fig. 3.4 Standard Data Frame of Controller Area

[3.3]-Software Architecture

We have designed software flow for three different firmware programs for three different
types of processors used in ROV. The flow charts in Fig 3.5, Fig 3.6, Fig 3.7 explain how the
peripherals like timers, DMA, CAN, I2C, UART, PWM are used in embedded system for
ROV project. Embedded software is designed in such a manner that all nodes (MCUs) are
running in parallel. All motor controlling nodes have same firmware. Motor controlling nodes
have software based PID controller for position error correction of motors. It is very easy to
add a robot arm or manipulator because it also uses 6DOF motion so it can reuse the code, as
we are already putting the code in DSP for that.

[3.4]-Real Time Operating System (RTOS)

The software part should be hard real-time system. Some hard Real time tasks like
Emergency stop etc., non-real time tasks and soft real-time tasks can work together under
embedded RTOS. ROV is proposed to guarantee the real time performance of hard real time
tasks. RT-Linux has small latency, small jitter and fast response so we are proposing RT-
Linux to perform all these tasks for ROV. RTOS can be implemented in Sensor and
Communication node. RTOS is running different tasks with different priorities; semaphores
can be used for inter-task communication to protect shared data resources. Preemptive
scheduling is used to perform a critical task which has a hard deadline like any emergency
condition, brakes, response to external interrupts etc.
Fig. 3.5 Sensor and Communication node software flow Fig. 3.6 Signal processing node software flow

Conclusion:

Ø Parallel tasking can be done using

multiple processors or multi-core
processor which results in fast response
and good performance.
Ø No need to pay the money for those
peripherals which we are not using.
Choice of processor is important.
Ø Sometimes some software instructions
save bulky hardware which reduces
overall cost of product.
Ø Multi-tasking is achieved using Real time
operating system.
Ø RTOS guarantees the time taken by hard
real time task, which provides safety in-
case of emergency situation.

Fig. 3.7 Motor Controlling Software flow

References

[1]- RT-Linux based hard real-time software architecture for unmanned autonomous
helicopters by Won Eui Hong, Jae Shin Lee, Rai, L., Soon Ju Kang , Embedded and Real-
Time Computing Systems and Applications, 2005. Proceedings. 11th IEEE International
Conference, 2005.