[ Home | Events | Robots | Humans | Projects | About | Account ] 

Recent blog entries for MartinCalsyn

1 Oct 2003 (updated 1 Oct 2003 at 22:24 UTC) »

Jake Mendelssohn just resigned from the Trinity Firefighting Contest... http://www.jake.men delssohn.name/

1 Oct 2003 (updated 1 Oct 2003 at 22:20 UTC) »

Robothon is coming...Oct 25, 26 in Seattle

I've got the following entries cooking

  • DoodleBug - Line Maze Event - A 68332 (MRM) based line follower built on a two-level 6" circular base. The drive system is based on a dual-motor Tamiya tractor kit driving hobby wheels. This is the same Tamiya kit that donated the tracks for ShoveBug
  • ShoveBug - Traditional Mini-Sumo - A 68332 (MRM) based 500g sumo bot with tractor treads driven by hacked servos.
  • Atlas - 3kg Sumo - Another 68332 project - This is the least baked of the three and I may drop this bot in favor of finishing FireBug 2.0
  • FireBug 2.0 - Fire Fighter - A fast-moving x86 based bot with PIC sub-processors. This is the most advanced bot from the standpoint of sensors, drive system and software. It'll be a real challenge to wrap up by the end of the month.

    All of the bots are using the same control-system software - a subsumptive architecture based on message passing.

    • 23 Sep 2003 »

    I've been doing a lot of thinking lately about the applicability of message-based systems and process calculii to robot programming. It seems that message-passing and process calculii (like the Pi-Calculus) would be extremely useful in implementing behavioral and subsumption programming for robots.

    Forget the definition of 'process' that you know now and consider every behavior - in fact you could even consider every component of a behavior - to be a process. Consider that all processes run asynchronously and in parallel. Each process exposes a contract and the communication between processes is by messages.

    Now, if your drivers and behaviors are processes and each exposes a contract and each communicates with each other via messages, you have

  • an excellent framework for distributed processing among processors within your robot and easy relocation of processes from one cpu to another
  • an excellent framework for cooperating with other robots - even those made by other builder/programmers since you need only agree on the process-contracts (note that process contracts document not only the message contents but the permissible ordering of messages)
  • support for real-time computing by prioritizing messages
  • a means of implementing behavior subsumption by redirecting, throttling or discarding messages.

    I'm currently trying to work up a framework that would allow for familiar C/C++ programming within a process- oriented-programming messaging-bus framework. Modules would be coded in C or C++ and described by contracts in an xml document. The modules could communicate to other modules only through messages and the framework would match messages to contracts (a key component here is that modules should not know about each other a-priori, but should be paired up solely because a message that was sent by one module matches the contract exposed by another.

    In any case, that's the path I am taking with my current work. Watch here or on the Scarab Robotics web site for more info.