For comparison, an Amazon EC2 “High-CPU Medium” (c1.medium) instance type prices out at $759/year running 24/7 (as a 3-year Reserved Instance running a Linux image). That’s a dual-core system, where each virtual core is equivalent to a 2.5GHz Xeon processor. Building your own equivalent will run at least 120W, implying $154/year in energy costs alone. If you build that server for $1500 and expense it over three years, the energy cost will increase your total bill by 31%. Throw in a $200 cooling unit expensed over the same three years, and your internal server will cost you $500+$154+$66=$720/year. That’s enough to make a cloud server seem downright reasonably priced.

• Prototype #4: Quad-Pulley Elevator (axled)
  

A fundamental shift in design vis-à-vis prototypes 1-3, lift #4 raises a rectangular platform via four corner pulleys.

Lift #4: Quad Pulley Elevator

Design: 1/2″ steel pipe structure. Flanges bolted to pulleys for pipe framework attachment. To minimize drive complexity, a single 12V/2000lb winch ($50, Chicago Electric model 92860) draws all four pulleys simultaneously via a pair of axles. Several additional pulleys redirect cable forces appropriately.

Analysis: Surprisingly unstable. Even after the addition of a cinder block to weight down the platform, still prone to inconsistent lift rates at the four corners and consequential tilting.

• Prototype #5: Quad-Pulley Elevator (unaxled)
  

Similar in nature to prototype 4, but without axles.

Lift #5: Axleless Quad Pulley Elevator

Design: 1/2″ steel pipe. To avoid jamming at the winch spool, only a single cable actually meets the winch. The three additional cables are attached to the primary drive cable at various positions along its length. Same drive winch (model 92860).

Analysis: Removing the axles reduces undesirable pulley tension, but reduces the framework stability. Joints tend to rotate unexpectedly.

• Prototype #6: Dual Pipe-Joint Fulcrums
  

A reimagining of prototype 3, where the pulleys are replaced with untightened steel pipe joints.

Lift #6: Pipe-Joint Fulcrums

Design: Again, 1/2″ steel pipe. To avoid jamming at the winch spool, only a single cable actually meets the winch. The three additional drive cables are attached to the primary drive cable at various positions along its length. Same 92860 drive winch. (Design is implemented twice in above image, hence the dual winches.)

Analysis: The best of the first six lifts. Disadvantages, however, include a large sweep-through space that must be kept clear of other objects and jamming due to uneven tightening of threaded joints. The latter flaw could perhaps be alleviated with improved lubrication.

Automated vertical transportation. Vertical travel: 100 to 200cm. Load: 4 to 30kg.

Some objects must remain at a constant orientation and cannot endure significant acceleration or jerk.  For instance, unenclosed liquids and most LCD displays cannot withstand impacts and must be oriented within a few degrees of vertical at all times.

SPOILER: Of 8 prototypes, the first 7 failed in practical applications.

• Prototype #1: Electric scissor jacks

Torqued scissor jack assembly

12VDC/6A/2000lb jack ($50, Central Hydraulics #95851). Cigar lighter power input to a handheld control box. Worm drive motor powered by a relay H-bridge, where relay control inputs pass through a user-operated momentary pushbutton AND a pair of microswitch sensors that are depressed at the extremes of the lift travel (to protect against stalling and hyperextension). Could drive motor directly with ESC, or splice into relay control box to take advantage of existing circuitry. Approximately 9″ useful lifting range per jack , as lifting power is reduced at height extremes. Can stack to increase range.

Design: 1/2″ steel pipe structure. 3/16″ aluminum plate bored with drill press to adapt pipe flanges to 8-32 bolts through top and bottom ends of scissor jacks, such that jacks can be screwed onto pipe.

Analysis: Unacceptably flimsy. As pictured (above), a few pounds of horizontal torque bends the jack itself. [The jacks themselves are bending, not the pipe.] Automotive jacks are apparently designed to handle large vertical loads but no horizontal forces.

• Prototype #2: Drawer sliders + winch
  

Drawer slider-based lift

Sometimes called “linear tracks” in CNC applications. $10 per 28″ pair (eBay), 200lb horizontal weight limit. Not designed to support significant torque about the track’s linear axis. Lift power must be provided externally.

Design: 1/2″ steel pipe joints. Flanges mounted directly to drawer sliders. Winch motor pulls steel cable around pulley to pull slider assembly upward straight along its travel axis.

Analysis: Smooth motion, but too fragile. When assembling and adjusting, impossible to avoid rotary torques that snap the tracks (spraying ball bearings everywhere).

• Prototype #3: Dual offset fulcrums (quad pulley) + winch
  

Two circles of common radius, where the centers are separated by distance x, linked (at a common phase offset) by a bar of the same length x. The bar must necessarily remain at the same orientation as the angle between the centers of the two circles as it travels about them. [This technique probably has a name, which I do not know.] To clarify, several angles are pictured (below).

Quad pulley lift

Design: 3″ garage pulleys (300lb max load) as fulcrums. 1/2″ and 3/4″ steel pipe flanges mounted to the pulleys to produce a freely rotating pipe junction. Four such junctions (4 pulleys, 8 flanges) to complete the system, where short lengths of pipe provide the separation distance x between the circle centers and rotating lever ends.

Analysis: Robust at certain angles, but extremely loose at others. Looseness in pulleys (due to manufacturing imprecision) leads to an angular error in the traveling bar’s orientation that varies as the inverse of sin(2y) where y is the angle from horizontal.

Peripheral Driver (v02) - CAD/raw/populated

First release of PCB design: Peripheral Driver. 2 layers, 1.3x2in (33x50mm). ATmega328 (or similar) microcontroller logic at up to 20MHz clock. Eagle design files and BOM available via GitHub repository: PCB-PeripheralDriver.

Each of the 22 three-pin peripheral headers provides low-voltage power, a unique microcontroller signal pin, and a common ground. Intended to manage peripherals with high current requirements and/or noisy electrical feedback: servos, relays, high-lumen lighting, active sensors, etc. Peripherals are expected to supply their own power amplifiers with high-impedance inputs [drawing 5 to 10mW max from the signal pin].

Separate inputs for logic power (Vcc) and power supplied to outputs (Vdd). [Ground must be common.]  Optional onboard Vcc regulation and low-pass filtering [in the half millifarad range].  Vcc may be reduced below 5V (i.e. to accommodate 3.3V supplies and peripherals), if the clock rate is reduced as well.

A standardized pinout and pair of mounting holes along the top of the board provide power and UART comms to independent daughterboards, such as the PeriphDB-DiffUART differential UART comms board. The RST pin is included for Arduino bootloader support.

Improvements in v02:

• Widen driver power (Vdd/Gnd) tracks to 20mil.
• Replace screw terminal power inputs with SIP header.
• Allow separate inputs for motor power (Vdd) and regulator power (VccReg). V01 allowed for separate Vcc and Vdd inputs, but the Vcc regulator, if installed, could only source from Vdd.
• Add dedicated BEC input port, where signal pin is left floating (but Vdd/Gnd are connected).
• Decrease overall footprint.

Dual PCD8544

C++ driver for the Philips PCD8544 LCD controller, based on Fandi Gunawan’s C driver.  Ported to C++ for object-orientation and template support.  Supports multiple LCD controllers with separate DC/CE/RST pins, screen caches, etc.  Other enhancements include support for any resolution (not just 84 x 48) and templated pin and SPI bus access for easy porting to new architectures.  Code is GPL’d in the GitHub repository Philips_PCD8544_driver.

The MDFly model MD8448B boards pictured here provide a backlit breakout of a Nokia 3310-style 84×48 monochrome LCD, requiring only a 3.3VDC power source.

The driver package includes two MapOS servers:

• StringServer: Upon receiving a packet, clears the screen and writes the text contents the packet. Especially useful as a line-based console output.
• CommandServer: A general control server which takes an opcode command (e.g. write bitmap) and arguments (e.g. offset and bitmap content).  Can clear the screen, set contrast, write a monochrome bitmap image at a desired offset, etc.

These two servers are implemented in a MapOS kernel released at GitHub’s Philips_PCD8544_Server.  This implementation executes on an ATmega328P 20MHz core (pictured at right).  The LCD driver and servers instantiate from template classes, utilizing the AVR_Object library’s OutputPin classes, and sacrifice several kB of (otherwise unused) Flash space in exchange for faster processing. Memory footprint: 16.5kB Flash, 91B Eeprom.

Below, an example bash script to control this server. $sendPack should contain the path to the sendPacket utility (compiled in MapOS/arch/linux/utilities/sendPacket), whereas $uartDev points to the /dev/ttyUSBx device feeding the ATmega UART-RX. This script will clear the screen, set the contrast, and draw two horizontal lines in the upper left corner.

# Set device address: 4-20.
echo "0 2 1 iu 1 iu 1 iu 1 iu 3 iu 4 iu 20 iu 255 e" | $sendPack > $uartDev
# Bind LCD-1 Command server to port 8-24.
echo "0 2 1 iu 1 iu 5 iu 0 iu 3 iu 8 iu 24 iu 255 e" | $sendPack > $uartDev
# LCD-1: Set contrast to 64. (Opcode 3, argument 64.)
echo "0 8 24 iu 3 iu 64 e" | $sendPack > $uartDev
# LCD-1: Clear screen. (Opcode 0.)
echo "0 8 24 iu 0 e" | $sendPack > $uartDev
# LCD-1: Write bitmap. (Opcode 1.)
# Second byte is data offset, in bytes, which corresponds to a horizontal pixel offset.
# The following bytes define the on/off status of pixels in a vertical stripe.
echo -e "0 8 24 iu 1 sr -\x00\x0F\x0F\x0F\x0F\x0F\x0F\x0F\x0F- e" | $sendPack > $uartDev
echo -e "0 8 24 iu 1 sr -\x08\x0F\x0F\x0F\x0F\x0F\x0F\x0F\x0F- e" | $sendPack > $uartDev
echo -e "0 8 24 iu 1 sr -\x10\xF0\xF0\xF0\xF0\xF0\xF0\xF0\xF0- e" | $sendPack > $uartDev
echo -e "0 8 24 iu 1 sr -\x18\xF0\xF0\xF0\xF0\xF0\xF0\xF0\xF0- e" | $sendPack > $uartDev

* DorkbotPDX (any size): $0.26/cm², no min area, but must order 3 boards.
* BatchPCB (1in²): $2.7/cm², 6.5cm² min
* BatchPCB (3in²): $1.15/cm²
* Seeed Studio (5cm side): $0.12/cm², 250cm² min
* Seeed Studio (10cm side): $0.10/cm², 500cm² min
* OurPCB (20in²): $0.023/cm² (plus shipping), 12900cm² min

DorkbotPDX and BatchPCB win the small-volume contest up to about $30 (115cm² from DorkbotPDX or 39cm² from BatchPCB).  DorkboxPDX is certainly the cheapest, especially for tiny boards, but they are brand new (and not yet commercially viable) whereas BatchPCB has a rich history as the de facto beginner’s choice.  Seeed then kicks in and gives you 250cm² for that same $30 on up to 500cm² at $50. Anything more than 500cm² is probably a production run, and you’re going to be jumping to the 1.3 square dekameter OurPCB order or going with one of the other big guys (e.g. MakePCB).

Note that BatchPCB and Seeed will both resell your boards for you.

[UPDATE: DorkboxPDX pricing corrected.]

Motor_Controller_Server - MAPPacketSink

An integrated Motor Controller Server (MCS), running under MapOS.  In addition to the standard MapOS dynamic routing capabilities, the AVR version of the MCS sports a continuous oscilloscope output [ADCServer from the ATcommon library], analog encoder sensor monitoring [with fixed-point position output], a PID engine with realtime coefficient configuration, and an ESC control server [PWM output].

An earlier version of this server was fielded in ATR5-b1.  (The fires were not the server’s fault.)

Code available via Github, repository Motor_Controller_Server.

MapOS - Motor_Controller_Server - MAPPacketSink

The MAP Operating System (MapOS) implements the Upacket project as a network-centric kernel. Tuned for microcontroller deployment,  including a minimal scheduler and supporting architecture-specific features [timers, ADC, PWM, etc], MapOS’s features include:

• Dynamic packet routing graph, which can be modified in realtime and (optionally) saved to nonvolatile state.
• Dynamic memory pools, in order to to reserve malloc()’d resources for specific purposes.
• A cooperative multitasking scheduler: essentially a list of methods that are called at defined frequencies.  Tasks are required to perform their own context switches.
• Easy extensibility.  New server processes can be implemented by extending the SimpleServer class with a single method – process() – which is called at a defined frequency by the scheduler.

Initial architecture ports include the Atmel AVR ATmegax8 series [especially ATmega328] and GNU Linux x86. An ARM Cortex M3 port is in place, but has not seen significant field testing.  Code [C++] is available via the MapOS GitHub repository.

Common servers:

• Dynamic router: Accepts command packets to add and remove packet routing graph edges, then routes packets as configured.
• Ping/echo server: Responds to incoming packets with their own payloads.
• Clock server: Sends out clock updates at a precisely defined frequency. Used for device synchronization.
• MAP/MEP servers: A pair of servers that encode and decode MAP packets into serialized MEP form, respectively. Includes checksum generation and verification.

Some architecture-specific servers:

• AVR: RPC server. Front-ends for basic AVR pin functionality, including PWM output and digital I/O. This server is sufficient to perform many common tasks, e.g. relay control, LED light modulation, push-button monitoring.
• AVR: ADC server. Takes analog readings, which are scaled as desired and transmitted in packets.
• AVR: MAP/MEP UART server. Buffers and encodes/decodes MAP packets for transmission to/from a UART bus.
• Linux: Command-line MAP packet generation tool [sendpacket] with MEP-encoded output.

MapOS is particularly adroit as a front-end for other devices. Established servers:

• ESC motor control server set, including position sensor monitoring and PID engine.
• Philips PCD8544 graphic LCD serving both text and full-screen bitmaps.
• Nordic nRF24L01P packet transceiver operating in ad hoc and infrastructure modes.

Servers in development:

• Composite/VGA video output via Parallax Propeller GPU.
• SD card read/write [raw and FAT32].
• Motorola Oncore VP DGPS position, pseudorange, and pseudorange correction I/O.

• MEP encoder and decoder implementations, to facilitate packet transmission over serial lines.
• MAP packet management utilities, including checksum generation/verification. MAP packet headers replace MAC, IP, and port (UDP) addressing layers and supporting unlimited nesting (i.e. for DSR).
• Posix 32-bit CRC checksum calculation/verification engine, providing the reliability mechanism for the MAP packet structure.
• Packet routers, including realtime graph edge addition/removal.
• Basic server templates from which new processes can inherit common functionality, such as reply-packet preparation.

Available via the Upacket GitHub repository, this C++ code library is an alpha release (in rapid development).

• FixedPoint: A cheap fixed point fractional arithmetic implementation. Does not allow overflow; clamps to extremes instead.
• StateMachine: Borrowing from existing work, implements low-cost parallel (thread) states in a non-threaded environment.
• MemoryPool: Tracks and implements memory allocation limits. Can be nested.
• DataStore: Static and dynamic array-based buffers and ringbuffers.
• DataTransfer: Data stream interfaces to support generic graphs.
• Status: A tiny library to support common enumerated return statuses.