Slashdot Mirror

← Back to Stories (view on slashdot.org)

Xerox PARC Working On Modular Robots

Posted by Hemos on from the build-with-construtix dept.

An reader writes "I was watching Discovery Channel Canada last night, and they had a story about modular robotics that is being researched at Xerox PARC. Rather than build a single, large robot, project leader Mark Yim is working on small, autonomous bots that can work together to achieve a desired goal. When many of this bots are linked together, they call the result a polybot. "

3 of 83 comments (clear)

  1. Re:The Unix paradigm? by Osty · · Score: 3, Informative
    Isn't this similar to how Unix does things? Instead of monolithic applications (*cough* MS *cough*), we have a number of smaller apps that can be linked to do something else (i.e. awk, sed, grep, find etc).

    Although you may not realize it, Microsoft apps also tend to be many smaller pieces linked into a whole. Everything is a COM object. MSXML is an object that can parse XML, mshtml handles HTML. Word is a container for a bunch of COM objects (the word processor, the spell checker, the smart tags, etc), Excel is a container for a bunch of COM objects, IE is a container, and so on. Just because each one of these components is not a separate program does not mean that they cannot be reused or linked together.


    The standard UNIX "method" is to take all those "single-purpose" apps like awk, or sed, or grep, and glue them together with shell script, or perl script, or tcl script, or some other scripting language. The same method applies to Windows as well. You can access COM objects via WSH (using JScript, VBScript, PerlScript, or any other language that has an implementation of a COM interface that can plug into the Windows Scripting Host), and then you can glue those objects all together into a larger whole. What's more, though, is that you can utilize these objects within actual compiled code, as well. C, C++, VB, C#, any language with a CLR target, ASP/ASP+ (in C#, VBScript, JScript, PerlScript, ...) all can reuse thse objects, unlike in the UNIX model wherein a C app would have to fork to spawn a new process and exec something like grep or sed, make a system() call, or "borrow" code from those tools. And in the code-borrowing case, you're limited to the language that the code was written in (and close relatives, as you can use C code in C++ and ObjC for instance).


    Obviously, projects like KDE's KOM/KParts architectures borrow heavily from this idea, and succeed well. But these projects have much farther to go before they'll reach the level of binary reuse and interoperability that Windows has had for years. And yes, I know about CORBA, but compared to COM or KOM/KParts, or even Mozilla's XPCOM, it's cludgy, bloated, and nasty, and is a much heavier paradigm (for instance, it requires an object broker).

  2. More correctly called swarm robotics by DoubleTake · · Score: 5, Informative

    This research project is repackaged swarm robotics. Swarm robots have been around for years. The main problem with swarms is getting the power and leverage to manipulate large objects as the swarm is only as strong as it's weakest link. The main benefit is that they tend to be more fault tolerant than monolithic robots.

    See:
    Robotics portal
    Swarm robotics google search
    CMU Robotics Institute

  3. Re:The Unix paradigm? by kin_korn_karn · · Score: 2, Informative
    Yeah, MS stuff works like this, but you can't find out about it unless you're a MCSD, have access to TechNet, or buy several $50 books. On a Unix box you can type 'man sed' and 'man ksh' and get all the info you need to write solutions.

    I'm not the kind of OSS radical that says MS should open its source code, but it definitely should ship documentation of these tools with its OSes.