Copyright © 2014 by Intelligent Systems Laboratory, Computer Science Department, Technion - Israel Institute of Technology, Haifa 3200003, Israel. All rights reserved


TheGrue.org

Modules for 3D Mobile Platform

Modules for 3D Mobile PlatformCommunication and Navigation Modules for Experimental 3D Mobile Platform

The goal of this project is to build a software C++ based modules (classes) that provide communication and navigation functions for an experimental 3D Mobile Platform, a helicopter in our case. The overall system as it meant to be in its conclusive instance involves three sides of compound interest - allowing the helicopter to perform data collecting, espionage and other missions while being navigated automatically according to territory map. From the point of view of detached observer, the helicopter “knows” to take off from special vehicle’s roof, then fly on a pre-defined track (can be dynamically changed while flying) and perform sensors measuring, video recording of the territory etc.. And, finally, return to base by itself, i.e. return and land on the roof of the vehicle.

These three sides are:

• Group one, responsible for displaying the location of the vehicle and the helicopter on the territory map.
• Group two, responsible for building the helicopter navigation track, providing it new destination points.
• Group three, responsible for navigation of the helicopter.

Group two’s navigational software communicates with the helicopter through Group three’s software, while Group one constantly receives feedback from the Group three side software about helicopter’s current location. Along with positioning feedback, Group one can also constantly receive frames from video stream from a web camera, located on the helicopter. Group three side software is implemented in this project.

PROBLEM DEFINITION
• An experimental helicopter can currently be navigated using a remote control.

• It has several sensors, such as GPS chip, mounted on it, as well as a web camera that transmits video stream through Wi-Fi.

• Using the GPS chip, the helicopter can be brought to a specific point. Moreover, it can be navigated through a specific track that consists of such points.

• Automated system of navigation, i.e. software, could expand the capability mentioned above allowing the helicopter to perform missions that include taking off, flying via dynamically given track, hovering while scanning data, then returning to base. All without human interference.

• Video camera mounted to the bottom part of the helicopter allows automatic landing using image recognition. Expanding this capability to landing platform located on the roof of moving vehicle is definitely an option, as the helicopter’s maneuvering capabilities are much better than vehicle’s.

• Group two in this project is a group of engineers that develop high level navigation software. This software needs to be in constant bi-directional contact with the helicopter, as it requires rapid on-demand reporting of positioning, flying status, battery etc.

• Group two’s software dynamically sets destination points and defines the track. It doesn’t care, however, how these actions are performed by the helicopter. This part is all performed by Group three side software, i.e. by this project.

• Group three to Group two communication is performed via TCP/IP network (TCP protocol). Two channels were defined, one for sending Group two to Technion data and the other for sending Group three to Group two data.

• Group one in this project is a group of engineers that develop high level graphical display system for the user that displays current locations of the helicopter and the vehicle.

• Group three to Group one communication is also performed via TCP/IP network (UDP protocol). A single channel is enough at this case, as Group one only requires single direction reports. Group three side is the one that provides Group one with current positioning data.

• Along with the positioning data an optional channel (currently implemented only by the Group three side) allows Group one to receive running sequence of frames of the area filmed by the helicopter’s camera. The video stream of the helicopter’s camera (MJPEG format) is transferred to Group one as bitmaps.

• GPS positioning data (latitude, longitude and altitude), navigation data (roll pitch and yaw angles) and velocity (speed on X, Y and Z axes) is received via a wireless COM port from a serial device through a constantly open channel.

• Another, optional, channel allows sending commands to the serial device. This feature was implemented but isn’t used, since the hardware that allows transmitting received commands to radio frequency helicopter commands is currently serves as a manual pilot executor.

• A manual pilot is a person that operates the helicopter using a 4 degrees of freedom interface, such as Joystick.

• Since no automatic mechanism (hardware) for piloting the helicopter is currently available, it was decided to use manual pilot instead. Nevertheless, the manual pilot receives instructions for piloting directly from Group three side software and strictly fulfills them. Therefore his functions can be concluded as parsing directions on a PC monitor to operating the appropriate levers on the Joystick.

A solution had to be found, that would fulfill all these requirements, i.e. communicate with Group two, Group one and serial device and provide instructions for the manual pilot. This project consists of several classes achieving all together for this common goal.

OPPOSED SOLUTIONS
• Data exchange with the serial device should have been performed through a serial, COM, port. Developing in C++ under Microsoft Visual Studio was required. Visual C++ doesn’t have any API for working with serial port hardware directly due to Microsoft HAL restrictions. It could be done through Managed C++, C++/CLI, C# and others, but they were all off the limits of this project.

• Several solutions were found of third party companies, e.g. ActiveComport Serial Port Toolkit 3. However, none was a freeware library that allowed their DLLs to be used as a regular programmer API, i.e. providing methods that could be called from C++ code.

שלום רב
• Communication with Group one was based on two TCP channels. At first, it was decided that Group one would act as server for both channels. However, on such TCP channel, only one side can be the server, while the other side is considered a client. The server keeps a queue of received messaged, while the client doesn’t have such a queue. Non blocking sockets mode was also tried… and thrown away, since is caused serious loss of messages. The communication scheme had to be changed to a more robust one that won’t lose data.

• The serial device providing positioning data is asynchronous. Furthermore, it sometimes provides garbage data, i.e. packages with failed checksum. Collecting data as it comes was unsuccessful solution. Checksum validation further to receiving the data and blocking method had to be implemented.


• In spite of the garbage data provided sometimes by the serial device, it is very important not to lose any data. This, to keep up the good rate of fresh positioning data, which changes rapidly. Every turn of the helicopter should be registered by the navigation system. Hence reading rate was a critical issue. At first, non blocking method of reading data from the COM port was tried. It definitely had the advantage of implementation simplicity. However, the data seemed to come jerked, while we required constant flow of the data with the smallest delta possible from the RMS rate. This solution didn’t work well and had to be replaced by a parallel programming solution.

• Since data from different sources is collected, e.g. serial device packets VS Group one packets, while each side has its own rate. Refreshing the instructions to manual pilot after receiving data from both sides caused serious delay. Though, this solution failed and a new one had to be invented that involves a synchronous mechanism for data echange and instructions display.


• When calculating the distance of the helicopter from current destination point, a plane projection of its latitude and longitude was first taken. Then the distance was calculated using constant that translates earth degrees to meters. This method, however, appeared to be quite inaccurate. The constant which was computed via earth radius wasn’t precise enough. Together with the approximation method of 2D projection, it resulted in calculations error of nearly 30 meters. A solution that would provide much more precise distance was required.