The Office Chairiot Mk II SmartChassis

Let's start with the chassis: The base of the Office Chairiot Mk II is actually more akin to a battle robot for a couple of reasons: It's got a heavy-duty wooden frame (soon to be replaced by an all aluminum frame) (stayed tuned to this website for updates) and a swanky aluminum body. It wheels around on pneumatic scooter tires for a smooth ride, even in parking lots and loose gravel. It has very few moving parts because of the differential steering. Motors, chains, sprockets, casters and wheels make it go.

The Chassis Outside

As mentioned above, the core of the Office Chairiot Mk II's chassis is made of two pieces of 3/4" plywood and a few pieces of 2x4 pine. It was a valid choice for a maker who couldn't weld. There's plenty of wood in there to keep it sturdy.

The body is made of sheet aluminum. The pieces were cut on a waterjet at the Local Motors Labs in Chandler, AZ. CAD for the pieces was done in Solid Edge on the workstations at Local Motors and in ViaCAD 9 Pro on the Mac Pro.

The IKEA chair and other accessories are connected to the chassis using four incredibly strong fence latches which make switching accessories very fast and easy. This simple system is called, "QuickLatch." A video of the system in action is coming shortly.

Every tire on the chassis is a pneumatic scooter tire to help smooth out the ride over rougher terrain. The front wheels on the chassis are simple, but heavy-duty casters holding air-filled tires. The rear wheels are actual rear wheels for motorized scooters with freewheeling sprockets that have been welded into place to prevent freewheeling.


The chassis is loaded with LED lighting features, including headlights, turn signals, a brake light and fully-programmable RGB LED lighting under the chassis and behind the logos cut into the body side panels. Each light is individually controllable by the chassis microcontroller via a relay board. The current draw can be quite impressive, considering there are 72 RGB LEDs underneath, another 16 behind the logos, two very bright headlights and 5 smaller indicator lights.

The Chassis Inside

Remember that bit about the battlebots above? In fact, this chassis uses a motor controller used in beefier battlebots: The Dimension Engineering Sabertooth 2x60 motor controller. It's capable of carrying 1,000 lbs. of cargo and can feed the drive system up to 60 amps per motor channel (and even short bursts of over 100 amps). It has many command modes, but in our case, it's being used in simple serial mode.


The main brain on the chassis is an Arduino Mega 2560, an 8-bit, 16 MHz (1 MIPS) prototyping board based on the AtmelĀ® ATmega 2560 microcontroller. The Arduino takes commands from any number of different kinds of remote controls over its UART (serial port) and translates a simple protocol of characters and bytes into motor commands, RGB LED and relay control.

The Arduino can also report on a number of on-board sensors, giving the remote control access to helpful data points on such things as motor temperature, power wire temperature, ambient air temperature, wheel RPMs, accelerometers, seat occupancy and GPS data.

The Chassis Firmware


The firmware is written in C++ in Apple's Xcode IDE which is made to play nicely with Arduinos and other embedded boards by a killer utility called, "embedXcode" from Rei Vilo Hobbies. embedXcode reconfigures Xcode to make Arduino development (among other embedded environments) super easy to do in Xcode. If you've never seen Xcode and you're on a Mac, once you see it, you'll never go back to the Arduino/Wiring IDE. Xcode is a FREE, high-end integrated development environment normally for writing Mac OS X and iOS applications. It's loaded with incredible and, by today's professional software development standards, expected features and functionality. The code indexing and code completion along are worth getting that set up. Syntax coloring, line numbers, error highlighting, etc. are all available to you in this environment. WAY better than the Arduino/Wiring IDE.

Handshakes & Heartbeats

The chassis firmware is meant to be simple. It's also meant to be safe. The chassis expects a connected remote controlling device to follow a simple character and byte protocol over a serial connection. It also expects to hear from the controlling device twice every second, otherwise it will shut down the motors (for safety) and lights (to save battery power).

The protocol for communicating with the chassis is very simple and it's even possible (by design) to command the chassis from a terminal application on a desktop computer. Each command is terminated with a newline ('\n') character making it very easy to distinguish between commands as they come in. Every command starts with a command character, such as "M" for motor or "L" for light. What follows that character is dependent upon the context of the first character. Usually, the 2nd character is a more specific target. For example, the "L" command is followed by which particular light you wish to control, such as "L" for the two left turn signals or "H" for the headlights. In the case of the "L" command, the third character is usually either a "1" for "On" or a "0" (zero) for "Off." Some commands take longer numbers, like in the case of RGB LEDs, where a command might look like "LW29485" which means set the "Wunderglow" (under-carriage) RGB LEDs to color 29485 (a 24-bit value representing the red, green and blue values for the pixels).

Here are some examples of commands that can be sent to the SmartChassis Controller:

ML511 = Left motor to idle
MR0 = Right motor to full reverse
MR1023 = Right motor full forward
0 = Both motors full-stop
LH1 = Turn on BOTH headlights
LA1 = Turn on LEFT headlight
LB0 = Turn OFF RIGHT headlight
LL1 = Turn on both LEFT turn signals (front and rear)
LLB = Blink left turn signal
LRB3 = Blink right turn signal 3 times
LC0 = Turn on both headlights
H = Heartbeat (keep-alive character)
SRL = Read left wheel RPMs
STA = Read ambient air temperature
STB = Read left motor temperature
SA = Read accelerometer data (fields returned together)
SG = Read GPS data (fields returned together)
X = Disconnect/exit (shuts down motors and lights)

This protocol will be replaced shortly with a more compact version where targets for actions and whether the action is read or write will be stuffed into bits and the commands will be just a few bytes. This will make the eventual transition to CAN-bus much simpler, as CAN messages usually contain only a handful of bytes. As a side effect, it will make commanding the chassis from a terminal a little more difficult for a human, since we don't tend to pack bits together very well without the help of software or calculators. But, to alleviate that problem, there will be a desktop app for commanding the chassis, as well as an iOS and possibly an Android app (ahead of being able to control the chassis from a mobile device, of course).

An important feature of this system is the safety cut-off for loss of communications with a remote device. As mentioned above, the remote device must stay in contact with the SmartChassis Controller or the controller will shut down the motors and lights. The chassis expects some kind of command, even if it is just an "H" (Heartbeat) command at least every 500 milliseconds. But, before that, a conversation must be started between the two devices. This is accomplished with a simple handshake. Let's walk through the startup sequence:

  1. Chassis 24-volt systems are powered up by connecting the "Master" wire to ground. This energizes the coil in the heavy-duty contactor (big honking relay) and connects power to the motor controller.

  2. The motor controller provides 5 volts for the on-board Arduino, turning it on.

  3. The chassis Arduino opens up its command UART (serial port) and starts sending the string, "Ping!" every second. This is a marker that a potential remote device can look for to make sure the chassis is fully awake and ready to talk.

  4. The control panel (or any remote device) finds the "Ping!" string and now knows that the chassis is waiting for a remote to talk to.

  5. The panel then sends, "Hello!" to the chassis and waits for, "OK" to come back.

  6. If the chassis receives the "Hello!" string intact, it will acknowledge the start of the conversation with, "OK" and comms is now established.

  7. From now until communications is stopped (purposefully or accidentally) the remote must say something to the chassis every 500 ms.

  8. If 500 ms goes by without a word from the remote device, the chassis shuts down the motors and lights and goes back into the waiting mode, sending, "Ping!" over and over again.

  9. If the remote device sends a command other than the handshake while the chassis is in waiting mode, the chassis will send, "NC" (not connected) and go back waiting.

This simple and effective protocol makes accidental disconnects between the chassis and remote devices an "auto-shutdown" kinda situation. This is particularly useful if you're walking alongside the chassis while it's carrying something and you yank the remote cable out of the Remote Port on the chassis. The chassis will stop moving in half a second. This also holds true of wireless connections. If a wireless remote goes out of range or just stops transmitting due to interference or power loss, the chassis stops in its tracks. Conversely, if you simply jack the cable back into the port, the two devices will automatically start talking again, once the remote sees the, "NC" string on its next command attempt. It's a total win-win situation! All the synergies!

The Crazy Control Panel

It is indeed a crazy control panel! Why? Because Andy's wife would prefer he doesn't buy a commercial aircraft or a 60's era space capsule. To satiate his need to push buttons, flip switches and monitor blah-blah-blah levels, he designed and built a control panel any NASA pilot would be right at home in front of.

The Panel Outside

The panel has over 30 switches and buttons. There's a "Master" keyswitch, a LCD for status output and configuration changes, two battery voltage meters and, of course, the "Thrust Control" joystick. Sprinkled around the panel are a handful of LEDs of varying colors, as well.

The enclosure itself (or the body of the panel) is powder-coated aluminum. It was designed around the face of the panel which was initially designed in Adobe Illustrator. The Illustrator file was converted to DXF and sent to the fabricator, Liquid Metal Concepts in Phoenix, AZ, where they extruded it in SolidWorks and had the aluminum cut on a waterjet at Southwest Waterjet and Laser, also in Phoenix. They then bent and welded the enclosure together, added some threaded holes and made a backplate with posts and matching mounts to mount it on the chair.

The face of the panel is actually a separate piece of black plastic cut on a laser with the exact same DXF file. The graphics on the face of the panel are vinyl decals made from the exact same process as automotive graphics wraps. I had those made at Sign-A-Rama in Tempe, AZ. Basically, the labels on the face of the panel are peel-n-stick vinyl custom-printed decals. That vinyl doesn't stick well to matte-finish powder-coated surfaces, as it turns out. This is why they're stuck to that piece of plastic. The plastic face is being held onto the aluminum enclosure by all of the switches and buttons. It actually turned out to be a nice fit-n-finish.

The Panel Inside

The panel, like the chassis, is controlled by an Arduino Mega 2560. It was chosen for the amount of program memory it has, 256K, and the number of available I/O pins. The panel has a lot of accessories that require I/O pins and that, in turn, means the firmware to manage all of those accessories requires more memory.

To lower the number of pins required by simpler things, like all those switches and buttons, a custom-built printed circuit board was built. It contains shift registers that allow the Arduino to gather the states of all of the buttons and switches in one fell swoop using only a couple of pins.

The USB port for the Arduino is brought out to the back of the panel with a cool little panel-mount port for convenience of reprogramming it and to communicate with it (monitor debugging info and stats). Makes the control panel look like a real USB device, too. Funny.

The various LEDs on the panel are controlled the same way as the buttons and switches. They are all connected to an LED controller similar to a shift register. It allows the Arduino to turn LEDs on and off by shifting bits out to the little controller board.

The LCD is connected with an 8-bit parallel interface for faster output. There is another custom-built daughter board on the back of the LCD that handles power, brightness and contrast. There is a digital potentiometer on the board for controlling the the contrast of the LCD. The backlight brightness is managed through PWM via a MOSFET on the board.

The Panel Firmware


In a little while, all of the source code for the Office Chairiot Mk II, both the SmartChassis and the control panel, will be available on or GitHub. It's been written to be easy to follow and understand. There is a lot of C++ class work in there and input from other developers is always welcome.