Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Robotics

Trans-Atlantic Robots 203

Posted by samzenpus from the give-me-robot-planes dept.
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?"
This discussion has been archived. No new comments can be posted.

Trans-Atlantic Robots More

Trans-Atlantic Robots

Comments Filter:

  • In one word? (Score:3, Informative)

    by vigmeister ( 1112659 ) on Wednesday October 03, 2007 @09:55PM (#20846991)
    MATLAB

    Cheers!

    • Re: (Score:2)

      by sokoban ( 142301 )
      Unfortunately, in order to do MATLAB you need to have already finished C.

      http://koentmnd.ytmnd.com/ [ytmnd.com]

    • Re: (Score:2, Insightful)

      by eggnoglatte ( 1047660 )
      For a realtime system? Surely you are kidding.
      • 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.
        • The problem is (last I worked with it) the generated code is absolute garbage. Your variables are a, aa, ab, ac, ad, aaa, aab, aac, etc - no rhyme or reason to them. Functions do not have meaningful names. You can take that generated code and compile it against your project and hope to God it works, but if something doesn't work, you are virtually hopeless. No tweaking.

      • Re: (Score:2)

        by Fred_A ( 10934 )
        Do you actually need realtime for a sail boat ?
        (just wondering)
        • I'm not a real expert, but I had some experience in systems that are not "hard real-time".

          I can't recall exact definitions, but there are "soft" and "hard" real-time systems. In soft systems you can miss some deadlines. Like in video game, where you don't want to skip the frame, but from time to time that happens and its not a big deal.

          Some very expensive systems are soft real-time. For instance, AGC - which is basically fine-tuning of power system's frequency (to keep it 50 or 60 Hz) is not hard real time.

          • Re: (Score:2)

            by Fred_A ( 10934 )
            It seems to me that 4 seconds would be plenty enough reaction time for sailing (40 probably would be enough actually).
          • This "soft-hard" thing you speak of is known as the system's "sensitivity", the associated maths is known as sensitivity analysis [wikipedia.org] 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 o

    • Re: (Score:3, Informative)

      by 0100010001010011 ( 652467 )
      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
      • I believe SpeedGoat, a MathWorks partner, has a ruggedized xPC target box we are planning on using in a marine environment. Its expensive, but you're going to have to drop at least 4 grand anyway to get something ruggedized, plus MATLAB/Simulink and the RTW addon, plus the xPC blockset will run you around 10k as well, unless you qualify for student versions. You will need to make sure that whatever hardware you do pick has analog and digital inputs and outputs, so the PC104 IO expansion cards in a ruggedi

    • Re: (Score:2)

      by itwerx ( 165526 )
      MATLAB?!? WTF?!?

      Other than some solar power all he needs is a GPS unit with a serial feed to a PIC motor controller and some code for steering based on current location.

      • Re: (Score:2)

        by Nullav ( 1053766 )
        You need more than a GPS, motors and a power source to sail. While land stays in the same place, the wind will no doubt change direction plenty of times. The boat would need a power source, a way to determine wind direction (and adjust sail accordingly), position, and possibly wave height. (Don't want the boat to capsize, after all.)
      • Why you would want to write a tacking [wikipedia.org] 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 [gumstix.com]) would be a bad idea for this project, as cross-compiling is a PITA. For rapid development (something I have much experience in), go w

        • Re: (Score:2)

          by itwerx ( 165526 )
          algorithm on a PIC microcontroller

          That was just to keep power consumption to a minimum.

    • Re:In one word? (Score:4, Interesting)

      by Anonymous Coward on Thursday October 04, 2007 @06:06AM (#20849677)
      I've already done this in April, and it works.

      http://67.15.245.144/portfolio/navcom_ai/ [67.15.245.144]

      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

  • URBI (Score:5, Informative)

    by bobby1234 ( 860820 ) on Wednesday October 03, 2007 @09:59PM (#20847035)
    http://www.urbiforge.com/ [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."

    • Re: (Score:2)

      by jdray ( 645332 )
      With a Java interface, I wonder if you could get some traction combining URBI with SunSpot [sun.com] [PDF] nodes for controller interfaces...

  • Well, DUH! (Score:5, Funny)

    by Anonymous Coward on Wednesday October 03, 2007 @10:01PM (#20847063)
    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.

    • you'll likely see this devolve into a heated debate about which flavor of *nix is better and why

      How can there be any debate? The only answer is Boating and Sailing Distribution.

    • Re: (Score:2, Insightful)

      by pwolk ( 912457 )
      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 p

    • Re: (Score:2)

      by Fred_A ( 10934 )
      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.

  • approach (Score:5, Funny)

    by belmolis ( 702863 ) <billposer@@@alum...mit...edu> on Wednesday October 03, 2007 @10:09PM (#20847129) Homepage

    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. :)

    • Re:approach (Score:5, Funny)

      by Rakishi ( 759894 ) on Wednesday October 03, 2007 @11:05PM (#20847577)
      Well they may consider the cannot round to be part of the boat thus it hitting another boat being a "collision." On the bright side even if you do get disqualified for such an act the DARPA grant you'll get soon afterwards will probably be worth more than the competition prize.
      • Hmm...that's a tricky obstacle. How do you cheat if nothing on your boat can touch other boats, and you can't EM them...

        Wait...water gun. Super High Powered Water Gun. Doesn't use any mass off your boat (ergo you can't claim collision) and doesn't 'directly' interfere with electronics (if it's not properly sealed, which would be a little silly first off, then it might interfere). Just got to get enough PSI and a good targeting system.

        The best part? Infinite ammo, as long as you have power you can hit the ot
      • Think about it...

        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 :)

      • http://www.sailwx.info/shiptrack/shiplocations.phtml [sailwx.info]

        With the help of GPS, some small Azipods from

        http://www.abb.com/cawp/seitp161/d9b2b9b6ef1f600cc1256fdf003b2929.aspx [abb.com]

        (hey, maybe they will be willing to sponsor a LINUX-controlled craft?)

        and some backing from other sources and I'm sure this can be done. After all, it's not as if Omega or LORAN are the navigation sources.
    • True, but there is nothing in the rules that states you can't have a shark-mounted cannon.

    • the rules forbid interference with other boats' electronic equipment and colliding with other boats

      Wouldn't that make running the system on Windows illegal? I mean, surely the potential of suicide bombing would violate the rules too.

      :-)

    • Re: (Score:3, Funny)

      by Xeirxes ( 908329 )
      Forty years later, the ocean is still overrun by four-meter long robotic attack ships, who refuse to allow any ship passage.

  • AI link (Score:4, Interesting)

    by SPickett ( 911670 ) on Wednesday October 03, 2007 @10:15PM (#20847177)
    Evolving neural network for sailing project http://annevolve.sourceforge.net/ [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.
    • I suggest carving it out of a solid block of wood

      You take a block of wood, and carve away everything that doesn't look like a boat. Right?

      • Re: (Score:3, Insightful)

        by fractoid ( 1076465 )
        Alternatively, you carve a bunch of boat-shaped pieces out of the block of wood, and then assemble them. But that would be thinking laterally. ;)

        "God Works in mysterious ways". "Shit Happens". Can anyone explain, obvectively, the difference?

        Partitioning of responsibility. "Shit happens" is simple acceptance of the universe's imperfection. "God works in mysterious ways" lets you know that if anything good happens, God did it. Of course, if anything bad happens, you deserved it. If despite all the Church has done for you, you still don't think you deserved it, then it's a test of your faith.

        • Alternatively, you carve a bunch of boat-shaped pieces out of the block of wood, and then assemble them. But that would be thinking laterally. ;)
          The key attribute was seamless. :)
  • Damn, it's spring now; we've only got three months! Will we be ready in time?
  • I for one welcome out Transatlantic Robot Overlords.

  • Just do what NASA does (Score:3, Interesting)

    by Fry-kun ( 619632 ) on Wednesday October 03, 2007 @10:35PM (#20847347)
    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.

    • Re: (Score:2)

      by Cecil ( 37810 )
      That's unfortunately not a foolproof system if they're all running the same software. It is possible, perhaps even likely, that they will all fail in the same way at the same time for the same reason, leaving things completely out of control. See the Ariane 5 accident [around.com] for a practical demonstration.
      • 1. That's not NASA, that's ESA
        2. They used **identical** hardware. The proposed system would use different hardware.
        3. They didn't bound check a conversion from a 64bit to 16 bit.
        4. The real killer - they were running unnecessary code. They didn't even need this bit of code, yet it had the power to take down the rocket.

    • Re: (Score:2)

      by Aladrin ( 926209 )
      Did anyone else just have a Minority Report flashback?

      Oh, and ignore the idiot about FTW. You had it right, he's obviously had a bad upbringing.
  • 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.

  • Possible Architecture (Score:4, Informative)

    by mechsoph ( 716782 ) on Wednesday October 03, 2007 @10:57PM (#20847503)

    PC (maybe mini-itx) running *nix talking via Ethernet/IP to a Netburner [netburner.com] 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.

    • Using Ethernet to control devices (Score:5, Insightful)

      by Animats ( 122034 ) on Wednesday October 03, 2007 @11:43PM (#20847831) Homepage

      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.

      • Ethernet is not suited for realtime. Random delays in cases of collision are bad, though perhaps not as bad on switched networks. Ethernet's large message sizes increase latency, which is also bad. TCP is also not suited for realtime. You could use UDP, but then you have to guarantee delivery yourself. CAN handles collisions based on message priority guaranteeing delivery. Messages are limited to 8 bytes, so latency is low.

        If you only need soft realtime, then ethernet would probably be easier. How

        • Re: (Score:3, Insightful)

          by Animats ( 122034 )

          See Making Ethernet Work in Real Time [sensorsmag.com], from Sensors magazine. They show how to calculate the odds of delay exceeding a given value for a given network speed and loading. With a 10 Mb Ethernet, sending 1000 64-byte packets per second, you can be 99% sure there will not be a delay of more than 7 ms in 9 years. You can't load the network very much (5-10% is tops for a real time application). But the odds of an error are higher than the odds of a timing miss.

          CANbus latency is only deterministic for the hi

      • Re: (Score:2)

        by bhima ( 46039 )
        What's so wrong with CANbus? I've used it for a while... after we moved from RS-485.

        You are right about the physical connectors for 10bt, though at first I thought you talking BNC. However I don't think any of those connecters are up to saltwater. I wonder what they use in boats and military applications. I'll bet something scrounged from military surplus would be better.

      • Re: (Score:2)

        by mstahl ( 701501 )

        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.

        Hot glue is always a good solution to that sort of thing. Holds better than those little tabs on the RJ connectors too. (Please excuse me if this is painfully obvious; it seems insightful/informative to me because it's early in the morning.)

      • There are cheaper multi-master buses for linking micros together with, as the grandparent mentioned CAN 2.0B is one. CAN uses a differential 2 wire bus with built-in CRC's implemented in the hardware. As I have worked in avionics and currently am working doing maritime controls, I can say definitively that CAN is the way to go. However, PC support for CAN is expensive, so use CAN to link the various micros and have one chip with both CAN and Ethernet.

        To be honest I don't see why you would need anything m

  • What we use (Score:5, Informative)

    by jfim ( 1167051 ) on Wednesday October 03, 2007 @11:10PM (#20847609)
    Our team(SONIA [etsmtl.ca]) 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 [wikipedia.org] 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 [vector-cantech.com].

    As for hardware, we use the Kontron JREX SBC [kontron.com] 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.

  • Use VISTA (Score:2, Funny)

    by RSA7474 ( 1163263 )
    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.
    • Dave, I detect that you are trying to cross a large body of water. This could be dangerous. Do you want to:

      COntinue?
      Stop?
      As more questions?
  • 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!

  • 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.

    • Thoughts from an amateur sailor/hacker (Score:4, Informative)

      by An dochasac ( 591582 ) on Thursday October 04, 2007 @05:18AM (#20849411)
      • 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
      • I'd say go with a junk rig sail setup. You'll lose a little bit of efficiency but in exchange for a much simpler sail setup. It would simply be a matter of hoisting and lowering the sails rather than furling and unfurling.

        My two cents as an armchair/weekend sailor.

  • The real challenges (Score:2, Informative)

    by 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 sm

    • Re: (Score:2)

      by nietsch ( 112711 )
      A) that is mostly a design problem. On a fullsize boat the rudder is relatively weak. The smaller the boat, the loads on each part go down exponentially (or cube size?). The forces on say the rudder of a 10 ton boat (40') are much bigger than the forces on a 100 kg boat.
      b) design problem too. Pot all electronics in suitable goo & install automatic bilge pumps.
      c) Yes, you can get marine forecasts, either codified (but for human consumption) or as fax-like maps. Both would require serious logic to interpr
    • Speaking of Laws of the Sea/Admiralty/etc. This craft will be unmanned. Who will pay the bill for escort services? If it's approached, found to be unmanned/unoccupied, in international waters, is there gray area to declare it a derelict (tho it's autonomous)? Could it be seized (might be to small to be "boarded") for a "prize crew"? If someone fired warning shots across its bow, and it didn't heave to, what happens?

      Some enterprising types might even steal it and auction it off for $2,000...

  • Automation in Linux (Score:4, Informative)

    by PtrToNull ( 742886 ) on Thursday October 04, 2007 @12:55AM (#20848229)
    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 [ni.com] for their excellent DAQ boards & LabView which are all supported under Linux.

    For the control system, we used INDI [sf.net], 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.

  • silly race, really. (Score:3, Insightful)

    by zippthorne ( 748122 ) on Thursday October 04, 2007 @01:01AM (#20848271) Journal
    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.
  • 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!
  • 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 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 emerge

  • sensors read and write to the "blackboard" through the device drivers and the high level code also reads and writes to the "blackboard"...
  • 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!
  • 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 gran
  • 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
  • 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)?

  • FlowDesigner/RobotFlow (Score:3, Informative)

    by jmv ( 93421 ) on Thursday October 04, 2007 @04:58AM (#20849347) Homepage
    I'm biased because I'm one of the authors, but you may want to have a look at FlowDesigner [sourceforge.net] and RobotFlow [sourceforge.net]. It's a visual development for plugging blocks together and we've used it to control mobile robots and interface with sensors and actuators.
  • The previous event which was just run generated quite a lot of media interest including:

    BBC News [bbc.co.uk] -- includes a video
    The Register [theregister.co.uk]
    UWA press release [aber.ac.uk]
  • Just follow the lead of these guys:Rubber Ducks. [bbc.co.uk]

    You wont need any processors etc. and the whole kit can be bought complete from Toys'R'Us for less than a dollar.

  • 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./ [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 nee

  • 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 de

  • "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?
  • 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 cau
  • 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 en

Slashdot Top Deals

"Being against torture ought to be sort of a multipartisan thing." -- Karl Lehenbauer, as amended by Jeff Daiell, a Libertarian

Close