Why embedded operating systems are a dead end...

With the (re)rise of concurrency (in particular concurrent processors),  embedded operating systems are a dead end.  This is especially true in robotics. 

Why?

Once you get linux (or whatever) running on your embedded hardware (robot?) , you then spend some time getting all of the interrupts right and then compile your high level control language into C (and then compile that into the target MCU) and then... you emulate concurency via threading/tasks. If you go beyond C, you are probably running in a general purpose VM to boot.

For every lift of a mechanical leg, a megabyte or so of code abstraction, translation and OS task switching takes place. Ugh.

What is the alternative?

Very High Level Languages compiled directly to (or interpreted tightly within a simple VM upon)  hardware with an inter-device messaging protocol.  I want my Lisp/Oz/Haskell/Erlang/etc running on bare metal, baby! (And all programmed from within Emacs running on my laptop ;-)

Of course, Forth programmers already had this 20-30 years ago...

Scratch + iRobot Create?

I stumbled upon information regarding the mysterious Scratch Extension Protocol. This is very interesting.  It addresses a deficiency in Scratch that prevented integration with external things such as robots.

In my opinion, one of the greatest hinderances in getting kids involved with robots is the difficulty in programming them. The root of the difficulty is syntax: So you've got an iRobot Create, want to make it move? Use C, Basic, Python or whatever.   Scratch seems like a natural for this.

With the Extension Protocol, I can write a small piece of middleware that would talk to the Create via wireless (Bluetooth maybe?).

I'm not sure where I would put all of the Create protocol parsing and generation. The easy way would be to place it in the middleware, but there is something "just right" about putting it into a microcontroller that is attached to the Create.  I think I prefer that way because it offers a future hint of autonomy.  Adapting the Scratch Extension Protocol to Create Protocol can be more than a simple protocol translation excercise but evolve into a language of sorts. 

Imagine this: 

1. You develop your ScratchCreate script in Scratch, first controlling an on screen Sprite that represents the iRobot Create.  
   
2. You then launch the middleware and continue to debug the script but now control an actual Create wirelessly.  
   
3. Once you've got it working the way you want, you download the Scratch script into the microcontroller running the Create. 
   

Voila, you now have an autonomous robot!

This is a powerful concept.  I know there are similiar commercial variations on this, but there is something that resonates differently here for me. I'll have to figure out what and write in more detail as to why.

Modular Robotics (Bioloid)

A couple of years ago I dropped big bucks on a Bioloid robotic set.  My son has since lost interest in robotics (but I will try to ignite it again in a couple of weeks at RobotFest).  I lost interest in the set due to its cumbersome programming interface and (to me) flaky CM-5 processor brick.

This morning I was talking about robots with a co-worker who has done quite a bit himself in the past. I was curious to see if Bioloids were still being sold and... ooh, there are tech manuals now on the smart servos!  Protocol documentation too!  

I smell a CFT project. In particular, I should be able to pair a Bioloid sensor with an MSP430 or AVR (the CM-5 uses an AVR) and do interesting things.  Maybe I could do this with a few servos too.

Imagine: A Bioloid / Roomba (Create)  hybrid... oooh, think of the potential!

/todd

Modular HW

A new idea: Throw a bunch of MSP430F2012s at a problem.  I did this recently. Rather than deal with a bigger MCU to handle multiple sensors (which increases software complexity), I have been pairing individual MSP430s with sensors to make them "super sensors".

This allows me to "perfect" a sensor node, define a common I/O facility (bit banged 2400 baud) and then hook them to a single "controller" MSP430 (maybe a fatter chip).  An example super sensor would be a motion detector consisting of a F2012 and an accelerometer. All of the algorithmic work of determining true "motion" (vs tilt or vibration) would be handled by the dedicated F2012.  

More thoughts on this later...

Back to softer thoughts...

I'm pretty burnt out. So, instead of hacking in my home lab, this past weekend I perused books. I grabbed some (mostly) math and programming books off of the shelf. It was both a reminder of some of the things I miss since I started doing exclusively embedded work and some of the things I don't miss.

What I don't miss is the plethora of general purpose programming languages that vie for my attention. What I do miss is the ability to express math concepts (especially geometry) in a high level manner. My lack of education in domain specific languages (specifically: math) is at fault here.

I think that my "general purpose" language exploration days are truly over. For general purpose programming I don't see what going beyond C and awk (or Tcl) gives me. Domain specific languages (DSLs) are interesting. For example, I use Dot (via Graphviz) for producing directed graphs all of the time. I use Scratch to work out simple animation/graphics oriented ideas (but, curse you Scratch: no parametization or recursion yet!) and I use it to teach kids how to program.

Right now, my son is interested in going beyond Scratch, so we may start playing with GameMaker (a commercial game building tool). That sounds like a DSL to me.

I've also been toying with doing a DSL in awk that will render graphic primitives (to some screen viewer/plotter via pipes) so I can work through Turtle Geometry without having to find/re-learn some Logo variant.

For work I am using awk to do some quick power consumption calculations. Excel is what we normally use, but I'd like to see the math all in one view (not by clicking on cells).

I am considering doing a short DSL in awk to coordinate between Dot/Graphviz state machines and actual code. I'd like to keep the Dot state machine up to date as the code evolves.

For now, I am exploring these softer thoughts...