From Noisebridge
Revision as of 23:53, 20 April 2011 by Jared (Talk | contribs)

Jump to: navigation, search

Hereby known as "MC Hawking - The Wheelchair Robot"

Here's the beast:

Videos: rachel driving rachel attacks a wheelchair driving around noisebridge



Improperly used, the robot can destroy itself, its suroundings, and run you over. Please know what you are doing and don't be afraid to ask questions.

  • RTFI! Know how to engage / disengage wheel clutches, and where the power switch is incase it goes crazy.
  • Always warn humans nearby that the robot could lose control and run them over.
  • DO NOT "UPGRADE" UBUNTU OR THE KERNEL ON THE HOST MACHINE! (unless you are going to stick around and make everything work with it...)
  • if someone is sitting in the chair when it is on, warn them that the robot could go crazy and kill them, it has almost happened.
  • always make sure it's plugged into the battery charger, and that the charger is plugged in and powered on. The batteries are throwaways and barely hold a charge as is, so we need to keep it on the charger.
  • We have not implemented even basic safety shutoffs, so you should be watching it all the time. It will very happily drive through its operator and the wall without stopping.
  • If it appears to be getting out of hand, the power switch is just behind the joystick, where you turned it on. This will power down the motors and stop it where it is immediately, with the brakes on. At this point you can disconnect the parallel-port interface and drive it home with the joystick, or disengage the wheel clutches and push it home manually.
  • If it REALLY IS getting out of hand, use furniture to try to stop its movement so you can get at the power switch. DO NOT try to use your body to stop it, it's heavier and stronger than you are and it doesn't feel pain.


M.C. Hawking the Wheelchair Robot, AKA Noise-Bot, uses an electric wheelchair (Action Arrow Storm Series). This is a mid-sized electric wheelchair which can be dis-assembled without tools and transported in a car, which is how it got to noisebridge. It uses two 12-volt lead-acid batteries such as car batteries. The batteries are wired in series for 24 volts, and it is necessary that they are matched so that one doesn't wear-out the other during use and charging.

At this time (nov 2010) the batteries are throwaways which have just enough capacity to play around with the thing for a couple of hours before having to go back on the charger.

The battery charger plugs into the wheelchair on the joystick side, just in front of the wheel. The wheelchair is electronically immobilized by the third terminal of the chargers' plug, which is connected to ground. In the future, the robot will be able to plug into electricity by driving into its parking spot, so that the onboard computer does not have to be shut down or manually plugged into mains AC to avoid draining the batteries. At that point the computer will gain the ability to power-up the wheelchair electronics, so that the robot can be summoned from afar at anytime, without a human present to unplug the charger, turn on the switch, and do the reverse when the remote user is finished.

There is a computer (separate from the wheelchair controller which technically has a computer in it) which is in an extruded aluminum case like a car-audio amplifier. It uses a PCI7E mini-motherboard and a Mini-Box M3-ATX power supply

The box is currently powered by a custom voltage regulator made by jake. It accepts up to 40 or so volts, but will never deliver more than 23 to the M3-ATX which is hard-limited to 25 volts. If the voltage is at or below 23 volts, its FETs are in full conduction and there is zero dropout. Once on, the M3-ATX will keep the computer running unless voltage goes below 7 volts, at which point the 24-volt battery array of the wheelchair is being seriously damaged.

The voltage regulator's input plugs into the wheelchair's charger port, on the joystick side, just in front of the wheel. The voltage regulator's output cable is soldered directly to the laptop's mainboard.

The voltage regulator's input plugs into a connector coming from the wheelchair controller's blue power connector, which is connected directly to the batteries. This is where the voltage regulator gets disconnected when the robot is not being charged regularly, so that the regulator does not drain and destroy the batteries. The output of the voltage regulator goes to two tab terminals and an on/off switch, to provide the computer's power supply with constant voltage, ground, and a switched-version of constant voltage. Read up on the M3-ATX linked above.

A circuitboard zip-tied to the arm-rest interfaces the parallel port of the computer to the joystick. This circuit uses transistors to trick the wheelchair controlbox into thinking that the joystick is somewhere other than at-rest in the center. Of the eight bits of the parallel port, two make the chair go forward, two to the right, two to the left, and two backwards. For each direction, there is one bit causing low speed and another causing medium speed. Both bits cause high speed. As of 11/15/2010 a steady-state on the parallel port is not ignored by the circuit, so a computer crash will cause the chair to go out of control. In the future, the circuit will ignore non-changing status bits, but the software has to be changed first.

At this time Jake is preparing to install sensors on the motor which will allow the computer to track movement and speed. An old ball-mouse has been disassembled and its sensors mounted on wires, and these sensors will be placed at the open end of the drive motors. An optical interruptor will be attached to the end of the motors' driveshafts, so the computer will experience movement on the x and y axes of the mouse when the left and right wheelmotors turn. Since the mouse is/was DB9 serial, it will be possible for the computer to treat it as a serial accessory rather than interpreting it as an actual Human Interface Device to move a mouse cursor. The next step will be a daemon to listen for serial data and to make available speed and movement data to applications such as the telepresence driving program ( to improve control of locomotion over a lagged internet connection.

An LCD monitor is being prepared to be mounted permanently as the seatback.

A robot arm made of mostly aluminum and animated by air-cylinders is fitted to the robot, but few electronic valves and no air compressor or tank have been acquired. Someone will have to invest time and energy to get the arm to do more than make the thing look more menacing. As of 11/15/2010 the arm was removed to make the robot more wieldy/less unwieldy.


The PC is running a stock Ubuntu with PyParallel being used by the controller program to access the parallel port. All the software from the home directory as of 11/15/2010 is here:

The above software is present in the home directory of user tvbrain and mchawking. The difference is that if you log in as tvbrain you are a regular user, but mchawking logs in to an instance of python which is how the wheelchair's motor functions are accessed.


username: mchawking
password: emc
username: tvbrain
password: [redacted]

Network Connection

The embedded PC is using a Generic Realtek USB 802.11b interface, which is sub-excellent, but the WUSB600N by Cisco doesn't work properly under Ubuntu for some strange reason.

There's also a Cisco Aironet 1220B named wbr2 on the wheelchair, which associates to a matching Cisco 1220B named wbr1 at 2169 Mission. They use 802.11a to communicate on a dedicated channel. They use the default username and password for that platform. The embedded PC uses its ethernet port to talk to the Noisebridge network via a connection to wbr2's ethernet port.

The embedded PC is configured from /etc/networks/interfaces Also, Network-Manager which is the gui-compatible 21st century newschool network configuration system is been pushed to the side, possibly for good. The embedded PC is now configured to find the wireless network called noisebridge and take the internal IP below.

Noisebridge internal IP address

The robot's USB wireless interface has claimed an IP on the internal network of

Its ethernet port is using DHCP at the moment.

Static world IP address

For those not inside the noisebridge internal network, a static IP from has been assigned. The static IP is


Access from outside 2169 Mission

Configuration of the firewall is done (thanks Jof), so that connections to the machine can be initiated from the outside world. This is important if people are expected to log in and drive it around from Germany or Singapore.

DNS entry

In the future someone will assign that IP address a DNS entry like

Local Operation

The electric wheelchairs' controller brain will not allow movement unless the joystick is at rest for a second when power is switched on. If the computer has not initialized the parallel port to the "stop" bitpattern, and the switch is flipped on, the green LED will flash endlessly because it thinks you are leaning on the joystick and don't intend to do so.

The drive-wheels have clutches which can be disengaged from their motors (and brakes) by pressing a button and rotating a collar until it can be pulled outwards. When the clutches are disengaged, the robot can be pushed around like a shopping cart, and the motors can be activated without actually causing movement. Sometimes the robot must be pushed forward or backward in order to engage or disengage the wheel clutches, because they are like gears and only fit together in some positions.

Disengaging the clutches before testing movement software is highly recommended, as you will be able to see the motors trying to run you over without the robot being able to actually do it. This is like taking the laser off of Johnny Five before sending him to the lightning-prone recharging booth.

Personal tools