Trans-Atlantic Robots

An anonymous reader writes "In the summer of 2008, teams from a host of countries will compete in The Microtransat Challenge with the hope of gaining the honor of having built the first autonomous sailboat to cross the Atlantic. The results of Microtransat 2007, a smaller scale preliminary race, were recently announced. The winner was the team from Austria; team RoBoat, for having completed 24 hours of autonomous sailing. I am strongly considering joining this competition before the year is out, and would appreciate any insight from the Slashdot community. The boats can be up to 4 meters in length, and therefore capable of carrying a full-sized onboard computer (operating system of your choice). Time is limited however, so I would like to avoid as many hardware issues as possible and get straight to the difficult problem of writing the AI. So how would you design a seamless interface between sensors and actuators to the high-level code?"

Comments

In one word?

[vigmeister]

MATLAB

Cheers!

Re:In one word?

[0100010001010011]

More Specifically: Simulink & XPC.

You can even build your own XPC boxes from old scrap PCs. The little blue XPC boxes are nice but expensive and have limited IO. Our company just did this to save some money, works great. You can bootload them so that they're always running too.

Fun stuff.

I 3 Mathworks

URBI

[bobby1234]

http://www.urbiforge.com/ "URBI is a Universal Real-time Behavior Interface and gives you a simple but powerful way to control any robot or complex system like a video game, using a convenient and easy to use scripting language that can be interfaced with several popular programming languages (C++, Java, Matlab,...) and OS (Windows, Mac OSX, Linux). URBI is based on a client/server architecture, which give a great deal of flexibility. URBI includes powerful features compared to existing scripting solutions: parallel execution of commands, event programming, command tagging, dynamic variables,... Currently, URBI is used as well by academic research labs, the industry and by hobbyists."

Possible Architecture

[mechsoph]

PC (maybe mini-itx) running *nix talking via Ethernet/IP to a Netburner Microcontroller talking via CAN to several PICs/AVRs with some extra circuitry (amplifiers, voltage dividers, etc) to interface with the sensors and actuators.

There are PICs and AVRs that have ethernet, but the NetBurner is damn easy to use. They also have some micros with GPIO, ADCs, and maybe PWM generation, so it might be easiest to skip the 8-bit micros altogether. I don't have any affiliation with NetBurner; I've just used their product and was sufficiently impressed that I might voluntarily choose to use it again.

What we use

[jfim]

Our team(SONIA) is working on autonomous underwater vehicles and we are using Linux with Java for the AI part. For communication with actuators, we use the CAN bus, which is fairly common in the industrial automation and automotive fields.

There are CAN bus adapters that plug into serial or USB ports and there is Linux support for these. We're using one from Vector.

As for hardware, we use the Kontron JREX SBC with JFlex I/O boards to add the I/O ports we need(firewire and serial, mostly). Of course, if you're not cramped for space, you might go with something a bit larger.

I hope this helps, feel free to ask more questions.

The real challenges

[Anonymous Coward]

There are lots of suggestions (some workable, some not) in the discussion, but the fact is that sailing a simple rig (let's say, a cat or maybe a sloop) has a small number of controls which operate in limited ways. Robotic controls for turning winches, for handling inputs on things like windspeed are fairly well understood.

Here's where I think your problems will really lie:

a) Heavy weather sailing relies on things like reefing and steering with an eye to waves. On a small boat, this goes double. 4m is small. Letting a following wave catch your rudder can simply rip it clean off. Control under difficult conditions is a whole nest of special cases.

b) The ocean is a hostile environment for humans. It's intensely hostile for electronics. A bit of water in the wrong place, and it's game over. Worse, boats come under savage stresses and strains; their hulls work, and consequently cracks let water in, and cracks develop in bad places.

c) Quite aside from radar, GPS and other ways of navigating, you should be aware of weather. Assuming you can get the weather predictions to the boat in some codified fashion, great, but I don't think that's a given, and without it you should be prepared for the North Atlantic's pitiless storms. In those: see A and B

d) Collisions. 4m is a small boat, but it's heavy, and there are other big things out there which can put nasty holes in your dinky boat. Like whales. Like floating containers. Like icebergs. Like other unknowing/caring vessels. I believe that by the law of the sea you might end up responsible for damage. Ask a sea lawyer! You don't want to pay Big Buck$ for a mistake!

e) On the topic of sea law, there are some required signals. Your boat may or may not be legally obliged to provide some. Check that too!

f) Boats have high masts, and sail on flattish seas. They get hit by lightning. Make VERY sure your design includes scope for surviving that.

I'm sure there's more, but I'm busy and it's a complex topic. Seriously, best of luck. Well-designed robotic sailing ships might do a lot for logistics.

Automation in Linux

[PtrToNull]

Having worked on development on robotic telescopes, both hardware and software, let me tell you that using Linux was not an easy choice. We had to narrow our search to vendors who explicitly support Linux, and even there, their support was flaky at best and we spent hours in troubleshooting the drivers before we got them to work. However, this exercise resulted in better support for Linux from the vendor, so it's a win-win situation. We opted for National Instruments for their excellent DAQ boards & LabView which are all supported under Linux.

For the control system, we used INDI, it's a powerful server/client control protocol that you can use to jump start your project within minutes. While it is geared toward astronomy, it can be used for any purpose.

FlowDesigner/RobotFlow

[jmv]

I'm biased because I'm one of the authors, but you may want to have a look at FlowDesigner and RobotFlow. It's a visual development for plugging blocks together and we've used it to control mobile robots and interface with sensors and actuators.

Thoughts from an amateur sailor/hacker

[An dochasac]

• You're going to have to make the gear strong, waterproof, salt proof. With this short of notice you might consider a commercial autopilot/GPS with a serial interface to a computer which should be well sealed. If I were going to "roll my own" autopilot, I might consider utilizing a printer driver and mechanism but scale up the motors somehow.
• Most commercial autopilots can't tack upwind. Since the trade-winds and gulf stream are against you, you're going to have to figure out how to tack.
• You'll need a way to cut down sail. The simplest would be for the main and jib to be roller furling, but it's more difficult to have roller furling mains. Another option would be to use a tiny or heavily reefed main and have the jib/genoa be your main sail power. This sacrifices upwind performance for simplicity wind speed flexibility.
• A mechanism to measure tidal drift and correlate it with predicted high/low tides would be useful. A dumb GPS based servo will waste lots of time and wind trying to correct course for tidal drift when it's possible that 6 hours later it will waste time and wind trying to correct course in the opposite direction!
• If you wanted to be really smart, you'd try to measure and predict wind direction. For example, if you know a high pressure system is passing to your north, heading west to east, you should expect the wind to gradually clock around to the from northwest to northeast.
• "Length must not exceed 4 meters" but North Atlantic waves regularly exceed 10 meters so your boat is going to be thrown around and shaken a lot and it will need to reorient itself.
• You won't have lots of power to spare, so an efficient CPU and efficient OS will be necessary, a stripped down linux or qnx might work. For power and reliability's sake you might even consider something ancient, a 386 or 68000 on a

Don't write algorithms on a PIC!

[Neil Jansen]

Why you would want to write a tacking algorithm on a PIC microcontroller is beyond me. I've written my fair share of embedded code over the years (I'm partial to ARM7's and ARM9's myself), and I'll tell you, if my project doesn't absolutely -require- something that small, I'll write it on a PC. Especially if time is a factor.

Even an embedded Linux platform (e.g. Gumstix) would be a bad idea for this project, as cross-compiling is a PITA. For rapid development (something I have much experience in), go with a standard PC with your development system of choice: C/C++, LabVIEW (really, not flamebait :) , MATLAB, etc.. Basically whatever you already know. Whatever can get data in and out of an ethernet port.

As for hardware, there are so many ways to go. If you have some cash laying around, go with National Instruments as their hardware line is well supported, has a very nice C/C++ API library, and will stand up to the elements pretty well. Even if you're on a budget, they sell some multifunction USB DAQs for less than $200. Buy your motor controllers and control wiring from Automation Direct they'll have almost everything you need.