Bot Thoughts

Data Bus Baseboard on Tindie

2013-05-21T15:34:00.004-06:00

Data Bus mbed baseboards are now available on Tindie as a fundraiser!

I figured there may be a few others who want to experiment with their own algorithms on a powerful 96MHz ARM processor and want a head start on building their 2014 AVC ground vehicle entry.

Now you can build your own autonomous rover!

Features

Three UART ports, one 3.3V, two 5V, series resistor protection
Five I2C ports, all 3.3V
ESC and steering Servo connector
Dual wheel encoder port
Onboard 5V regulator powered by ESC 6V BEC powers 5V UARTs
Separate mbed supply rail to keep noise out of your GPS.
Filtering / bypass caps

Just get an mbed, load it up with my code ( and here), add an L3G4200D gyro, Venus or uBlox GPS, wheel encoders.

Data Bus source code repository
AVC2012 code on mbed.org

Noise and the 3DR uBlox LEA-6 GPS

2013-05-17T12:00:00.000-06:00

3DR uBlox LEA-6 GPS + secret sauce

I'm evaluating a 3DR uBlox LEA-6 GPS for use on Data Bus to either replace or supplement its current module, the Venus 638FLPX.

At first the GPS could not obtain a fix. Here's how I brought the GPS from no fix to a 10-satellite fix. From my basement!

Wayne H (2012 and 2013 AVC competitor) put together sample code and wrote an evaluation on his website. I ported his code from Arduino to mbed (http://mbed.org/users/shimniok/code/ublox_demo/)

The code works great, but I and immediately ran into problems with RF interference. The GPS could not get a fix.

Even taking it outside, it would lose fix going under a tree or in the garage. By contrast my Venus can get a 8-9 satellite lock in my basement with ease. Indoors, basements, garages, all a cakewalk for modern highly sensitive GPS receivers. Like the uBlox. So what gives?

Experimentation revealed that the GPS would work fine directly off an FTDI breakout board, and would also work fine when connected to my Arduino Pro. Anytime it was powered off Data Bus' mbed baseboard, no joy.

In fact, I could power it off the baseboard without the mbed plugged in and it would work. The mbed was the source of some type of interference.

I tried various combinations of...

RC-filtering the power supply on the baseboard and GPS end
Ferrite bead on both, then only one power line.
470uF bypass cap on the baseboard
power GPS off the second regulator supply line

Then I built a 5V linear regulator using one of my eeZee Power boards and a 5V NCP1117 chip I had laying around.

Purple eeZee Power board with 5V regulator

I discovered that the GPS would work with the mbed plugged in, provided the GPS TX/RX lines weren't connected to the mbed!

A trip to Radio Shack scored some RF snap choke cores (p/n 273-0069) around which I wrapped the GPS TX line several times. That did the trick.

Eight wraps around a choke for RX and TX

My old trick of using a square of metal as a ground plane also improved reception and at one point I was tracking 10 satellites. In the basement!

NAV-STATUS: gpsFix = 3, dgpsFix
NAV-POSLLH: lon = -104.9330273, lat = 39.5976185, vAcc = 2964 mm, hAcc = 2015 mm
NAV-SOL:    week = 1740, gpsFix = , pDOP = 1.6, pAcc = 359 cm, numSV = 10
NAV-SVINFO: channels = 16
id =   3 (30) ******
id =   4 ( 0)
id =   6 (23) ****
id =   7 (28) *****
id = 10 (17) ***
id = 13 (37) *******
id = 16 (25) *****
id = 20 (40) ********
id = 23 (40) ********
id = 27 ( 0)
id = 30 (20) ****
id = 31 (19) ***
id = 32 (31) ******
id = 133 (27) *****
id = 134 ( 0)
id = 138 (30) ******

Not that it's pulling in 10 sats all the time. It's getting 8 almost always, and once I was up to 11.

Clearly the chokes and dedicated linear power supply helped. I don't know why I didn't see these problems with the Venus board.

But if you're trying to get a 3DR uBlox (or really any GPS) working and noise is a factor, now you know what to do.

Ramp Jump Breaks Data Bus

2013-05-14T12:00:00.000-06:00

I built a ramp very similar to the one for the 2013 AVC so I could get a sense of how the robot will handle the jumps.

Unfortunately I stripped out one of the plastic idler gears doing a high speed jump. I've got a metal set on order to arrive Friday.

Can you see the stripped teeth on the small idler gear?

I was hoping to test my revised path following algorithm. That'll have to wait until I replace the gear set. More on the path following algorithm soon.

Just under four weeks left.

Reverse Engineering GM ECMs

2013-05-09T07:00:00.000-06:00

This is the tale of how I wrote a Perl disassembler for the Motorola 6801 CPU to learn how the fuel injection computer that I installed onto my Jeep works.

Almost 200 pages of source code and data create code to run late-80's GM fuel injected engines. DIYers retrieved machine code, disassembled it, and reverse engineered code and hundreds of parameters 15 years ago.

Complete ASDZ Source for 1227747 (pdf)

Inside a 1227747 GM ECM

Fuel injection computers interface with fuel pump relays, fuel injectors, ignition modules, coolant, throttle, oxygen, and pressure sensors. They employ complex algorithms to properly meter fuel under myriad engine and environmental conditions.

Only recently has my 1986 Jeep Grand Wagoneer benefited from this technology when I retrofit an 80's GM 1227747 ECM, throttle body, and all the fixin's. While I use nice GUI software to tune the parameters, I wanted to peer into the code that is executed on a 1MHz Motorola 6800-family CPUs with a paucity of memory.

On a whim I decided to write a disassembler in Perl with all the features that were lacking from other offerings. Plus, writing one is a great way to learn about a CPU.

Source code repository

CPUs in the 6800 family are simple. They have two accumulator registers (A, B) and one index register (X) as well as a stack pointer (SP), and program counter (PC). A status, or condition code register (CCR) stores the status results of computation: carry, zero, overflow, and so on. The MOS 6502 (Apple //e) and related MOS 6510 (Commodore 64) are even simpler, designed as a low cost alternative by some of the same engineers.

MC6800 Assembly

Here's some assembly language from the GM ECM.

LDX #$D4D9 ; O2 SENS VOLTAGE BIAS FOR COLD OP'S TBL
LDAA $00E3 ; START UP COOL
COMA
JSR $FB36 ; 2d LK UP, WITH UPPER LIMIT
STAA $0055 ; SAVE o2 SENSOR VOLTAGE BIAS RESULT

In the example above,

The mnemonic LDX loads the operand, the value 0xD4D9, indicated by the # prefix, into the index register X.
Then, mnemonic LDAA loads the A accumulator with a value stored in memory location 0x00E3.
COMA performs a binary complement on register A.
JSR jumps to subroutine at location 0xFB36 in memory. After it returns, the result returned in the A register is stored to memory location 0x0055.

Mnemonics

Assembly mnemonics represent simple instructions for the CPU to carry out. Operands like #$D4D9, $00E3, $FB36, and $0055 are addresses or values used by the instruction. They specify the addressing mode of the instruction.

Addressing Modes

The 6800 family instructions can have Immediate Mode (value) operands like #$D4D9, Direct Mode operands referring to the first 256 bytes in memory like $0055, Extended Mode operands that can reference any memory such as $FB36, and Index Mode operands which use the X register as a memory pointer, indicated by ",X" in assembly language. There's also relative addressing used for branch/jump operations. The operand specifies a relative address, positive or negative, to jump to. Inherent mode has no operand; the registers involved are implied, such as ABX, add B to X.

Writing a Disassembler

Assembling

When assembly language is assembled into machine code, the mnemonic and addressing mode determine the opcode to use. A given mnemonic has an associated opcode for each addressing mode. For example, ADDA is a mnemonic which can have immediate, direct, index, and extended addressing modes:

ADDA #$04 becomes opcode 8B, operand 04
ADDA $0004 becomes opcode 9B, operand 04
ADDA $04,X becomes opcode AB, operand 04
ADDA $4004 becomes opcode BB, operands 40 04

Disassembly

Disassembly is the process of converting machine code into assembly language. With the 6800 series, any given opcode may have up to 2 additional bytes for operands. A 6801/3 instruction set reference (pdf) provides information on how many bytes per opcode and what addressing mode is involved.

So when disassembling 8B 04, one translates 8B to mnemonic ADDA, then expects a single byte afterwards, which is formatted as #$nn in this case #$04. To simplify this process and keep the code simple, I use a hashtable generated from a configuration file that lists all the opcodes and their mnemonics, number of bytes, and addressing mode. Here's an excerpt:

###################################
# Accumulator and Memory operations
###################################
# Add to A
8B,2,adda,immed
9B,2,adda,direct
AB,2,adda,index
BB,3,adda,extend

Formatting operand output is based entirely on the number of bytes and the addressing mode. For example, 8-bit immediate mode format is #$NN and 16-bit is #$NNNN.

Relative Addressing

A little extra challenge is provided by the relative addressing mode used by jump/branch instructions. The operand is a signed 8-bit integer representing the number of addresses before or after the address of the operand. The variable $a1 is read in as a signed value, then the absolute address is calculated:

my $calcAddr = $addr + 2 + $a1;

Labels

I wanted to automatically generate labels, which are assembly langauge conveniences that identify addresses and can be used by jump and branch instructions making code much easier to read and maintain. Here's an example from rosettacode.org:

outeee   =   $e1d1      ROM: console putchar routine
        .or  $0f00
;-----------------------------------------------------;
main    ldx  #string    Point to the string
        bra  puts         and print it
outs    jsr  outeee     Emit a as ascii
        inx             Advance the string pointer
puts    ldaa ,x         Load a string character
        bne  outs       Print it if non-null
        bra  main       else restart
;=====================================================;
string  .as  "SPAM",#13,#10,#0
        .en

Without labels, bra puts would be replaced by a relative value. Same with bne outs and bra main. Likewise, jsr outeee would be replaced with jsr $e1d1 which is harder to understand.

To generate labels, I disassembled the code in two passes. The first pass identifies address references. The second pass converts opcodes and operands into assembly, while replacing raw address references ($e1d1) with labels (LE1D1), and prefixing referenced addresses with labels. Like this:

        bmi   _Ld62c
        ldab D05
        andb #$80
        aba
_Ld62c: ldab D10

As you probably noticed, I also converted direct mode references to labels of the form DNN.

Variables

The first several hundred bytes of GM ECM binary file is filled with parameters. Rather than using generic labels, my disassembler reads a list of addresses and label (variable) names. Here's an excerpt of the config file:

d290,TPS_FiltCoef1,FILT COEF TPS
d291,TPS_FiltCoef2,FILT COEF TPS
d292,DiffTPSforPE,DIFF TPS REQ FOR PWR ENRICH WHILE IN PE
d293,IAC_BPW,usec ADDED TO BPW WHILE IAC IS OPENING

So, for example, any reference to $0D293 is converted to IAC_BPW, the Idle Air Control Base Pulse Width. I did this for all the addresses referenced in the bin itself. It makes the code more readable.

        ldaa IAC_BPW ; ADDED TO BPW WHILE IAC IS OPENING
_Ld79f: adda D52     ; BPW,LSB
        bcs   _Ld7a7 ; BR IF NO OVERFLOW
        adda D53     ; BPW,MSB
        bcc   _Ld7a9 ; BR IF NO OVERFLOW

There are commented disassembly files out there. Adding those comments (as above) to my disassembly using descriptive variable names should reduce the time it takes me to understand the code.

2013 Sparkfun AVC Entry Video

2013-05-08T15:35:00.003-06:00

Here's a demo of Data Bus driving itself around in the rain outside my house. Sparkfun requires a demo submitted before the May 8 deadline. I actually submitted it on the afternoon of May 8, so I hope I'm not too late.

Data Bus is configured to travel slowly, around 6 m/s, between four waypoints outside my house. I ran it a few times and it seemed to traverse approximately the same route each time.

With only a month left, I guess I can stop procrastinating, now. I'd like to at least get a sense of how accurately I can control its path and make a few improvements before June 8.

Taking Time Off

2013-05-01T10:19:00.000-06:00

I am taking time off posting for the next couple weeks due to personal reasons. Last week I was too focused on fuel injection tuning for my Jeep to work on robotics or write articles.

AVC 2013 Course

2013-04-11T11:30:00.000-06:00

Sparkfun 2013 Course (from avc.sparkfun.com)

Unlike previous years, the 2013 Sparkfun Autonomous Vehicle Competition course is fixed through all three runs and the dimensions are, more or less, provided. However, after drawing a SketchUp model of the course, I am taking the dimensions with a grain of salt.

Reconstructing The Course

I started with a Google Earth screenshot of the area and scaled to better than 0.5% accuracy. I drew in the legs of the course, the barrels, start line, ramp, and hoop. This is what I got.

My model in SketchUp. North is not up.

It's not entirely clear if the first, top leg is actually 160' but the median is about that length according to Google Earth. Also, beware that the course is not aligned to north.

North is up in this picture from Google Earth

I was able to tweak the angles and lengths of the remaining 3 legs to arrive at 180', 160', and 165' respectively. In my version the distances to the curb don't match those of Sparkfun. The bottom is off by 5', the right side by 2'. I'm not sure why. Scaling accuracy would account for only 1' in 200'.

The Sparkfun drawing isn't visually accurate as you can see. It just gives the dimensions but even then it's hard to reconstruct from the data given. I intend to approximate the course during practice and on race day, take my own measurements and hope for the best.

3D Rendering

It's helpful to see some of the obstacles in 3 dimensions where you can rotate your view and so forth. The barrels look a bit less scary:

Here's the hoop:

The ramp looks more scary. It's tiny. It's right after the 3rd turn. Your robot has to finish the jump then merge left to avoid the curb.

Here's the SketchUp file:

AVC2013.skp

If you tweak it or get a better result, let me know.

Raspberry Pi Telepresence Rover

2013-04-04T06:00:00.000-06:00

Introducing my yet-unnamed Raspberry Pi telepresence rover. Everything the rover does is controlled directly by the RPi with no add-on microcontrollers.

The setup is simple using existing tools for motor control and streaming video. Here's the skinny on how I built it.

Overview

The rover consists of a Raspberry Pi in an enclosure sitting on top of a tracked chassis. Low voltage motor controlles are driven by the RPi GPIO pins controlled by REST services called from a control webpage via JQuery.

One of our cats, Dragon, was quite curious

A web cam provides visual feedback using mjpg-streamer visible on the control webpage. The rover runs off of a 3600mAH NiMH battery feeding into a switched 5V regulator board. The RPi uses a wifi dongle for LAN communication.

As for the details, let's start from the bottom and work our way up.

Chassis, motors, and motor control

The chassis is built around the Pololu 30T track kit that I picked up on sale a couple years ago. It comes with tracks, a pair of idler wheels and a pair of drive wheels.

I added another pair of Pololu idler wheels and mounted the idlers on short sections of aluminum L stock.

The drive wheels are mounted onto 150:1 Pololu gear motors which in turn are mounted to the top of the L stock with motor mount brackets.

I assembled each side independently, then cut a Lexan (polycarbonate) base. I found a new technique for easily bending/breaking polycarbonate: wood carving tools. I carved a groove in the plastic, then bent it in a vise for a clean break.

Each aluminum L channel is mounted to the Lexan base with long #10 screws and nuts. Extra nuts are used to raise the base above the motors.

The RPi enclosure mounting holes are used to attach it to the base. Holes are drilled in the base to permit removing the top cover of the RPi without unmounting the case from the chassis.

Wires were installed on the motors prior to installation. Those wires are in turn connected to a Pololu DRV8835 dual motor driver board.

This board handles all the tough stuff about driving motors. All you have to do is send it a 3.3V signal on two pins for each motor.

Controlling IO

I'm using webiopi and its built-in REST services to control PWM on the four motor GPIO pins from the main web page.

The control page includes webiopi.js and then uses JQuery to make function calls to set PWM parameters on the GPIO pins whenever a control button is clicked.

The DRV8835 uses a mode pin and four PWM pins. Details on how to use the board are found on the product page.

The control page is crude for now. It has 9 buttons. In the center is stop. Spin left and right are found to the left and right. Forward is top center, reverse is bottom center. In the corners are buttons that enable only one track, in either forward and reverse.

I'd previously experimented with variable speed, and fine control over turning but ran into issues with latency and had some bugs in the JQuery. I simplified the interface until I can work out something better that is also iPhone compatible.

Streaming Video

Streaming video originates from a Microsoft LifeCam HD-6000 with it's annoying, unnecessary autofocus disabled. The web streaming is made possible with MJPG-streamer. It runs its own web server on the RPi.

My control page simply includes an IMG tag: <img id="streamimage" src="http://192.168.0.4:8080/?action=stream" /> to display the streaming image.

Screen capture from today's cat observation mission

The camera is mounted with double-sided tape to a section of aluminum bar stock I bent into an L shape. That in turn is mounted to the RPi enclosure.

Raspberry Pi Setup

The RPi runs a standard Raspbian Wheezy distro. An EDIMAX USB wifi dongle provides connectivity and is configured with a static IP address.

The RPi is enclosed in an injection-molded plastic case from Cyntech which I consider to be one of the prettiest, nicest-looking plastic cases made for the Pi.

You can find them on eBay or MCM Electronics, and probably other sources, too.

Battery, Power Supply

The robot runs off a Reedy Wolfpack 3600mAH NiMH battery.

Why antiquated battery technology? Because I happen to have an automatic NiMH charger that I plan to hack into a docking station. Drive the robot up to it and charging begins.

The NiMH pack voltage is fed into a Pololu Step-Down Voltage Regulator D15V35F5S3 the same switching voltage regulator powering the electronics on Data Bus.

I used a section of aluminum bar stock mounted underneath the Lexan base longitudinally with a gap between the bar stock and the base so that I can use velcro straps to secure the battery.

The messy wiring in the picture at the beginning of the article has since been tidied up considerably.

Source

Full source is on the Bot Thoughts Google Code Repository, here

Future Plans

In addition the docking station I'd like to add servo pan/tilt for the camera, and battery meter circuitry so the RPi can display power statistics on the control page.

Thanks, Subscribers!

2013-04-02T07:00:00.000-06:00

This is long overdue, but thanks, readers!

I really appreciate you and I hope you find stuff on my blog helpful, entertaining, amusing or of value in some fashion. Maybe this is corny but you make blogging a really rewarding experience.

Several months ago, Bot Thoughts finally broke the 300 subscriber mark. Sweet! It's taken me awhile to announce that. So long, in fact, that the blog is now closing in on the 400 subscriber mark. Wow.

Sharp IR Ranger Noise

2013-03-29T07:00:00.000-06:00

Time to look at supply and signal noise on the Sharp IR I2C adapters I'm working on.

You often read how noisy these sensors are. Now you can see it for yourself.

The second revision of my board incorporates a 10uF tantalum bypass capacitor on the ranger supply, a 4.7uF tantalum on the ADC supply, and has an anti-alias RC filter feeding the ADC and features improved PCB layout.

ADC Measured Noise

First, I looked at the noise read by the ADC for each of the two board revisions to see if I'd made any improvements.

Apparently not. Both the Rev 0.1 and 0.2 boards have a similarly high level of noise. Disappointing.

Before looking at board design and ADC noise further, I decided to look at the ranger itself.

For my tests I used a 150cm GP2Y0A02YK (datasheet pdf). The board is hooked up to the ranger via 1.5cm lengths of wire. The board is powered through 5cm long supply wires connected to a breadboard. The breadboard is in turn powered from USB (eeZee Power) with 100uF tantalum bypass capacitor.

Sharp IR Noise

Despite a 10uF tantalum bypass capacitor very close to the ranger's supply connector, the oscilloscope shows supply voltage dips on the order of 0.1V at 200Hz measured at the ranger connctor.
These dips almost certainly correspond to current draw from the ranger's infrared LED.

Why 200Hz? So the ranger can bandwidth filter on that frequency to eliminate interference from other sources, most likely. Much as an IR remote typically runs around 40kHz. These rangers do work outside in sunlight, after all.

Pulses of 20mV occur on the signal line at the same times as the power supply dips suggesting that whatever internally generates the analog voltage is affected by the power supply.

Next I tried adding a 10 ohm resistor in series with a 10uF capacitor in parallel. This should isolate the ranger noise from any upstream circuitry.

The power supply waveform changed to a typical RC charge/discharge curve and the maximum swing increased to 1.2Vp-p.

Or rather, the lowest voltage was lower than before as you can see by looking at the scope grid. That makes sense with the series resistor in play. I would expect to see (but didn't check) that the other side of the resistor shows attenuated noise.

Something I didn't notice at first was the intermittent nature of the 200Hz pulsetrain. Here I'm using a 10uF bypass cap across the signal and a 100uF bypass across the supply. No series resistor.

The datasheet indicates the sensor samples at approximately 40ms intervals which matches my scope measurements of 8 divisions at 5ms/div. The ranger runs the LED for a period, then stops and generates a new output voltage.

You can see the output voltage changing in sync with the LED off period, below. (Sorry for the blurriness; I was handholding the camera with a slow shutter to capture the whole trace).

The top trace is the supply voltage (with a slightly different filtering configuration) while the bottom trace, the output voltage, shows the voltage jumps in the LED off periods.

Both channels are set to AC coupling so I could see small noise on top of big DC signal. In that mode, as you might expect with a large capacitor inserted in series with the signal, you still see abrupt (high frequency) changes in DC voltage, but the trace deflection decays over time, as in the left side of the bottom trace.

Good Enough?

I'm still working out the noise problem, just how much is tolerable, and eventually how to get good performance out of the ADC.

I've gotten the signal noise down to 5mV with a 10uF electrolytic bypass capacitor, and a 10 ohm / 100uF RC on the supply. But I'm just messing around at this point to get a feel for things.

Is 5mV of noise too much? By my calculations, the required voltage sensitivity of the GP2Y0A02YK at 140-150cm is about 2.6-3.0mV / cm.

To calculate the required sensitivity, I estimated data points from the datasheet and did a curve fit in Libre Calc.

So 5mV could be too much. Additional filtering could be done in software, with the ADC running at least 2 times the noise frequency per the Nyquist-Shannon sampling theorem.

Software filtering should be able to reduce the noise further. Whether through simple averaging, or by implementing a digital notch filter.

Tindie Items in Stock

2013-03-26T07:00:00.000-06:00

The gamut of breadboarding goodies are back in stock at the Bot Thoughts Store on #tindie:

How do you organize your cables?

2013-03-19T07:00:00.000-06:00

I don't and am soliciting your wise advice. Here's my mess of cables.

How do you organize yours? What containers, retainers, thingamajigs do you use to maintain order?

MRP App for Makers

2013-03-15T07:00:00.000-06:00

When done, MakerMRP will help me track parts inventory, BOMs, product inventory and sales for all boards I've been building and selling on Tindie.

After using LibreOffice Calc to try to keep track of nine products each with a dozen parts, I committed myself to spending 20+ hours writing a LAMP/AJAX/jQuery application from scratch while learning more about each on the fly.

Writing the app isn't about saving time. It's not motivated by laziness.

The mother of invention is an extreme, gut-wrenching, violent hatred of mind-numbing, boring, busy-work and the willingness to do nearly anything to avoid it.

Functionality

It's still a work in progress, but the tool is intended to manage the flow of parts ordering and of product building and selling.

Products

We start with a list of products. Products can be added, edited, and deleted. And each has an associated BOM.

Parts

Before you can have a BOM you need to be able to track parts. Each part can be added and deleted and each field can be edited.

BOM

Once you have the parts and products, you can add or delete parts to/from the BOM, or edit quantities.

Inventories

With each product, it's BOM, and lists of parts defined, the tool can keep track of inventories and orders for each product and part.

Let's say I want to build 3 more eeZee Propeller boards. I click the "needed" button on the Products page. The tool subtracts the correct number from the parts inventory. If I don't have enough parts, it keeps track of how many more to order.

Let's say I've run out of 5MHz crystals and need 3 to fulfill the needed number of products. The Parts list will show 3 in the needed column for the crystal.

I order them and click the ordered button on the Parts page. Now the need count is 0 but the ordered count increments by 3. When those parts arrive I click the received button and ordered goes to 0 and inventory increases by 3.

Building and Selling

If I then build those 3 boards, I click the built button on the Products page and the needed count goes to 0, the inventory count goes to 3. Then I sell one, and I click the sold button. Inventory changes to 2 and sold increments 1.

Coding Approach

You have probably noticed that this is a table-based, data-driven application.

Being relatively new to jQuery, inexperienced with PHP, and a newb at mysql, I opted to write this from scratch rather than using convenient tools like jqGrid or jQuery EasyUI DataGrid.

I focused on getting core functionality working first, then refactoring and generalizing, and refining.

Core Functionality

I started by following a tutorial, Creating a Web App from Scratch in 8 parts. It was a good start and I had something working pretty quickly.

The solution consisted of several php classes for database access, and several php pages for displaying the data in tables.

I used MySQL Workbench to do the database design and sync it with my database.

Refactoring and Generalizing

The tutorial above has two flaws.

Don't Repeat Yourself

First, the database-related code is duplicated across every php class. That breaks, in my view, the Don't Repeat Yourself principle. Updating code means more opportunities to make mistakes. Keeping code in sync is harder. Fixing bugs is harder.

I refactored the code to use a single class for all data retrieval. The next step might be to use polymorphism to encapsulate the details of getting data out of each of the tables. For example the Parts table is a type of Data table, but specifies the columns specific to Parts.

Cohesion

The second, far worse problem, was that the class code was a mix of html output and database input. It's better to keep your presentation layer (html, etc) code separate from your database tier code. The two concerns are logically separate. Mixing them means that you have to dig into the guts to change the way the application looks.

I pulled all the html php out of the classes when refactoring them into a single data class. All the presentation stuff lives in presentation php code.

Generalizing

As mentioned, I created a general solution for data-retrieval by refactoring several nearly identical classes into one Data class.

I also found myself duplicating code in the presentation tier. Instead of looping through rows of data and having code for every single column, I created a php function to print out each row driven by data from the database and metadata in a variable.

The metadata is stored in each presentation page (parts.php, products.php, etc.). Now instead of large, complex, duplicated table code, I have one line: row($metadata, $data); that displays all the rows for the table along with whatever editing, buttons, etc., that I need.

But it's not perfect yet. I'm duplicating this metadata across multiple display pages. Worse the list of columns is supplied separately when instantiating the Data class and again in the metadata variable, breaking the DRY principle.

I'm moving towards creating the entire table from a single module driven by a single source of data and metadata. And while we're at it, I could reduce to a single php page that prints out any of the display tables at will. I might not if it turns out to be too complicated versus having several very small php pages.

Complex Data Relationships

Just doing tables is easy. Where it gets hard is when you have data in one table that references another table. Each part can have a type. The name of that type comes out of the Types table. My code generalizes that problem.

As another example, a BOM entry corresponds to a single part and a single product. I've also generalized that problem.

Also, particular part appears multiple times in a Product's BOM. That's similar to the two scenarios above. I'll create a general solution for this problem next.

Inline Editing

I like applications that require few clicks and which flow easily alongside the real life activities they are meant to support. I don't want to have to visit a separate page to edit a record in a table, so inline editing was a must.

I tried jEditable and a couple other approaches, but decided it would be more beneficial to learn how to do this from scratch than it would be to use some particular package.

At the same time I'm using the metadata described above to define a few types of editable data: text that can be clicked on to edit, buttons to move numbers around, and pulldowns to select from existing lists, like selecting a part to add to a BOM or selecting a part's type and subtype (the Subtypes page is shown below for giggles).

I followed a similar path of refactoring and generalization ending up with a single jQuery script that will handle all the various application events. It's not done but the UI functionality is all in place and the events are captured.

CSS

Meanwhile I've been brushing up on my CSS. As much as possible, I've tried to keep the look and feel, placement, sizes, menus, buttons, and other things like that in the styles.css file.

The table's rounded grey borders, the left float placement of image buttons set up as sprites, the navigation menu, the title, all this is handled in CSS.

All unknown to the application, without which, the tables would show up as default with standard form buttons, etc. And in fact I coded without much CSS set up at first to force myself from inserting look-and-feel in the php.

Incidentally, I've done all this on my Linux Mint environment. After my outburst, followed by a nice vacation and some rest, my outlook greatly improved and I've been in the Linux environment for the last 3 weeks straight.

AVC 2013: Rules, Walkthrough

2013-03-14T17:55:00.001-06:00

Sparkfun posted the rules and course walkthrough for the 2013 Sparkfun AVC.

https://avc.sparkfun.com/

For us ground vehicle folks the rules are rather different and it really changes up the strategy.

If you finish the course you get 300 points from which your time in seconds is subtracted. You get 25 points for every corner you pass.

Two bonuses are possible, the hoop from last year earning 50 points and a jump ramp for another 50 points.

Finally, every run counts towards your final score.

Speed is no longer king. Consistency, accuracy, and precision are.

Propeller VGA Breakout Kit

2013-03-09T08:58:00.001-07:00

My Propeller VGA kit is $4.75 with 2 days left to order on Tindie. Generate VGA signals with your Propeller with software from the OBEX.

Propeller VGA breakout kit (prototype)

Furby Disassembly: Part 1

2013-03-05T07:00:00.000-07:00

"Cookie Muffin, Too"

Faced with a malfunctioning $8 Goodwill Furby, I set about non-destructive disassembly of my daughter's new sick pet, inspired by the dramatic skinning of a Furby by Becky at Adafruit.

I was also inspired by Doc McStuffins.

And yes, I was secretly happy the Furby wasn't working; I confess having had thoughts of disassembly the moment after I saw the price tag.

Don't worry. No Furbys were harmed in the making of this blog post.

The Furby was making odd chattering noises, strange light fluctuations in the eyes, and shutting off unexpectedly. For awhile the eyes and beak weren't moving in time with speech. New batteries helped a little but this was a sick little fella.

He's got lifeless eyes, black eyes, like a doll's eyes.

Removing the Fur

First step is to remove the battery cover and remove batteries. That's easy enough. Then remove the screws around the battery tray that hold a retaining clip which keeps the bottom end of the fur in place.

Next, start peeling back the fur. Near the tail you'll find a loop attached to a hook. Remove that.

Now peel up the fur. It is clipped in two spots at the back, around the ears and around the face with locking plastic tabs.

Locking tab shown with small slot below for unlocking.

In most cases, wherever there's a clip, there's a slot below it so that you can insert a small screwdriver and push up on the locking tab and pull out the clip.

At the front, after removing two screws holding the fur to the body, insert screwdriver to unlock the tabs, unplug the red wire, and pull the fur up.

Two screws and two clips in front below face.

Remove the red tickle sensor wire.

Now pull up the fur to each ear, for which there are two more clips. You'll need to remove the ears first. They are held in by internal clips so you may have to pry, twist, etc. to get them off.

Remove ear clip with screwdriver in small slot

One ear of the furby popped right off, the other took more work and came off in two pieces, the actual ear first, which came loose from a glued-in retaining clip (still attached, below).

Ear pulled loose from retaining mechanism

Now, insert screw driver and remove the ear clips. The right top clip can sort of slide out in front of the ear if that's easier.

Remove two white plastic covers that go over the ear nubs (shown below).

Ear nubs, white ear cover things. Right ear came off in two pieces.

The fur is clipped in two spots at each side of the face. Again with the screwdriver to pry the locking tabs out of the way, slide out the clips.

Clip at side of face

There are two more clips at the top above the face.

Clips at top of face, clips/ring for ears shown.

One top clip removed

You are now left with this fascinating and in no way disturbing sight. You might as well put the batteries back in so it can talk to you in this state. Fun.

Skinned Furby

Removing the Back Cover

Four phillips screws hold the back cover on the Furby. You will probably have to cut through some tape to get to them all. There are two at the bottom on each side, and two at the top near the face clips.

Right bottom screw

Left bottom screw

Top screws between ears and sliver sensor

Before you remove the back cover, you have to peel back the silver sensors on each side. As you have no doubt guessed, the Furby uses these to detect if you're petting its head or holding him or whatever.

It's affixed with good old fashioned clear tape. Peel it up with something sharp. You can always re-affix the sensor with packing tape.

Right side sensor, peeled back.

Peel back the left sensor past the white speaker grille, further than shown below.

Left side sensor, peel back further than this.

Now you can remove the back cover.

Inside there's an optical encoder board for the eyelids using a Schmitt trigger inverter, plugs for the speaker, and other goodies that I didn't really explore further.

Inside the back cover

Optical encoder for the eyelids. Try running the Furby in this state...

Speaker connector and... I'll find out later.

I'll find that out later, too.

I'll post more details when I disassemble further. I thought I had the Furby working again but after putting it all back together... I was wrong.

Graphic LCDs for Data Bus

2013-03-01T07:00:00.000-07:00

Graphic LCDs are excellent debugging tools. Digole offers an I2C adapter with Arduino library that I've ported to mbed.

128x64 Graphic LCD on Data Bus displays GPS, battery, etc.

The 128x64 module I used on Data Bus was indispensable last year. It graphically displays battery voltage, GPS fix quality, and also displays IR ranger information. No ground station required.

With limited serial ports and a desire for XBee (or something) wireless, I wanted to run the LCD off the I2C bus. Digole's universal backpack supports serial, I2C, and SPI, selectable with a solder jumper. The solution is fully-wrought with good documentation and Arduino demo and library code.

My Digole backpack on a giant LCD

After responsive customer support helped me fix a manufacturing defect on my own (wrong resistor installed in a voltage divider), I2C worked. For the time being I wrote the mbed library to speak only I2C. It uses Arduino print routines.

The backpack supports common graphic LCDs. Digole also sells OLED backpacks that use the same library. Since the LCDs I have are so heavy I may switch to an OLED instead.

While experimenting, I found something odd. When I held the backpack and LCD just so, it would operate stably, when I didn't I'd see junk characters or other misbehavior. Apparently my thumb was acting as a pull up resistor for a pin pad marked NC. A 10k resistor replaced my thumb with the same effect.

If this is a KS0108-driven LCD (the eBay seller didn't specify), the NC pin would correspond to Chip Select 2 (CS2). Perhaps the backpack simply shouldn't be configured for KS0108. I'll edit this if I find out more later but for now it works reliably and I can get busy porting Data Bus code to use the new LCD.

Data Bus Software Design

To that end, I am working to decouple display details from the main code, an inevitable side effect of scrambling to get a robot done for a competition.

Main routines should not know how to draw boxes and bar graphs, locate cursors and print data. Nor should it care whether the output device is a Digole or Sparkfun backpack, or even if it's a 128x64 Graphic or 16x2 text display.

I'm shooting for a more flexible solution that supports any number of output devices interchangeably. By the same token, I also want the same kind of flexibility for sensors and input. Why?

My dream is to make a hackable, flexible autopilot software and hardware for other hobbyists. I don't want hardware lock-in like I see in some 3d autopilot solutions; I want hackability and flexibility. Run whatever sensors, outputs and ground stations you want and reuse or write code modules accordingly.

2013 Sparkfun AVC location announced!

2013-02-28T08:01:00.002-07:00

Barrels of doom. 2012.

Sparkfun announced the location of the 2013 AVC on their Google Plus page:

Ladies and Gentlemen, start your engines! We have now nailed down the location for the 2013 SparkFun Autonomous Vehicle Competition - it will take place on June 8th, 2013 at the Boulder Reservoir. We are still hammering out some final details (including entrant and spectator signups) which will be forthcoming, but save the date! We hope to see you there!

mbed sdk is open source

2013-02-26T07:00:00.000-07:00

from mbed.org

The mbed team announced a few days ago that their SDK, that is, the new mbed library, is open source.

I'm sure more than a few folks had some reservations about such a previously closed system.

For me, it'll be very educational with great examples on how to implement the mbed library of which I'm quite fond on LPC. They have extensive internals documentation posted up. I've scanned through it and I think it'll make a fascinating read.

It will likely open the door for porting to other Cortex M chips and platforms as well. Think LPC1769, STM32F4, Stellaris, etc.

AVC 2013, Sharp IR I2C

2013-02-22T07:00:00.000-07:00

My AVC 2013 preparations have begun.

I have a list of improvements planned for my rover Data Bus to make it faster, more precise and accurate. I'll soon add the convenience of telemetry and FPV.

Some changes are small but quite helpful. One such improvement is to I2C-ify my Sharp IR Rangers.

Last year, Data Bus used a Sharp IR ranger as a last-minute, last-resort device to curtail violent curb encounters during testing.

My beautiful electronics layout, ruined by...this.

Lacking free ADC ports on the mbed required the addition of a butt-ugly protoboard Arduino to translate analog ranger signals to I2C. I will be replacing it with something like this. Prettier, no?

Early prototype for my Sharp IR Ranger I2C Adapter

It's a tiny, general purpose board that will adapt any Sharp ranger to digital I2C. Or any analog sensor, in fact, with the performance advantages of a dedicated, 188.9kSPS ADC near the analog sensor. The board includes the recommended 10uF decoupling capacitor for the ranger. A single I2C bus can host 9 of the devices, each with a unique address.

It's built around the Texas Instruments ADCxx1C021 single supply I2C ADC where xx is the bit resolution, 08, 10, and 12. The chip costs under $4 in single quantities. (More info: ADC081C021, ADC101C021, ADC121C021)

Resolution

Resolution is a challenge. The Sharp GP2D12 analog signal range is about 2V with supply voltage of 5V according to the datasheet (pdf). A single supply, single-ended ADC running at the same 5V as the ranger, therefore, loses more than 1 bit of resolution. So, how many bits of ADC resolution is needed?

This plot shows the non-linear Range (cm) vs LSB
relationship for the big 5m sensor

In the GP2D12 datasheet, there's a plot of voltage versus distance. ADC resolution is more important for longer distances as you can kind of tell from the plot above. Close in, 10-30cm, the sensor sensitivity is 110mV/cm and at long range, 50-80cm, it is 6.67mV/cm.

A 5V 8-bit ADC has a resolution of 19.5mv/LSB, almost 3cm/LSB at long range. Better is a 10-bit ADC with a 4.88mV/LSB or 0.73cm minimum resolution. Best is a 12-bit with 1.22mV/LSB or 0.18cm resolution. I'll probably be able to get away with a 10-bit ADC.

I don't know what the Sharp sensors' resolution is in mV. I've looked at sensor output on an oscilloscope and it is not purely analog because it changes in small steps.

Layout

As a part of this project, I spent some time learning about mixed signal PCB layout and ground planes. One of the best resources I read was this Maxim paper, Successful PCB Grounding with Mixed-Signal Chips - Follow the Path of Least Impedance. The ADC's datasheet also provides good information about layout and PCB design.

The gist is that low frequency signals follow the shortest path on their return to ground, while high frequency signals (say around 100kHz and up) return to ground under the corresponding signal trace because the signal current reduces impedance on the adjacent ground plane. In short, signals follow the path of least impedance. Shocking, I know.

My next set of prototype boards implement the Maxim paper's suggestions. I'll test noise performance and also attempt to answer some questions I have about the best way to use a ratiometric ADC on a noisy digital sensor like the Sharp. If you have a 10uF bypass capacitor on the Sharp supply, should the ADC also feed off that point? I think so but we'll see how much it matters.

Incidentally, I don't need to go to all this trouble for a curb sensor. I plan to make this board available to other hobbyists and I want it to work well.

Here are some more papers:

Analog Devices AN-202 (pdf)
Elmac paper, "The ground plane: Lord of the Board", (pdf)

Stuff I'm up to and Tindie

2013-02-13T17:14:00.000-07:00

First, I'm very honored that Bot Thoughts blog has been selected as one of the Top 100 Resources for Electrical Engineers.

Stuff I'm Up To

As usual, I have a number of irons in the fire.

In prep for the 2013 AVC, I plan to add an Xbee radio to Data Bus, my autonomous rover, to implement remote telemetry and control. I must first free up a serial port on the mbed. I bought an I2C-based Digole LCD adapter to replace the rover's invaluable serial LCD.

I discovered and repaired an mistake (the wrong 0603 resistor was installed) and now it works with I2C on the mbed. I'm currently porting the company-supplied Arduino Library to mbed while learning more about C++ inheritance and virtual member functions.

I'm redesigning the Data Bus baseboard. It will be pro-fabbed after home-etching the first few iterations. It'll either be mbed- or LPCXpresso-based. Next version will get an onboard ARM, either LPC1769 or STM32.

My Raspberry Pi telepresence rover is done. Or, at least the initial phase. I'll share more about that soon and document enhancements as I go, too.

I'm also starting to gear up for STM32F4 development. I'm planning a machine-vision system based on the Toshiba tcm8230md camera. Some of the STM32 series have camera peripherals that should work with the this Toshiba 640x480 color camera.

If a little ATmega8 at ~17MHz can run the AVRcam to track multiple colored objects, then a 168MHz STM32 with far more memory and the benefits of DMA should be able to do a lot more.

On a related note I've been working on interfacing a Game Boy camera (Mitsubishi M64282FP) with a dsPIC33F and digging into assembly on that MCU. It's really quite fun. It's on hold for a little while but I'll get back to it soon.

The mailbox notification project, using JeeNodes, is on the back burner but not forgotten.

Tindie

The eeZee Propeller is back in stock on the Bot Thoughts Store and the ATtiny24/44/84 Board should be soon. Same for the ATtiny2313/4313 boards. My eeZee Power usb breadboard power module is funded and then some. Cool.

The fundraiser microSD boards will be delivered in the next few weeks, populated, and sent to supporters.

I'm also working on a a couple new products: a Sharp IR Ranger I2C adapter and a VGA breakout adapter for Propeller.

Migrating to Linux: Day 7

2013-02-11T07:00:00.000-07:00

That does it. I give up.

I'm writing this within Windows Vista.

When you spend two hours trying to get any kind of stupid serial terminal emulator working, and wind up not getting any of them working, something is not right.

Background: I'd installed Mint-14 to compile an AVR gcc toolchain. That went fine. Installing ARM gcc with m4 hard float support was frustrating due to numerous package dependencies and stlink issues. Eagle install, cake. LTSpice under Wine, no prob. Printing? Took awhile to find the right driver. The hours just seemed to fly away.

Working with the new Serial/I2C/SPI LCD for Data Bus brought about the last straw. I wanted to take a few minutes to test the LCD. Fire up a serial terminal, connect Bus Pirate, check some things, then move on to porting the library to mbed. About that serial terminal...

Many forums recommend minicom as the go to serial terminal program. Really? I remember using that awkward relic in the early 90's. CTRL-A Z is not a convenient key sequence. And heck, it didn't even work with my Bus Pirate anyway. Then I tried and ran into all sorts of issues with running a terminal emulator under Wine and even VirtualBox.

This should have been a five minute deal. Find, install, run, get on with testing my Digole serial LCD adapter. And it was a five minute deal, right after I booted into Vista.

I said it before and I'll say it again. Linux is really fast. In the time it takes to get something working in Windows you can try hundreds of times to get the same thing working in Linux. And still fail.

Now, where'd I put my Win 7 x64 Ultimate disc...?

Migrating to Linux, Day 6

2013-02-09T16:04:00.002-07:00

Flashing STM32F4 Discovery

I almost gave up. Trying to flash my STM32F4 Discovery has been a nightmare. The stlink code I found didn't seem to work reliably for me. At long last I discovered OpenOCD does work. Then realized that it was mass-erasing the chip before flashing. Trying that with stlink works better. But I'd rather erase only what's needed. So, still struggling but at least there's hope of developing on STM32 on Linux.

Time Machine

Meanwhile I discovered something that would be painful to do in Windows (I think), emulating a TimeCapsule. Using netatalk 2.2 (apt-get install netatalk) I followed this guide but ignore the bit on Avahi and use the tm option on your volume.

The network backup disk does not support the required AFP features

After attempting to backup on OS X Lion or later, you get the "does not support the required AFP features" error. You may find in your Mac's /var/log/system.log that your Time Machine volume doesn't support TM Lock stealing.

Make sure you're running netatalk 2.2 or higher which supports the required AFP 3.3
If it's enabled, disable the afpd service in avahi by removing /etc/avahi/services/afpd.service (whatever it may be called) so that netatalk can advertise the volume; restart avahi-daemon.
Add tm to the options in AppleVolumes.default and restart netatalk
Unmount /Volumes/TimeMachine (or whatever the volume is called) on your Mac or it won't see the changes you made on Linux.

JeeNode AA Power Board

2013-02-08T07:00:00.000-07:00

I'm using JeeNodes for a project to notify me when the mail has arrived. You know, like packages containing electronics goodies.

With basic communications working in the lab, it's time to prepare the mailbox JeeNode to run off a battery. I bought a AA Power Board from Modern Device and installed it. The Power Board powers a JeeNode at 3.3V by boosting a single AA battery voltage using an LTC3523 boost regulator.

The design is very clever, offering many ways to connect the power board to your existing JeeNode. I chose to put it on the bottom side. Here's how.

First, break off 8 pins of the included, extra-long breakaway header and install into the JeeNode so the short side with the plastic is on the top and the long side goes through the board.. This will be the main connection and physical support for the AA board.

Next, break off one pin and install it in the SS pad, again with the plastic and short end of the header on the top and the long side going through the board. Do the same for the I0 pad. These two pads are outboard of the SPI header pads which are located between P1 and P4 right next to the RFM12B module.

Now, solder on the battery holders on your AA Power Board. You can put them in a position to use a AA, AAA, or CR2. Finally, slide the power board on over the long side pin headers making sure the bottom side battery holders don't contact anything, then solder into place. The power board is now supported by 8 pins at one end and two at the other. Nice and sturdy.

Configure the Power Board to output 3.3V by soldering the +3V solder jumper. Another solder jumper labeled BCHK permits the battery positive voltage to be routed to Arduino analog pins A4 or A5 (note that one cannot do this and also use I2C). In code, use analogRead() to determine if the battery voltage is dipping too low.

After connecting everything and installing a AA, I connected the other JeeNode to my PC and lo and behold, the battery powered JeeNode was transmitting properly.

OKG 5 97 0
-> ack
OKG 5 97 0
-> ack
OKG 5 97 0
-> ack

It feels good to make some progress again. The next step is to refine the code on both nodes. I'll tell you about the completed physical sensor at a later date.

Migrating to Linux, Day 2

2013-02-05T07:00:00.000-07:00

I finally got fed up with Vista and decided to switch over to Linux Mint 14 as my primary OS...

...with the intent of never going back.

Will I survive?

Ok, I haven't given up Windows entirely. Wine and VirtualBox are in play. Both look promising. Also, I've mounted my Win NTFS partition read/write. (Ha, you kids have it easy now! Why, back in my day...)

The cause of my switch? WinAVR is 3 years out of date and doesn't support the ATtiny84A of which I just bought 3 to test my ATtiny24/44/84 target board. In frustration I built the entire AVR toolchain from scratch on Mint following Lady Ada's tutorial.

My first pain was the awful, too-twitchy mouse. Got that fixed with some xinput/xset magic.

Losing Picasa sucks. Either digiKam will have to do or it's Picasa in Wine (as Google originally shipped it for Linux). I wished I could see what pictures I've uploaded to Picasaweb.

LTSpice works great in Wine. Eagle is fast but with a niggling key binding issue.

Chrome, GIMP, no problem. I want Notepad++ back.

I'd just fallen in love with TortoiseSVN... thankfully, RabbitVCS works very similarly. Although Mint/Nemo isn't officially supported, it works a-ok with a little trickery.

Probably my biggest regret/pain is having just paid for Carbonite. That was the one thing holding me back from Linux and the one thing tempting me to go back to Windows. I hate to waste that money.