<?xml version="1.0"?>
<rss version="2.0.">
  <channel>
    <title>robots.net blog for MartinCalsyn</title>
    <link>http://robots.net/person/MartinCalsyn/</link>
    <description>robots.net blog for MartinCalsyn</description>
    <language>en-us</language>
    <generator>mod_virgule</generator>
    <pubDate>Sun, 6 Jul 2008 01:08:25 GMT</pubDate>
    <item>
      <pubDate>Wed, 1 Oct 2003 21:27:47 GMT</pubDate>
      <title>1 Oct 2003</title>
      <link>http://robots.net/person/MartinCalsyn/diary.html?start=2</link>
      <guid>http://robots.net/person/MartinCalsyn/diary.html?start=2</guid>
      <description>Jake Mendelssohn just resigned from the Trinity 
Firefighting Contest... &lt;a href="http://www.jake.mendelssohn.name/" &gt;http://www.jake.men
delssohn.name/&lt;/a&gt;</description>
    </item>
    <item>
      <pubDate>Wed, 1 Oct 2003 20:04:52 GMT</pubDate>
      <title>1 Oct 2003</title>
      <link>http://robots.net/person/MartinCalsyn/diary.html?start=1</link>
      <guid>http://robots.net/person/MartinCalsyn/diary.html?start=1</guid>
      <description>&lt;a href="http://www.robothon.org" &gt;Robothon&lt;/a&gt; is 
coming...Oct 25, 26 in Seattle&lt;p&gt;
I've got the following entries cooking
&lt;li&gt;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
&lt;li&gt;ShoveBug - Traditional Mini-Sumo - A 68332 (MRM) based 
500g sumo bot with tractor treads driven by hacked servos.
&lt;li&gt;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
&lt;li&gt;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.
&lt;p&gt;
All of the bots are using the same control-system software -
 a subsumptive architecture based on message passing.</description>
    </item>
    <item>
      <pubDate>Tue, 23 Sep 2003 23:58:33 GMT</pubDate>
      <title>23 Sep 2003</title>
      <link>http://robots.net/person/MartinCalsyn/diary.html?start=0</link>
      <guid>http://robots.net/person/MartinCalsyn/diary.html?start=0</guid>
      <description>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.
&lt;p&gt;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.
&lt;p&gt;Now, if your drivers and behaviors are processes and 
each exposes a contract and each communicates with each 
other via messages, you have &lt;li&gt;an excellent framework for 
distributed processing among processors within your robot 
and easy relocation of processes from one cpu to 
another&lt;li&gt;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)
&lt;li&gt;support for real-time computing by prioritizing 
messages&lt;li&gt;a means of implementing behavior subsumption by 
redirecting, throttling or discarding messages.
&lt;p&gt;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.
&lt;p&gt;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.</description>
    </item>
  </channel>
</rss>
