Software Design

CYBER-Alaska Software Design

Dr. Lawlor’s basic vision (subject to improvement!) is to build a single generic microcontroller software platform, and do almost all the interesting programmability up on the PC side.  The basic parts would be:

  1. A broad set of sensors & actuators.  Sensor data arrives via digital input or A/D pin.  Actuators are all driven by digital outputs or PWM pins.
  2. A single pluggable microcontroller, with a single generic set of firmware.   Firmata is an example of generic firmware, already loaded on Arudino Uno boards, supporting MIDI, I2C, etc.  Firmware language: C.  Latency sensitive calculations (e.g., encoder counting) might need to run here to get decent performance.
  3. A single generic PC-side “robot server“, which exposes the microcontroller’s functionality to the network via HTTP.  Server language: C++, possibly with some OpenGL for graphical output, and OpenCL for high performance.  Computationally heavy simulations (like fluid dynamics) might need to run here to get decent performance.  You could even start students out with a simulated robot server, with none of the above hardware.
  4. A web browser user interface, running either on the onboard PC or across the net.  All student-programmable high-level control software runs here, in clean easy JavaScript (see below).  There’s a browser plugin to read joystick data in JavaScript.
  5. A logging and data analysis component.  It’d be nice to be Google Data Protocol compliant: basically we do data logging by sending JSON HTTP off to a backend somewhere.

Unresolved questions:

  • Where does “lesson plan specific” software go?  I’d lean toward putting it into the robot server’s config files.
  • With this many stages, failure at some level is inevitable–we need good error reporting, so the web browser shows “lost connection to robot server” or “Arduino not found” instead of locking up, or blazing along with bogus data.

Programming Model

Imagine NetRun, only with the user writing robot control loop code. Basically, the browser is executing the following:

repeat forever {
  try {
    read sensors from robot (HTTP GET recv)
    RUN user's control code
    write actuators to robot (HTTP GET send)
  }
  catch(exception) {report failure;}
};

“user’s control code” comes from a live textarea.  Sensors are all shown with a pretty GUI (dropdowns, etc).  Commanded actuator states are all shown in the GUI as well.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>