Slashdot Mirror
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?"
MATLAB
Cheers!
Atheist: Buddhist in a Prius
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."
The first thing I would do to get a leg up in the competition would be to post the question to a technology website that garners millions of hits a day - a website that, more than likely, most of the robot boat-building teams are familiar with. That way, no one but me would have access to collective thoughts of hundreds of brainstormers.
You may be better off asking people within the sailing industry or a well-heeled engineering team. On /. you'll likely see this devolve into a heated debate about which flavor of *nix is better and why.
I couldn't help noticing that the rules forbid interference with other boats' electronic equipment and colliding with other boats, but say nothing about the use of, say, cannon. :)
Until someone gets to the Blue Waters of Death. Even better, this gives someone a chance to pirate Windows for real.
Evolving neural network for sailing project http://annevolve.sourceforge.net/
if you need close-to 100% reliability, set up 3 different hardware platforms with different OSes - then run the program(s) on each and interpret the result as a system of experts (i.e. choose what the larger group suggested). If one goes down or starts spewing bad results, you'll be able to detect it. ...I think that's how it works :D
Oh, and I'd recommend miniature/low power PCs for obvious reasons. That, or laptops.
Did you know that "FTW" ("for the win") is a direct translation of "Sieg Heil"?
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.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
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.
Jean-Francois Im's blog
Oh, sure, Linux can handle a USB port. But can it handle a USB starboard?
If it requires a driver and a Linux driver is available
Didn't you RTFS? It has to be autonomous. That means no driver.
What if I do the same thing, and I do get different results?
Just convert all the hardware devices to be USB portable into your CPU and plug-in-play should work seamlessly, and because VISTA is so bloated it will definitely stay afloat.
There's something to be said for using 10baseT to talk to control devices. 10baseT has better noise immunity than RS-232 and 5V TTL encoder signals. We had trouble with big servomotor PWM noise leaking into encoder signals, and a low noise in analog signals, but the 10baseT worked perfectly, even when near the engine of our robot vehicle. Not only is it differential over twisted pair, there's checking and retransmission.
The trend is towards putting an Ethernet interface on the thing to be controlled, rather than bothering with translation to CANbus. We used Galil motor controllers, which talk TCP and UDP over Ethernet. They're OK, but you can get comparable functionality in a smaller and cheaper package now.
10baseT has a feature that's important here - the connectors have retention latches, and don't fall out. USB does not latch, which is a showstopper in an industrial or vehicle environment.
Something we found useful was encapsulating boards. Mask the connectors with masking tape, and spray with Fine-L-Kote, which seals the board against humidity and provides some mechanical protection. Inspect under ultraviolet light (the stuff is clear, but glows) to see if you missed anything.
I am not convinced the AI is the difficult part of this. Developing a seamless hardware solution is very difficult, assuming it need to be very robust. The salty sea air only makes this harder on the hardware, especially the electronics. However good you think you can make the AI/software part, you might want to look around for someone that can do an even better job on the hardware side. I think (good-hardware + average-software) > (average-hardware + good-software) in the domain of this contest.
The quickest way that I know of to get your computer to talk to your motors is through a USB Data AcQuisition device (DAQ, for short). When we built a prototype ROV, we bought an off-brand China special for about $80 that had drivers for LabView. You will also need a motor controller. Some DAQs have Pulse Width Modulation (PWM) motor controllers built into them, but these are not cheap, in my experience.
Hook your DAQ up to your control computer (we used windows), and then your motor controllers to your DAQ. The power supply that powers the motors (12 V DC or more) goes into the motor controllers, and the signal from the DAQ goes into the motor controllers (USB is 5ish V DC, I think). The power to the motors comes out of the motor controllers, according to however you program it in Labview.
We used an Open Source Motor Controller (OSMC) that we built from parts.We used the system to vary the speed to 4 motors on the fly, using a computer interface that accepted input from a mouse and keyboard (just like Half-Life... sorta).
"I do not avoid women, Mandrake . . . but I do deny them my essence." - Gen. Ripper
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.
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.
Buy a commercial autohelm and feed its inputs with directions based on your gps waypoints and the local weather. You'll also need some kind of auto-main-sheet and auto-jib. Large yachts already have these. Heck, most cruise ships are already ocean-crossing robots. They don't even necessarily require the pilot's input for docking maneuvers anymore.
The trick, IMO, is creating a tacking plan based on your goals for the day, and knowing when to adjust it and when to just ignore local fluctuations.
Can you be Even More Awesome?!
The book "Robots op zee" (Robots at sea, P.W. Adriaans) deals with building a highly automated full-scale sailing boat to cross the Atlantic. Their first approach to control the boat was unsuccessful: it involved neural networks. The second approach was more successful, and involved expert systems in a cascading set-up, having a helmsman unit, a navigator unit, and a captain unit, a.o. The helmsman unit had windward and leeward defined in its internals, which proved by no means trivial. It is no project a pedestrian hacker would pull off in a few months. Another main hurdle for sailing oceans unmanned is the *robustness* of the ship's sensors: the ocean is a hostile place, and Adriaans is doubtful whether the sufficiently robust sensors are available at all. So (1)read the book, (2)have fun, and (3)good luck.
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.
Opus: the Swiss army knife of audio codec
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.