06.0_Batman_Control

http://scoutbots.org/data/Protei/06.0_Batman/control/20110510%20Protei%20rough%20electronic%20diagram.jpg

This page is for the control system that will pilot protei006. Please add your name below if you would like to be part of this group. We will be investigating the hardware, software and sensors needed to make Protei semi-autonomous with remote over-ride control.

Feel free to delete this once it is addressed, but I know that a major issue regarding unmanned surface vehicles is in collision avoidance. UUVs and UAVs have less of a risk as a result of their freedom of movement about any axis. Depending on the materials used for the construction of Protei, collision with another vessel can have serious consequences. This is also important if Protei is to act in swarm-mode eventually (GPS can be used but what about other vessels). Current all-weather autonomous collision avoidance systems (radar, optical, infrared, lidar) is fairly immature in its development. Even that requires advanced filtering and data processing given environmental situations.

</Shah Selbe>

Current Tasks

We are agreed to read the materials which Peter shared for us till next meeting. (2 pdfs attached below) And we will discuss about ways of using 'agent-based control scheme' to the Protei.
We are going to list up sensors and also other hardwares that we need for the Protei continuously.

Proposal of a General Block Diagram of Protei v6

This proposal assumes following. If there are swam commands, they would be always reinterpreted as a set of waypoints of each individual Protei and also distributed properly to right individual Protei by ground control system or anything else(for instance, web application). Therefore, there is no need to concern about other Protei vehicles for individual Protei. Then, we can view individual Protei as a waypoints tracer. That is, a set of waypoints will be received by GPS or Telemetry and it follows that one by one. Based on this, I would like to propose following block diagram. (Unless, I think it could be too complex to be implemented within this summer.)

And for controller module, there should be several modes depending on the situation(e.g. tacking or jibbing). This strategy will be based on the results of model-based research or empirical tuning (i.e. trial and error).

Investigation for existing platforms

[1] OpenPilot. (wiki, flight controller, ground control system)

This one is using FreeRTOS (a small sized operating system). If we use some OS like this, we can get a multi-threaded, complex running system. Through this, our code could be very well modularized and easy to maintain(like, OpenPilot's HAL, App. modules). Instead, we need sufficient processing power. For instance, OpenPilot consist of 2 ARM processors(STM32F103RE, 32bit/72MHz) and one processor is dedicated only for the sensor board(AHRS). Maybe, we can also consider using small RTOS(like arduino + duinOS, or atmega328p with freeRTOS port for AVR).

ArduPilot. (official web, source code, board schematic)

There is no OS running on this. It is implemented as a manner of 'state machine'. In this case, it is easy to understand the flow of the program and do debugging. Instead, it may not be very well modularized. But anyway, this could be most efficient way concerning processing power and the simplicity. This one uses Atmega328 (16bit, 16MHz).

[2-1] ArduPilot Mega (official web)

Variation of ArduPilot.

</Dooho Yi>

[3] CompactRIO

NI CompactRIO is a reconfigurable embedded control and acquisition system. The rugged hardware architecture of the CompactRIO system including the I/O modules, reconfigurable field-programmable gate arrary (FPGA) chassis, and the real-time controller. Additionally, CompactRIO is programmed with LabVIEW graphical programming tools and can be used in a variety of embedded control and monitoring applications. http://www.ni.com/compactrio/

About Communication

Range issues with radio frequencies: "I believe there is an inverse law about data rates, which is roughly half the data rate and double the distance (for the same transmitter power and receiver sensitivity), so design to the lowest baud rate feasible. The 600km was, I think, about 10-12 baud, with a few mW (to stay legal)"

Anyway the largest ranges I could find go up to

40 miles (64 km) for XTend 900 for the US -> www.sparkfun.com/products/9411
15 miles (24 km) for XBee-Pro900XSC U.FL for the US -> www.sparkfun.com/products/9086
60 miles (80 km) for XBee-PRO® 868 OEM RF for Europe ->http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/point-multipoint-rfmodules/xbee-pro-868.jsp#overview

-> XBees seem to be a very good documented and straight forward solution for short range communication and should be enough for the Protei v6 ZigBee modules:

advantages:

easy to use, direct communication with microcontrollers
can also talk to each other

disadvantages:

relatively short range
not so cheap -> 60 to 150 Dollars

--> if we do not have our own satellite, the largest range can probably be achieved with cellular systems / GSM-modules

GSM-modules

there are plenty of GSM-modules that can be used with Arduino or other microcontrollers but I want to point out this one:

It's Open Source -YEA- http://www.hwkitchen.com/products/gsm-playground/ there is also a library for arduino: http://www.hwkitchen.com/news/gsm-playground-software-library/

this would basically be an out of the box solution! I also checked if those would work in most countries: -> YES they would its (GSM 850, 900, DCS 1800, PCS1900 MHz) which works almost everywhere http://www.onesimcard.com/?idmenu=8

GSM-modules:

advantages:

very big range
you can address every single craft individually from everywhere -> you can call it to come home :)
seems to work out of the box

disadvantages:

need a sim-card -> there is always a company in between that we cannot control
need to have GSM reception
not so cheap -> 132 Euro = 192 Dollar

Conclusion:

For the Protei v6 for September a XBee Pro 868 for Europe should be a good choice, since it is easy to handle and good for prototyping. But for the final version we might think about adding a GSM-Modul. But since we will create an open-source solution we could also leave this option free to anyone who builds her/his own craft.

Also we need to determine what range we need. Is it enough if the crafts only talk to each other or should they also be able to communicate with a control-station on land?

having control over them from a great distance would be very good if not even a necessity.

Feel free to add or change!

</sebastian neitsch>

INFORMATION TRANSMISSION METHODS

Communication with Protei 006 will be very important. While full autonomous behavior is desired, monitoring Protei is critical to testing the design. Even when Protei is fully functional and ready to be let loose in the ocean, a method of tracking Protei will be important. A website that displays the current location and other information collected from Protei. This would be useful for tracking and could be used for demonstrations as well. Additionally, future swarm behavior will require the Protei to communicate with each other.

Some possible communication options are

WLAN :
- UMTS/GPRS
IRIDIUM
INMARSAT
Eutelsat
More satellite communications

Depending on the requirements for the amount of data that needs to be sent, there are a number of options for satellite-based communication systems that can be used in either SMS, low-speed data, and high-speed data configuration. Generally these have incorporated GPS units so they commercial off the shelf units can fill the need for both the GPS and the communication functions.

If SMS were to be used, a communication protocol can be created to deliver the necessary telemetry. The prototype unit may need to be equipped with a more robust communication or data logging system to account for additional testing and characterization. From wikipedia: All commercial satellite phone networks except ACeS and OptusSat support SMS. While early Iridium handsets only support incoming SMS, later models can also send messages. The price per message varies for different networks. Unlike some mobile phone networks, there is no extra charge for sending international SMS or to send one to a different satellite phone network. SMS can sometimes be sent from areas where the signal is too poor to make a voice call.

Satellite phone networks usually have web-based or email-based SMS portals where one can send free SMS to phones on that particular network. Other commercial service providers such as Targlets allow for SMS on the +881 and +882 numbering plan prefix. Some other providers also cover the +870 plan.

It should be noted that these satellite networks generally either have a monthly subscription rate or per message rate (or a combination of the two). Some underwater glider researchers have found that, during long missions, the expenses from the satellite phone (as Peter said below, typically Iridium) can make up a significant amount of their operating expenses (the nominal communication cost for Iridium usage to be approximately USD 2400 for a 3 week glider mission or USD 180 per day). Also, for those high costs the data rates may be low (I have read 2400 bps maximum on Iridium). I found a link with a useful (top level) summary of satellite communications for the ocean environment and the associated regulations:

http://www.gps-practice-and-fun.com/satellite-communications.html

http://www.gps-practice-and-fun.com/maritime-regulations.html

Also, it may be easier to have the capacity for WiFi or a radio modem (Freewave brand - 60 mile line-of-sight range) that is used for operator-vehicle communication during deployment and retrieval. The range of these can be extended through elevated coastal comm infrastructure. During the mission phase, it can send telemetry using a satellite communication system to improve the range.

Lots of good information in this article "A Communication Framework for Cost-Effective Operation of AUVs in Coastal Regions."