Slashdot Mirror


Open Design for ~$800 Swarm Robots

An anonymous reader writes "There are lots of multi-robot designs out there. Most are either research platforms well over $2K (often $10K or more), or are hobbyist bots under $400 with tiny brains and few sensors. But George Mason University's new FlockBots wiki is interesting. They're trying to pack as much functionality as possible into a roughly $800, 7" mobile swarmbot, and publish the design and software as a free and open spec. So far their design includes a wireless 200MHz Gumstix Linux computer, a camera, range and bump sensors, wheel encoders, a can gripper, and lots more. It's a great-looking design and I think the cost could drop to $500 with vendors doing consolidation."

6 of 106 comments (clear)

  1. Military applications? by CyricZ · · Score: 4, Interesting

    I wonder if we'll see freedom fighters in countries like Iraq and Afghanistan start to use robots like these such as weapons (assuming these researchers do succeed in keeping the cost low). Indeed, considering the US military's increased use of drones and unmanned combat vehicles, it is doubtful that those they are fighting against will not soon resort to employing he same methodologies.

    This particular device uses Linux, which brings up another question: should developers of open source software license their software so as to prevent it from being used in such killing devices? Or should freedom trump such an argument?

    --
    Cyric Zndovzny at your service.
    1. Re:Military applications? by cranos · · Score: 3, Insightful

      Nope not a chance. Part of the reason why the insurrgency has been so successful is the low tech aspect. This is something the US found and the forgot about in Vietnam. In a straight up battle, the US probably has the best technology in the world, against simple devices such as road side bombs and car/truck bombs they don't know what to do.

    2. Re:Military applications? by hoggoth · · Score: 5, Funny

      > should developers of open source software license their software so as to prevent it from being used in such killing devices?

      This is a great thought. By forbidding using open source software in killing devices we will cause great numbers of lawyers to approach the fighters to serve notice of the lawsuits. The fighters, of course, are already killing people and killing a few lawyers that get in their way won't bother them.

      Killers use up their inventory of killing robots.
      Software developers feel good about being on the moral high-road.
      Lawyers die.

      It's a win-win situation.

      --
      - For the complete works of Shakespeare: cat /dev/random (may take some time)
    3. Re:Military applications? by Admiral+Burrito · · Score: 4, Insightful
      This particular device uses Linux, which brings up another question: should developers of open source software license their software so as to prevent it from being used in such killing devices?

      Somehow, I doubt that people who would use the software for such purposes would be dissuaded by the licensing conditions.

  2. Interesting equipment choice by Sv-Manowar · · Score: 4, Insightful

    Its interesting that they chose to pair the Gumstix with the Acroname Brainsem. I've been working with the brainstem for mobile robotics as part of CSCS and found it extremely flexible for robotics development. In what we've been doing, we used the brainstem chained to Zaurus PDA's, to achieve a similar linux control environment for the actual board (as the TEA language used to program the brainstem is somewhat restrictive). This platform seems like a great way for people to start out with a known good set of equipment, something that would really have helped us when getting started. (We had a whole load of teething issues getting the PDA's and brainstems talking, not to mention creating working combinations of servos)

  3. Deterrent in the Field of Robotics by kai.chan · · Score: 5, Insightful

    Having an Open Design is well and good, but I think there is still one main factor that prevents the field of robotics from flourishing. The problem stems from the lack of standard in both the development of the software, hardware, and mechanics.

    Since there is no standard, someone can be using Microcontroller A with Motion Controller X using Programming Language N. Then finally combining these electronics with Servo K. When drivers for Motion Controller X has already been written under Programming Language M, developers have to spend time porting the code for another language for a different microprocessor, which might or might not work with the Servo.

    When there are so many variables in robotics without any standard, a lot of development time are wasted either porting code, finding minor differences between devices and motors that causes incompatibilities, or choosing non-optimal parts for ease of implementation. In order for the field of robotics to advance at a faster rate, there needs to be a more standardized open environment in the software, hardware, and mechanical aspect.