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."
I'd do it one weekend, in assembly, on paper.
And it would probably compile in one shot.
- Aetheral Research -
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'm always very fond of Linux because it seems to provide better raw access to system devices (serial and usb ports etc)
However, the ultimate question comes down to this: does the gear you have to interface with already have some kind of driver developed for it, or do you have to write the interface to those as well?
If its all serial, I would go with Linux. If it requires a driver and a Linux driver is available, I would still go with Linux.
We don't have much to go on here. I've seen people turn Linux boxes into coffee machines on crack (I think there is a man page out there somewhere) and other home automation systems that basically just use relays and a few other custom made components. Give us more details on your specific equipment and maybe you'll get better answers.
Ha ha! Winner... Windows.. thats funny.
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.
Yeah. I remember how Slashdot made a joke out of that the last time there was an article about a robot winning a competition using Windows.
Ooo man the floppy drive is broken. No wait. The computer is just upside down.
Evolving neural network for sailing project http://annevolve.sourceforge.net/
So how would you design a seamless interface between sensors and actuators to the high-level code?
Well, if the interface has to be seamless, I suggest carving it out of a solid block of wood.
The theory of relativity doesn't work right in Arkansas.
"So how would you design a seamless interface between sensors and actuators to the high-level code?"
It's called a programmable logic controller.
Lego Mindstorms.
Damn, it's spring now; we've only got three months! Will we be ready in time?
The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Shall we put two dwarf robots into it? we could save loads of energy!!!
I for one welcome out Transatlantic Robot Overlords.
Sorry about the writing. Robot fingers, you know? Cliff Steele in DOOM PATROL #23
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"?
You take a block of wood, and carve away everything that doesn't look like a boat. Right?
This issue is a bit more complicated than you think.
Why not some sort of embedded platform? Custom built and programmed. You can do that for the sensor and control equippment. You might find that power consumption is a lot less, and you'll have a lot more control over what you do, and might get better reliability.
I would suggest just recruiting some Monkey Ninja Pirate Robots to sail it for you.
With their 133t skillz, they should remain undetected unless a container ship carrying music cd's and/or movie dvd's comes into Ahoy! range.
Oh, and look out for sharks with friggin' lasers attached to their heads-bad for sailboats.
Down With Slashdot BETA!!! I've been around the corner and seen the oliphant; you can only abuse me from your perspecti
I think that the use of relative pressure on the helm would do wonders, speaking from a standpoint of doing much racing its not really moving the help more resisting the movement of the helm. I would try to get it to sense the speed rotation and yaw of the boat through accelerometers and have it resist presure and not adjust movement much. Hope this helps
There is hopeful symbolism in the fact that flags do not wave in a vacuum. --Arthur C. Clarke
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 about hardware, guys? I'm curious about this. How do you get a PC (Linux or otherwise) to talk to actuators, motors, etc?
You have apparently not seen Matlab's Realtime Workshop, which translates from Simulink to C for running on embedded systems. Of course, using this does mean that you have to program in Simulink. Unless your one of those (disturbingly common) engineers who just DON'T GET computers, it can make you want to stab things.
While I have no idea of your background, this seems like a fairly basic question. If you have the experience necessary to be competitive in a competition like this, then you should already have several answers in mind. I would recommend starting on smaller projects before tacking something as big as an autonomous sailboat. Then again if you have the time and money and want to fuck around for fun...go for it.
Comment removed based on user account deletion
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
I think there is an autonomous sailing contest from Columbia to the New Jersey Coast that has a huge cash prize. Enter it instead.
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.
Cuz then I suggest taking all the remaining Windows ME boxes and as many orange crates, pillowcases, car batteries and servos as needed and go for it!
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
RayMarine makes a really nice navigation system for sailboats (and other boats as well ...). They have wind sensors, water speed sensors, GPS with WAAS sensor (Ray Star 125), Auto-pilot (with compass), as well as hydraulic (or electrical) rams (for rudder control). These all connect seamlessly together via Raymarine's "SeaTalk" bus. They also offer NMEA (National Marine Electronics Association) I-O (essentially 4800 BPS serial ASCII) for easy interfacing. By reading these NMEA "sentences" you can learn position, heading, course over ground, wind speed and direction, water temperature, distance to a way point, cross track error to a way point, etc. Also, by writing (properly formed NMEA sentences) to the NMEA interface you can engage (or dis-engage) the autopilot, set way points for the autopilot, order steerage by wind angle, etc. Add a group 8 AGM deep cycle battery, a PC, a copy of LINUX, a couple of computer-controlled motors driving some self-tailing winches (for sail trim, reefing, etc.), a few solar panels for battery charging, a little software, and you should be home free (or to Europe - as the case may be...). Just remember - at sea the winds tend to veer in a clockwise direction (when viewed from above), so chose your tacks appropriately.
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.
But I like your style ;-)
While you do your project, I would urge you to post your solutions in great detail to push lots of the patentable material into the realm of prior art.
---
My perception is all societies will need zero carbon emitting low energy consumption autonomous vehicles. Your sailboat is exactly the vehicle needed for the low carbon footprint future.
----
I have been thinking about autonomous vehicles operating in the 1 to 4 mile per hour speed range. These vehicles will need a vehicle to vehicle communication process.
Someone recommended I review the one-laptop-per-child project. The OLPC laptop has ad-hoc peer to peer wireless networking built in. The laptop has a waterproof keyboard too.
Your sailboat should have the ability to communicate with nearby boats, right? Avoid collision, exchange wind and wave data, describe location and direction of travel, receive collision warnings, dodge oncoming tankers, heave to when being boarded at the end of the trip. For initial development, you will want a SSH link to a nearby boat and you will want to see what your boat is using as navigation inputs and rudder and sail angle control outputs.
Slow moving trucks going nose-to-tail down a highway will need a similar vocabulary to pass trip and safety information from vehicle to vehicle.
All this top level stuff should be available in a free software format. I mean should in the sense that the message language must be open. And second should in the sense that part of the problem has been addressed already. Perhaps reviewing kugle.com source code research engine might help you find source code. Perhaps there is a DARPA autonomous vehicle team that has written a vehicle to vehicle message exchange language.
How about a mast-top high brightness LED navigation light that broadcasts high speed data to other ships nearby? Sending out UDP packets in light flashes? Route the OLPC ad-hoc networking data stream up to an led and photo-transistor detector device.
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.
No contact with other boats, hence no collision. You could aim it at the sails or the structural components of the boat, hence no interference with the "electronic components".
Now all we need is the sharks to mount the lasers on :)
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
I used the SOAP protocol in my sailboat software. It melted in the water and my boat sank :(.
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.
Things break, make them redundant.
Reember to include GPS, and a sat receiver to get weather maps. Knowing about vawes and their sizes might also prove helpful, and femember to make a big keel to keep the boat stable. And waterprof it, so it can go down but will buoy up with the sail pointing in the right direction.
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?!
How can there be any debate? The only answer is Boating and Sailing Distribution.
I don't therefore I'm not.
What if this technology can be used by terrorists to ship all their WMDs to our shores?
Oh won't somebody please think of the terrorists!
When I read the title, I first thought about robotic _aircraft_. That seemed like a particularly bad idea...building transatlantic rockets for fun and profit! It's perfectly innocent, I assure you!
Please correct me if I got my facts wrong.
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.
The college a friend of mine went to tried doing something similar (actually, the vessel should have gone around the world instead of just crossing the Atlantic). They had to give it up due to some maritime law issue - apparently, ocean-going vessels need to be capable of picking up people in case of an emergency (like rescuing them after a shipwreck). Understandably, a small robotic ship that doesn't have any provisions on board doesn't qualify.
sensors read and write to the "blackboard" through the device drivers and the high level code also reads and writes to the "blackboard"...
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
My methodology would go something like this:
1. Determine most stable and speedy hull design that will accommodate servos, electronics and power storage. I'm thinking basically a mono-hull with two outriggers using a simple lateen style sail. Jib may be a problem.
2. Sensor needs... GPS I'm thinking. Design a self learning algorithm that can take a plotted course and learn how to sail it. Let the boat learn how to sail itself ala FPGA style.
3. Profit!
Codifex Maximus ~ In search of... a shorter sig.
Go for Player/Stage. It's an open source HAL for robotics. We used it in the lab I used to work for; it's very easy to use and has great documentation and community support. The biggest benefit of Player is the ability to use Stage to simulate your robot - code that runs fine in the Stage simulator will work just the same in real life. That's super important if you have a short development cycle for your project, and for this type of "robot adventure racing". Always remember the team that won the DARPA grand challenge was the one that spent the most time (by far) in testing.
'Every story, if continued long enough, ends in death.' --Ernest Hemingway
Assuming a 4 meter overall boat, it would be about 3 meters (ten feet) on the water line. Even a skinny competition yacht body would be more than 30cm wide, and more than 20cm deep - so the total mass could be easy in excess of 100kg.
You have space and mass for any kind of computing system you need - but batteries for a long flight would be a problem. Best solution? Build a real ship (wider, deeper) and use plenty of batteries as ballast.
Hmmm, no mentions about a multihull. It might be a good solution - I've sailed a catamaran recently, and it was a beginner's dream - it hardly heeled, and went nose in wind unchecked.
Software? you only need to know if you can point high enough in the wind, and if not, start wearing (tacking was difficult, as the very light boat lost speed incredibly fast when tacking).
So you need compass, wind vane and wind speed indicator. Plus some ways to reef the sail, and adjust how much you can point in the wind by how much sail you carry, and how much sail you carry by the windspeed.
My robotics lecturer at UWA last year entered the Microtransat last year, along with another CompSci lecturer who wrote the AI. They entered a machine that they had been working on for well over a year & was the third design after two previous unsuccessful past attempts. Does the OP really think that s/he can just quicky throw something together & expect to get anywhere?
I would think that the amount of batteries required for a multi-week trip would be pretty heavy. Maybe you could use a small generator with a small turbine in the water (I guess air couldn't work here). Although you would lose some speed, I don't think it would compare to the speed lost with battery weight.
PLCs (Programmable Logic Controllers) are the traditional way to solve the interface between software and hardware sensors. This is done in industrial computing and control all the time (Factories, manufacturing machines, robotics, etc). The sensors and actuators are connected to the Digital/Analog Inputs and Outputs of the PLC. The input signals are converted into variables (with ADC) that can be read like any other variables. The output variabels are converted back into the appropriate valtages and currents (0-10 VDC or 4-20mA). The I/O modules also do error, short circuit, wire break, etc. checks. Basically PLCs take out the hassle of having to build the hardware interface between the real world to the software.
Most of them are programmed in a graphical language called Ladder diagram (like relay logic dagrams in software). Some of the more advanced ones can be programmed in C or other 3rd generation languages. There is actually a standardised set of languages to program them, Structured Text is the one that is most C/Pascal/Basic like (see IEC 61131-3). There are libraries etc to support all the conventional control issues and yes you can build your own.
See companies like Siemens Automation and Drives http://www.siemens.com/, Rockwell Automation http://www.rockwellautomation.com/, Bernecker & Rainer Industrial Automation http://www.br-automation.com/, Schneider http://www.schneider-electric.com/ for more information.
whatever
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.
Given that it's a boat race on open water, maybe you should spend a *little* time thinking about hardware issues. If your key interest is AI maybe you should stick to simulators and lab based lego robots (or find a marine engineer for your team)?
"considered dangerous cargo" should be "considered dropped dangerous cargo"
Is assimilation of another boat seen as interference?
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
ai-0.net?
What kind of sensors do you have ? I would imagine:
- GPS
- Compass
- Wind direction
- Heeling angle
- Wind speed
- Winch positions
- Rudder position
From this information, it should be possible to write a pretty good 'software sailor'. It seems to me no AI is required. My software would:- Plot a course
- When the above course is to much into the wind, sail as close to it as possible.
- Make a tack when the target position comes at a certain angle.
- Use combination of wind speed, wind direction, and heeling angle to determine correct winch positions.
- Use a feedback control loop using rudder position and compass to control the rudder and maintain the planned course
- Repeat the above and win the race
:D !
Actually, I would like to help you write the software. That would be interesting.The first thing to consider is whether to edit the code with vi or Emacs. Until this important point is addressed, I don't see how we can move forward to the sailing engineering bits.
May contain traces of nut.
Made from the freshest electrons.
How about Rowbots?
I've already done this in April, and it works.
http://67.15.245.144/portfolio/navcom_ai/
You're welcome to contact me for info, or just grab the source code and schematics since it's all open. If you do contact me however, I've changed some code in the past two months that's slightly more efficient (it's on the Parallax website in the object exchange under Math AFAIK, if you can't find it, get a hold of me)
Matteo Borri mkb@libero.it
It uses the Parallax Propeller platform (8-core 80Mhz system that uses about 3 watts when all 8 cores are actively processing). This particular desing can be dipped in fresh water and keep running.
The previous event which was just run generated quite a lot of media interest including:
BBC News -- includes a video
The Register
UWA press release
Just follow the lead of these guys:Rubber Ducks.
You wont need any processors etc. and the whole kit can be bought complete from Toys'R'Us for less than a dollar.
Old COBOL programmers never die. They just code in C.
Imagine a beowulf cluster of these sailboats! If we had this, I am sure we would all welcome our robotic sailing overlords of the deep Atlantic waters.
--A non cow
There is no substitute for a good engineering team on a project like this. Perhaps a challenge for a local university of engineering students to help out.
But environmental concerns are that a PC isn't going to cut it. Imagine what salt water mist does when it gets sucked in.... My guess is you need ingenuity like you find on many of the devices on http://linuxdevices.com./
An SBC computer that is of low power and can be sealed from the elements. Many have no special needs for fans. You going to need the power to drive servos and motors so generating power from the sun and the boats motion including electricity storage is paramount. GPS and compass interfaces as well, possibly weather too. Maybe 2 SBC, one to control the boat and another to plan and guide the boat simple cross over Ethernet to communicate. You want a small computer(s) for space, weight and power consumption.
For software development, keep it simple. KISS rule applies. Don't get Java fancy, use straight up and simple C/C++ structures. Follow basic concepts of good embedded software design like avoiding memory allocation and associated leaks at run time. Modularize all the components. Find a good programmer(s) in embedded design and a good technical sailor and marry them if you have to. Having a good mechanical aptitude will help to. I am not sure how many servo systems you will need but they are needed and are the fingers of the system.
Design nothing of the hardware except plugging it in and sealing it from the elements, favoring COTs (common off the shelf) parts if available. Use a USB to a GPS for example. Or get the servos from an industrial shop. Your going to be under a time crunch to get that software working so leave as much time as you can to testing it. If it isn't tested, assume it does not work.
The only computing/electronic thing I'd wish for beyond GPS would be real-time weather data, more for storm avoidance than any wind-speed advantage - but I don't think you'll be getting that reliably in the middle of the Atlantic???
Really, you're more likely to have a stuck actuator than a computer system crash. I'd look to proven designs for radio-controlled sailboats, work up an algorithm to sail with the available wind (and furl before it hurls), and implement it on something that doesn't have a million lines of code in the OS.
Here.
When it comes to pastry theft, I take the cake.
Useful for pulling in sensor data and making dynamic predictions. I've seen marine navigation software that used this technique.
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.
You can buy all your interfaces for about 20k from National Instruments and run them in Labview. What I don't quite see is where you're getting the power to run your boat from. You will have winches for boom control and sail reefing, and actuators for your rudder. Unless you work with mechanical interlocks (which add lots of complexity and failure points) that allow you to power them down in "constant sailing mode" those will eat your power fast. Are you allowed a generator, or are you cladding your boat in 4 m^2 of solar cells and hope for good weather? Small keel boats are notoriously slow. speed in knots (nautical miles/hour)= 1.337 * sqrt(L ft) For a 10 ft water line, you get a little bit over 4 knots, what gives you over 20 days of travel time, a long time to run high power motors of batteries. But unless you can design a system that can replace a true helmsman (who can steer a boat in between waves to avoid capsizing)_ you are required to go with a self-rightening design. Multi-hull designs don't have that limitation, but once they flip, that's it.
I'm aging rapidly, I bought a new game and had no idea if my machine was good for it.
NMEA 0183 is an old and well tried standard for communication of marine electronics. On my sailboat it can interface the GPS with autopilot, thus making autopilot run the boat according to the course. If wind instrument is installed, autopilot can steer the boat based on wind direction. Electric winches exist that can also be easily controlled, if sail size needs to be changed.
If I was making this one, I would go with a single sail rig, something along the lines of Freedom sloops - it makes sail control much easier (essentially only needs to tack) and may be a permanent preventer to avoid jybe accidents.
AI for this sort of thing isn't going to be too complex - in fact a decent modern GPS navigator can do most of the work already (albeit can't chose the course by itself).
If you need more info on any of this - reply here, I'll post some links.
MATLOCK
Never say never. Ah!! I did it again!
There is one part that is gonna kick your ass, and that is the ocean.
Waves are going to be the tricky part, since unlike tree's and other obstructions they are constantly in motion and vary in both size and intensity on an almost random basis. These will be the problem since knowing when you can tack, safely, and not end up stuck in the trough and rolled or worse yet, pitch polled by your computer trying to sail up the face of a wave will be your greatest challenge.
As others have said, your basic hull design is going to make a lot of difference. A mono-hull will be the rule, I think, and one with enough keel to right itself. I would avoid cats or tri's and outriggers of any type, since they tend to cartwheel and once upside down its pretty much game over.
I would also go with sails modified with some drainage to help your righting arm coming back from a knock down, since you really wont be able to let go of the jib or main to facilitate same.
Your rigging is going to have to snarl free as well. I suggest a roller main to allow you to reef based on conditions and a roller jib in case you get into a blow and need to just roll it up and sail with only a reefed main.
There is a LOT of stuff that needs to be taken into account, best of luck.
Hey KID! Yeah you, get the fuck off my lawn!
This "soft-hard" thing you speak of is known as the system's "sensitivity", the associated maths is known as sensitivity analysis and can be used calculate risk/stratergy in all sorts of models including the Earth's climate, industrial robots, financial analysis, etc.
:).
Having said that and with some experience of rough seas in a 20m trawler, auto navigation/steering is probably the easy part of crossing the Atlantic with such a small autonomous craft - there is a lot of crap and dead trees floating about out there so I suggest a maze solving algorithm using weighted threats detected on the radar (you will need to instal this as high up as you can
It gets worse when you consider the performance of radar on a 20m trawler (roughly 10m above the waterline) is serverly degraded in a 4-5m swell, while a tree trunk hiding in the next trough is not a real threat to a trawler it can make a hell of a loud bang and put a nasty dent in the steel plated hull. It would certainly certainly sink an unwary 4m yatch, I would say use a commercial life raft to avoid sinking but that has obvious propultion problems.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
If you have to ask, then I believe you are getting in way over your head. We're talking about some extreme concepts here: real-time determinism, advanced data-capture algorithms, "artificial-intelligence".
If you're not already at least proficient in all these areas (and then some), I don't think you will be bringing any serious competition to this event.
Adapt, adopt, or get out of the way!
"So how would you design a seamless interface between sensors and actuators to the high-level code?" Personally, I would use Perrone Robotics' MAX platform. http://www.perronerobotics.com/ We're already using it in planes, an entry for the DARPA Grand Challenge last go-round, and a new entry for the Urban Challenge this go round. http://www.teamjefferson.com/
There is nothing so good that someone, somewhere, will not hate it.
Use a Kestrel 4000 (or any 4x00) Pocket Weather Meter Station attached to whatever computer you use, it's the best weather station with an optional USB link.
I don't know how many /.ers have any sailing experience, but I'm guessing I'm one of just a few. It seems that this competition is reinventing the wheel. The sailboat that my family uses is perfectly capable of sailing itself to wherever you would like. If you sail without a jibb(the front sail), it can even handle tacking(turning the bow through the wind). Sailboats already come with sensors for wind speed, wind direction, etc and GPS, and you can bring up the GPS, put the cursor on a point (that you could get to without going over land) and say, go there, and the boat can do it all.
So it seems that the only challenge is how will you make sure you don't crash into anything? I'd say read up on the rules regarding right of way on a boat (I believe a portside tack always has the right of way) and that should give you right of way over all the other boats. And as long as the course isn't in the arctic, you shouldn't have too much else to worry about.
Here's what I'd do. Design and build to win, not just survive. It has to survive to win but if you build it like a tank, it will sail like one. Build it strong enough for the expected worst conditions, but no stronger. Watch the weight. Light is fast. OTOH, I doubt you could build it considerably lighter than the 40Kg weight limit. The boat doesn't have to look like a yacht. For speed, the waterline should be maximized. Make it the full 4m. With no one aboard, it doesn't need a particularly dry deck or have a comfortable motion. The hull could look like a torpedo, it could be semi submerged to reduce energy robbing wake. Or it could be a dish-like planing hull. It doesn't need to resists capsize, it just needs to self-right when knocked down. Keel type is a trade-off. A narrow, deep, bulb keel is faster, more efficient in counteracting heel and leeway. A long shallow keel makes the boat easier to keep on course, requiring fewer steering inputs.
For rig, forget cloth sails. I'd use a single efficient tall high aspect solid wing. Rotate the wing to power up or reef. If it gets knocked down in a storm, it will self-right. Nobody dies and the storm will pass. Will the crossing be in the trade wind belt or in the North atlantic? Design the rig for the expected winds. Optimize your course based on the boat's polars, maximize VMG (velocity made good.)
Power management will be the biggest systems challenge. Use solar cells on the wing to recharge batteries for the night. Minimize loads so e.g., use LEDs for navigation lights. Wake up the equipment as needed, otherwise keep it asleep. Use the assist of the wind and forward motion of the boat as much as possible. For example, miniaturize a sturdy yacht windvane self-steering rig. With their servo tab actuators, these require zero electricity to steer. The only control you'll need to actuate is the wind angle setting.
This looks like fun.
"So how would you design a seamless interface between sensors and actuators to the high-level code?"
That's probably the easiest problem you will have in the whole project. Why are you asking about it?
The way Linux handles the RS232 comm port (serial) makes it super freakin' easy to send and recieve messages to another serial device. I was passing messages to and from hyperterm on my webserver box within minutes of finding a few examples in C. Oh yeah, most Linux distros can compile C into an executable real easy too. You want to start from scratch have total control? Get yourself a PLC (programmable logic controller) with termination points for all of your physical IO, and that will also talk modbus ASCII. Write a program that will take a .txt file or SQL database or whatever your favorite poison and transfer to and from the PLC where your physical IO lives. You'll have to read a couple pages of modbus message structure and create a couple custom ASCII messages, but again it shouldn't be that hard.
Now all you have to do is write your high-level code to read/write to that database and you should have full access to all your sensors and the ability to write to (control) your servos and motors. The upside is that PLCs are generally tough as hell (NEMA4X) and you can run the Linux control AI programs on small industrial PCs (ICL makes a really cool one) that are also untra tough. Sea-faring tough.
This challenge sounds like fun all around. As far as how to design software to accomplish a task like this I have designed just a system(ERC), twice in fact. It is relatively simple to write software to collect data from sensors but the hard part is normally distributing and analyzing that data. The system that I helped write is called ERC or Extensible Robot Core. ERC allows data to be collected and analyzed by several machines in an effort to map the robots environment. A task like sailing seems like a much simpler one than what I have been developing code for as I doubt a sailBot would need to map building techniques such as SLaM. Additionally, I would think that the number of sensors would be very low; a GPS unit, some way of measuring wind speed and direction, and a magnetic compass to keep track of your heading should do it, plus some odds and ends(potentiometers and encoders) to keep track of the positions of all your actuators. On the computation side of things I would think that you could pull this off with nothing but embedded micro-controllers, though it would be easier with a small PC. I personally would opt for a small ITX PC or smaller with one or two micro-controllers to interface between actuators and their feed back sensors. All in all this sounds like a very doable and fun challenge, wish I could participate, I'd love to teach my PC to sail!
Make a jet propulsion unit, sitting up off the back of the boat, so the spray shoots backwards at about .5metre above the water.
Then, just after passing a competitor's boat, cut in front of it.
The blast from your jet would theoretically strike the other boat about the middle of the control deck, having the reaction of either massively slowing the other boat down, or potentially blowing it off course.
Do that to enough of the competition, and it doesn't matter how long it took YOU to finish, because none of the others could get close enough to pass you.
=)P
Let's hope you do better then the titanic
Think even more "laterally." Who says the pieces of wood have to be dead? Graft them and let them grow until there's no seam!
Figure out how fast your actuators (rudder, sail, etc) can affect your ship, and scale your "real time" system appropriately. It's hilarious reading the comments describing exotic high speed high power real time systems more suited for hypersonic active airfoils and realtime audio DSP, when realistically, you only need to adjust the rudder and sails every couple seconds, at most. Besides, assuming you could miraculously swish the rudder back and forth at a 100 Hz rate, it would take too much power and cause too much drag and wear the actuators out very quickly.
A previous poster was complaining it is "too hard" to cross compile your app for a non-pc linux based controller. The solution is simple, use an interpreted language, whichever you're most comfortable with and has the best libraries, or use scripted apps, like octave to calculate your course based on your position and target and some perl or expect to interface it with your actuators.
Human boats have huge wide open interior volumes for bunks, passageways, food, storage, repair parts, etc. The average interior density of a human ship is probably about half that of water. You can fit a huge number of batteries in there (right above the keel, if not inside it). Then fill the rest of the ship with styrofoam. You'll have a lower center of gravity than a human ship, also who cares if the hull cracks from hitting a tree trunk, if less than 5% of the volume of the ship can be flooded? You only have to concern yourself with gross structural integrity, and again, no humans on board means you can put support beams everywhere in weird locations and use relatively small watertight compartments.
Install at least 3 compasses, 3 GPSs, 3 weather stations, and have some comparison routines toss out the outliers and average the remaining ones. A gyrocompass might be a good idea too.
A simple, reliable system that goes a little slow, will win against a fast and fancy system that breaks down.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
I would recommend the Mathworks Simulink tool chain which includes the new Embedded Coder. The resultant C code is readable and testable (as compared to RTW alone). The requirement to solve the abstraction from the control to the I/O (actuators, sensors) is an embedded platform that bridges Simulink algorithms to real, embedded hardware. Many vendors provide prototyping or instrumentation h/w such as the Mathworks XPC. You might also check out rugged, embedded modules that are Simulink "programmable" using the MotoHawk tool from MotoTron. http://www.mototron.com/products/MotoHawk
First, a full-sized computer? Power issues come to mind. But maybe you're allowed to refuel or recharge, I dunno.
As for the interface between sensors and your computer, microcontrollers are the bomb. Cheap, easy, fast, low-power, and designed for just that sort of thing. One $8 microcontroller, a $4 USB->serial chip, and a few passive components later, you've got something that can not only take readings (serial or analog) from a good number of sensors and pass them back to your computer, it's got enough power that you very well might find yourself passing more duties off to it as well.
Oh, you're not stuck, you're just unable to let go of the onion rings.
I work with the Roboat team which won the Microtransat competitions in 2006 and 2007. As you might know, the big challenge to cross the Atlantic ocean is scheduled for Autumn 2008. Prior to this event we plan to organise one more competition for autonomous sailing boats on Lake Neudsiedl in Austria (ca. 60km from Vienna). The intention is to provide - ahead of the transatlantic crossing - a training environment and a competitive challenge amongst companions with alike intentions. This should be a chance to (final-) test our boats, equipement and crew before heading out to see. Furthermore this event on a lake would give new teams the opportunity to participate who are not yet ready to sail across the Atlantic Ocean.
The event is set to last a week, prospective the 17th - 25th of May 2008. Races would be held from Wednesday until Sunday after a few days for test runs and social program.
If you are interesed in this event don't hesitate to ask for more details at contact@innoc.at. And have look on our Roboat
Cheers,Roland