SYSTEM LEVEL VIEW

SYSTEM FUNCTIONAL ARCHITECTURE

Six different colors identify six subsystems:

1. Motion Control: This subsystem is responsible for the low-level motion control of the quad-rotor.

2. Perception: This subsystem is responsible for the basic sensing data processing.

3. Communication: This subsystem is responsible for securely transmitting messages among the Arduino, the SBC and the GCS.

4. Rescue Mechanism: This subsystem is responsible for deploying the lift mechanism and lifting the subject on-board.

5. Navigation: This subsystem is responsible for guiding the quad-rotor to the target location while avoiding obstacles.

6. Graphical User Interface: This subsystem is responsible for displaying the state of the quad-rotor as well as communicating operator input.

SYSTEM PHYSICAL ARCHITECTURE

1 MECHANICAL DESIGN:

1.1 Quadrotor Frame:

The mechanical frame of the quadrotor is a vital component in quadrotor flight. Symmetry, weight balancing and materials used are an important design choice. Since our goal was to develop additional functionality on a quadrotor platform, we

decided to purchase an off the shelf quadrotor frame made by 3D Robotics. This design choice was made from several options available online. Some of the key factors we took into consideration prior to purchasing the frame: weight of the

frame, materials used, dimensions, available volume to attach components etc. Many of the available quadrotor kits were less than 15 cm, motor to motor diameter. We determined that this would be very small for our purposes since the

quadrotor will have to lift a payload of atleast 1.3 kilograms. The arm of the 3D Robotics frame, as shown in Figure 1 below, is 11.02 cm, giving a total cross-sectional length of 27cm. This is conventionally a larger frame, but offers the

opportunity of increased payload.

Figure 1: Arm design

Additionally, the arm was built with quality Aluminum, offering sturdiness and resistance to impact.

Another major design decision we made was for choosing the landing gear of the quadrotor. This is a very important component in the frame design. The major responsibility of the landing gear is to reduce passing the tensile stress to the arms,

in case of a hard landing. However, at the same time, landing gears must not be too brittle as to snap frequently. We experimented with a few different materials in this domain. In order to keep the budget under check, we used the drawings

from 3D Robotics and laser cut our own landing gears with thick acrylic. This material, though good with shear stress, fails terribly under tension. Therefore, in a few landings, several landing gears were fractured. We then decided to use

Balsa Wood. The wood does not fracture easily, thereby transferring all the impact to the arm. We observed minor deformation in the Aluminum arm. Finally, after some research we learned that carbon fiber is the most suitable material for the

same. Since we could not find any resource at the university to laser cut carbon fiber, we ended up purchasing it from 3D Robotics itself.

In order to accommodate the laser mount on the frame, we decided to purchase a three level stacking on the quadrotor frame. The bottom housed the power distribution board. On the first level was the Ardupilot board and the IMU. Lastly,

on the top plate we screwed the laser cage. Figure 3 shows the drawing of the final quadrotor frame.

Figure 2: Final Assembly

In retrospect, we made one major mistake. The screws and nuts we used to secure the quadrotor assembly was of M3 size. This size is a popular hobbyist threading in Europe. However it is very difficult to find it in the United States. Most

major stores such as Home Depot and Lowe’s did not carry this kind of threading. As a result, we were restricted to purchasing all our fasteners online at premium prices.

1.2 SBC Mount:

Mounting the Single Board Computer on the quadrotor was a major design challenge. Due to heavy weight of the SBC, we decided to mount it under the main frame, snugged between the landing gears. This made the quadrotor bottom heavy

avoiding it to flip very often. Additionally we had to ensure, adequate ventilation for the processor board, in order to avoid overheating. Therefore, the mount could not be tucked right under the power distribution board. We decided to use

metal spacers of 10mm height between the quadrotor frame and the SBC mount. Finally, we had to consider methods of fastening the SBC to the main frame. We decided to use the holes on the bottom carbon fiber plate housing the power

distribution board, to secure the SBC mount. Figure 3 is a hand sketch we created to machine the mount. In order to support rigidity and sturdiness we used acrylic for the mount material. A major design accommodation we made in the SBC

mount was to provide clearance for altitude measurement. A mirror was used to bounce horizontal laser beams vertically to the ground. However, a full size mount would obstruct the beams causing a loss in altitude measurement. Therefore,

as can be seen in Figure 3, we cleared a small square of 5cm x 5cm (top edge) to permit the flow of LiDAR measurement. A 1cm slit was provided on the bottom edge to house the belt that would secure the batteries to the SBC. Finally the

SBC mount also housed the camera on one side and the rescue mechanism on the other.

Figure 3: Mechanical drawing for SBC mount

1.3 Laser Cage:

The LiDAR was the most expensive component of the entire system. Therefore it was imperative to protect it. Since the purpose of the LiDAR was to scan the environment, it would be completely exposed during impact. Therefore we

decided to seal the entire surface area of the LiDAR, other than the scanning region. Given the laser occupied a 50 mm/ edge cubic region, we designed a cubic cage of 90 mm. The volum was hollow to house the laser, thereby giving 20mm

cushioning on each surface of the LiDAR. This design also accomodated for the USB connection by a slit on the right surface, as can be seen in Figure 5. Initially we planned to machine this cage from high quality and light-weight ceramic.

However, given the cost of machining and material price, a single cage would have cost over $250. Due to budget constraints, we scrapped that decision and made it with insulation foam instead. The designs of the cage remained the same,

though the build process was highly simplified than initially planned. The cage was sturdy and served its purpose well, saving the money and time.

Figure 4: Model of the LiDAR cage

2 ELECTRICAL DESIGN:

2.1 XBee Pro 900 Transceiver:

The main requirements for the wireless telemetry device were:

· Capable of transmitting data with a range of 100 meters.

· Capable of transmitting LiDAR data of 15 kbps (so has a minimum data rate of 19.2 kbps).

· Compatible with the ArduPilot Mega board/IMU shield (has serial interface).

· Does not interfere with the radio communication at 1.6GHz.

Figure 5: XBee Pro 900 module with accessories

These requirements are well fulfilled by the XBee Pro 900 wireless telemetry module, as follows:

· It has a data range of 10km with high gain antennas.

· The baud rates are configurable, with max allowed baud rate of 57.6 kbps.

· Has direct 4-pin serial interface to connect to IMU Shield. It has been tested to communicate to APM board successfully by hobbyists.

· Operates on 900MHz frequency. So, does not interfere with the radio we’re using.

Hence, we chose XBee Pro 900 for our project.

2.2 Single Board Computer for on-board processing:

In Fall semester, we decided to go with the off-board processing approach. The LiDAR data was supposed to be communicated wirelessly to Ground Control Station, where we would process the data. This was required, because the APM

board deploys an AtMega 2860 processor, which has a maximum operation frequency of 16MHz, and cannot process the LiDAR data. However, at the beginning of Spring semester we noted the following after a few brainstorming sessions

and tests:

· APM board has a single USB slave port which is used to communicate with the host PC. Since Hokuyo LiDAR also has a USB slave port, an intermediate USB Host Controller device would be required to enable APM board to

read the data from LiDAR.

· The default data output from APM board follows MAVLink data protocol. This meant the LiDAR data had to be encapsulated into the MAVLink data packet, and then serially transmitted via XBee wireless module. Given the

timeframe of 3.5 months in the Spring semester to complete the implementation and testing, we found it difficult to complete this task.

· LiDAR sends the data at a data rate of 15kbps. The size of SRAM inside AtMega 2560 processor is 8kb. This is not enough to store all the LiDAR data. The solution would be to use an external RAM, but its integration with APM

board would be outside the time limits allowed.

· Even after solving the LiDAR date problem, the AtMega 2560 processor in the APM board cannot process the data from camera due to low processor speed and very low on-chip memory.

All these factors led us to choose the Single Board Computer for on-board processing, and completely abandon the off-board processing. This made things much simpler, and we came up with following requirements for the SBC:

Ø Must be able to run Ubuntu 10.04 OS, so we can replicate the code for MAVLink protocol written in ROS.

Ø Must have at least 3 USB ports – one for LiDAR, one for camera, and one for communication with APM board.

Ø Must weigh less than 500 grams including mechanical case.

Ø Must have at least 1GB of RAM, and a 1.6GHz processor for running color detection algorithms.

Ø Must have a LAN port to communicate with PC via remote desktop.

After going through the list of SBCs, we finalized the FitPC2 SBC for our projects. It had the following specifications (that met all our needs):

· 6 Hi-speed USB ports

· Runs on 8-15V power supply, and hence can be powered by 3-cell/4-cell LiPo battery

· Has 1 LAN port

· Processor: Intel Atom Z530 1.6GHz

· Has a RAM of 1GB, which we enhanced to 2GB

· Can run Ubuntu 10.04 LTS

· Bootable with a pen drive

· Weighs less than 200 gram with the mechanical case

2.3 Multiple batteries

Following major components were expected to be powered from SBC directly (or algorithms running on SBC):

· 32-bit Ubuntu OS. This makes SBC have a default current consumption of 500mA

· Hokuyo URG-04LX UG01 LiDAR - The current consumption of Hokuyo LiDAR is about 500mA, and peaks up to 800mA during startup.

· USB Camera – It consumes about 500 mA of current.

· The color detection algorithm – It is not as rigorous as other complex image processing algorithms, but we left the buffer of 500mA for the algorithm.

This makes the SBC source about 2300mA of peak current. The allowed operating voltage for the SBC is 8-15V. We considered the following facts for choosing the powering scheme of SBC:

· 2-cell LiPo (7.4V) was not an option, since its voltage would be too low to power the SBC.

· 4-cell LiPo (14.8V) would cause excessive power dissipation from SBC (average power = 14.8*2 W = 29.6W).

· The AC-DC adapter for FitPC2 SBC supplies 12V DC to power the SBC.

We were using a 4-cell LiPo battery to power the DC motors on quad rotor, due to high thrust requirements. Initially, we thought of using the same 4-cell battery to power the SBC too. However, we rejected the idea of single-cell powering

due to following reasons:

· The flight time for 4-cell battery with the entire payload was already under 5 minutes. Using the same battery for powering SBC would further deteriorate the mission time, and we would not be able to meet the requirement

of mission time for 5 minutes.

· 4-cell battery would cause excessive heating of SBC.

Hence, we chose to go with the 3-cell LiPo of 11.1V with current source of 2200 mA and maximum discharge rate of 25C. This gives the battery a peak current source of (2.2A * 25 = 55A), and is sufficient for our application.

2.4 High Power DC motors

In Fall semester, we mounted only the basic components on quad rotor that were required for its maneuvers. These weighed about 800 grams. We therefore used the DC motor AC2830-358 which had a kV value of 850. The

recommended propellers for this motor were 10’’x4.5’’, and generated a thrust of 855 grams at 75% ESC efficiency per motor. The total thrust generated by 4 of these sets was (855x4 = 3420 grams) theoretically.

However, in Spring semester we had following additional components to mount:

· Single Board Computer – 200 grams

· Additional 3-cell LiPo battery – 200 grams

· LiDAR – 160 grams

· Weight of mounts (LiDAR cage, SBC mount, etc.) and cables – 100 grams

· Weight of lift mechanism – 50 grams

· Weight of USB camera – 30 grams

This resulted in additional weight of approx. 800 grams. The existing motor-propeller combination was able to lift the weight only at a very low altitude when we tested it. Hence, we decided to go for the next available combination – the

AC2836-358 DC motor with a kv value of 880, with the recommended propeller set of 12’’x4.5’’. The expected thrust from this combination at 75% ESC efficiency was 1290 grams per motor. Since we had 4 such pairs, now the total

theoretical thrust output would be (4x1290 = 5160 grams). Though the actual thrust generated would be lesser, we assumed the difference between theoretical vs actual thrust to be same for both the motor-propeller combinations. This meant

the actual thrust generated would be (5160 – 3420 = 1740 grams) more for the new motor-propeller combination. Since we had the additional weight of only 800 grams, we agreed to go with this new motor-propeller combination.

3 SOFTWARE DESIGN

3.1 Tools

l ROS

ROS (Robot Operating System) is an open-source system providing services including message-passing between processes, hardware abstraction and package management. For our system, the softwares on the SBC (Single Board Computer) and the GCS (Ground Control Station) are based on ROS. We use the laser-driver package in ROS to process the data from the LiDAR. ROS CvBridge package is used as the interface between the software system and OpenCV library, which is further used to process image data from the camera. The package management in ROS also made it easy for us to develop independent software nodes, which could communicate with each other using the message-passing mechanism provided by ROS.

l ArduPilot Firmware

ArduPilot is an open-source firmware based on the Arduino Mega platform. It provides the basic functions for motor control, radio signal processing, IMU and GPS data processing, and PID controllers for autonomous stabilization. Therefore for our system with a different weight and center of mass, we just need to tune the controller parameters to make the firmware work.

l MAVLink Protocol

We used MAVLink (Micro Air Vehicle Protocol) for communication among the softwares on the Arduino, the SBC and the GCS. MAVLink protocol is independent from the hardware level and also implemented in the ArduPilot Firmware. It is also convenient and safe to customize new message types in MAVLink Protocol.

l GTK++ and OsmGpsMap

GTK++ and OsmGpsMap are used for the GUI (Graphic User Interface). GTK++ enable us to make a fancy GUI based on GNOME in Ubuntu and OsmGpsMap can provide the GUI with online maps and the capability to plot the GPS track on the map.

3.2 PID controllers

We implemented PID controllers in the rescue subsystem to stabilize the quad-rotor above the target. Although at last we did not have enough time to tune the PID parameters, a PID controller (or at least a PI controller) is still our first choice since it will make the quad-rotor achieve the desire state faster and avoiding over-shooting. We are also using PID controllers in stabilization, navigation and altitude hold. For stabilization, the controller is largely based on the feedback of gyro data. For navigation, it gets the feedback from the compass and adjust the yaw of the vehicle. In altitude hold, there are two PID controllers controlling the altitude and climbing rate of the quad-rotor.