Second, a beetle-like walker that can easily navigate rough survaces:

Progress on robots has been pretty steady for years, so what is interesting about these particular examples?

The ability to direct a robot’s higher level movements with reliable outcomes.

That is, a shift from directing robots with syntax (manipulating control surfaces, motor speeds, servo positions) to directing with semantics (go to the living room).  Robots like those shown above will soon be able to take commands at a high level and carry them out reliably and safely.

Broad access to robot servants

We have reached a point in sophistication and cost where small, autonomous robots can be controlled with higher level commands.  To learn to fly a quad-copter via remote control of throttle and pitch in a way that can navigate a window with 3 inches of clearance takes hours of practice and crashed copters. As shown above, now we can merely command that it be done.  The cost of these devices has reached a few hundred dollars each and will continue to fall quickly.

Swarms of robots (“many hands make light work”)

These developments mean that small robots can be directed to “got into the living room” or “fly across the park without hitting anything and find little Bobby.”

The possibility of cheap, small autonomous robots performing tasks such as searching for hurricane survivors, mapping oil spills, collecting anti-personnel mines, carrying out surveillance, assisting you in the garage or mowing your lawn is now very real.

With the ability to direct them at a high level, the opportunity to carry out large tasks with many small specialized robots is in reach. With our current knowledge of collective behaviors, swarms of robots could be called on to perform large scale work requiring collaboration and coordination.

Bio-mimicry and fear

There is something unsettling about both of these videos.  They both demonstrate movements that are life-like, and often associated with animals we’d rather not have too big or too close.  Both robots execute robust recovery and control actions much like beetles or house flies. I postulate that this bio-like attribute is core to the technical success demonstrated here.  But it is also clear that this attribute may be more a than a little distasteful to people.

Will we adapt to the creepiness and have a swarm of crawlers clean the house? Or is this technology DOA because it violates some survival instinct?

Another concern is the new, cheap capabilities to do harm that come with any technological advance. Will ethics and countermeasures evolve fast enough to head off a major mis-appropriation of robot swarms?

64 Fireflies Part II from tinkerlog on Vimeo.

I wanted to be able to add an embedded Web server to my projects.

I chose the MatchPort AR because, with the same experience, hardware, and nearly the same software configuration, I would be able to move to a wireless solution with the MatchPort b/g Pro. (The MatchPort b/g uses a different OS.)

I wanted to get up to speed quickly, so I purchased the demo kit, thinking that would include all the software and hardware I would need to understand and learn how to use the MAR in a project of my own. This was more or less the case, but getting up to speed was much slower than expected.

I thought I would be up and running demo apps in an afternoon and off to my first project early the next morning. Instead, I spent hours understanding the paradigm assumed for the MAR, hunting down example code, working out details and trying to understand the MAR’s somewhat convoluted documentation.

I hope this tutorial gives the first-time embedded TCP/IP/HTTP server users a fast and straightforward introduction to the MAR. And maybe I can save more experienced users the hassle of tracking down the details of how the MAR can be coaxed into becoming a working embedded network component.

Download The MatchPort AR Missing Tutorial (PDF).

Below is the schematic.  The changes from Dan’s datalogger are that I used the PIC16F886, which is pin-compatible with the PIC 16F876.  I also used the PIC’s hardware serial I/O channels (pins 17 and 18) and I added an indicator LED that indicates logging in progress and the log interval (pin 22).  The switch sets the mode between logging and writing data over the serial port.

The C data logger code is available here as is a hex file with 1 s log interval. I used the CCS compiler. This makes reading and writing program memory very straight forward with commands like write_program_eeprom( prog_mem_adr, value ) and read_program_eeprom(prog_mem_adr). The 16F886 has 8192 total program flash words. The total time of logging is determined by the delay setting at line 64 of main.c.  Use a frequency counter at the indicator LED to set the desired logging interval. If you don’t add any lines to the code, you can increase the memory used for logging by setting START_ADR to the lowest open memory address. You can get this information with, e.g., the PICKit2 programming application or whatever your favorite PIC programmer provides.

Here’s the completed logger with a LM35 temperature sensor (suspended in the foreground) and a 7805 regulator (on the back left corner of the board) with a 9V battery attached.

I wanted to configure this for use with the CCS compiler IDE. After a few minutes of searching on Google for an answer, I didn’t find one.  So I set about figuring it out.  Here’s my solution:

The CCS Compiler allows a user to add buttons to execute 3rd party applications under the “Options|Tools” menu item.

Open this dialog box and in the dialog box, under “Name” add the name, e.g. PICKit2. Under “Usage” use the drop down menu to select where you want the new button to appear.  I added one for both “Tools Menu” and “Compile > Program Menu.”

In the “Command” box, you need something like this: “C:\Program Files\Microchip\PICkit 2 v2\pk2cmd.exe” “-P%D”  “-F%H” “-M” “-h3″

You need to add the path above to your windows “PATH” variable (under “My Computer|Properties|Advanced|Environment Variables”–I had to log out and log in for the changes to take effect.)

The %D parameter is the device name including “PIC”, e.g. PIC16F648A.  “-M” indicates that the chip is to be erased before programming; %H is the name of the hex file to program to the PIC chip.  Finally, “-h3″ tells the application to wait 3 seconds before exiting.  This is a great feature as the CMD window opened by the application closes immediately when execution completes. Without the delay, you don’t get to see any of the output messages.

Be sure to read the Readme file that comes with pk2cmd.  There are additional command options for reading from the device, powering the device, etc just like the GUI interface for the PICKit2.

Hit the “Apply” button.  Be sure to save the profile by hitting the green disk “Save” button to the right of the “Tools” menu, again, under the “Options” menu. If you don’t do this step, you won’t have any custom buttons when you restart.

I hope this helps.

Fortuitously, the last issue of Make has a short article on page 157 on the topic of DIY electrocardiographs.  So off we go…

I first decided to go with the instrumentation amplifier built from three 741 op amps as described in the article.  I added the simple resistance-capacitance filter recommended in the article, got some conducting 3M Red Dot electrode pads and hooked the whole think up to the USB Bit Whacker for data collection (see Accelerometer from a few days ago.).

What were the results? Well, a qualified "it worked," but this needs some work.

The amplifier.  We need a gain of about 1000 to get the signal in the range of the A/D capabilities of the UBW (0-5V, 10 bits resolution). And we need high fidelity differential amplification of the inputs. This is called the common-mode rejection ratio (CMMR).  We need a CMMR of 100,000:1 (~100dB).  Here is the schematic:

I added the recommended RC amplifier to the output to clean up the signal a little.

Here are some photos of the construction process. The circuit is point-to-point wired on a proto board and the whole think is mounted in a small aluminum case. The basic circuit is only a few components so it didn’t take long to build.

The amplifier is powered by two 9v batteries to provide +/-9V for the op amps.  This means the output signal varies from something like -8 to +8 volts. Feeding the A/D of the UBW a signal between 0-5V is going to require some adjustments.  I added two 10K ohm potentiometers for null offset to I1 and I2.  (I now think this was a naive mistake because these have to be set very nearly equal for the amplifier to work.) I also added a 500 ohm gain adjust potentiometer in place of the 200 ohm fixed resister recommended.

When I tested the amplifier with DC input signals, I grounded one input and varied the input at the other with a simple voltage divider.  This didn’t expose any of the weaknesses of my design decisions. The null offset adjustment worked well. The test showed a gain of 1000 was easy to attain and that the amplifier produced a nice looking linear response.

So I closed up the case and was off to measure my heart beats.

Contact pads.  I started with some home-grown copper electrodes.  While I did get a small signal–intermittently–this wasn’t going to work. To the Internet to buy the real thing from 3M.

I attached my new amplifier to the UBW analog input channel and modified my Python script (accelerometer.py) from the accelerometer experiment to capture data on one channel every 10 ms.  Here are the results:

And some detail…

It is clear that external signals are swamping the desired heart beat signal.  It also may be the case that the amplifier-A/D combination is so poorly matched that there is some distortion of the data.

What to do different:

* Shorten the input leads–they seem to be acting as large antennae to the 60 Hz AC line frequency
* Build a better filter (active)
* Build/buy a more robust instrumentation amplifier
* Use a smarter method to translate the output to the required A/D voltage range
* Best of all, have this experience

The UBW lets you control pin input and output though the USB port on your computer with a few simple commands.  Using standard USB/Serial drivers on the computer (available from Microchip and elsewhere), you can interact with your UBW through a terminal application or any language the speaks serial. That’s all there is to it. I built an 18F4550 board that uses Brian’s UBW firmware with a minor modifications. But for real speed, just buy one ready to go from Sparkfun (shown in the photo).

I got a new +/- 2g accelerometer and a UBW from Sparkfun and wanted to see them in action right away. Using my UBW from Sparkfun, I added some header pins and used some jumper wires to hook things up as shown in the photo (this part takes about 2 min if you move slowly). The accelerometer is a 2 axis (x-y) device that offers voltages at the outputs between 0 V and Vcc (roughly) that are proportional to the acceleration along the x and y axes. Since there isn’t any difference between the acceleration due to gravitational force and that due to changing speeds, the device can work dynamically to measure motion (acceleration) or pseudo-statically, to measure orientation in a gravitational field.

(Click for full-size image)

  With a few lines of Python code reading the serial port, I was able to log data from both axes of the accelerometer as I slowly rolled the accelerometer along my desktop. The resulting data is shown in the plot below.  As you can see, I rotated the device through 360 degrees in about 22 seconds, taking a few readings per second.

Links:

* Sparkfun — Lots of cool stuff here!
* UBW at Sparkfun
* UBW Homepage
* Accelerometer data sheet
* Accelerometer at Sparkfun 
* Python data logger application

Here’s the LinStepper driving a small stepper motor at 12V.

And here’s a close up of the Stepper Tester.

 If you want to build one of your own, here’s the schematic and circuit board (600dpi) artwork.  I used a 470 ohm resistor for the LED, 10K ohm resistors for the pull-ups, 2 500K pots for frequency and duty cycle adjustment and a .1 microfarad capacitor for the timing cap.  The 7 pin header matches the layout of the LiniStepper.  The upper 2-pin jumper in the photo is power input to the regulator circuit; the lower 2-pin header is for additional 5V supply (here I am powering the circuit directly from my bench supply).