Robots Rob

This page last updated: 5 November 2016

In Autumn 2013 I decided that I wanted to make an autonomous robot.  The idea was to build something that could wander around the garden, doing something, and return to its charging station when low on juice.  Mechanically, I was inspired by a rather expensive octopod that I had seen on-line, so I initially looked for some sort of octopod chassis upon which I could build my robot.  Finding none, I was advised that the best way forward was to purchase a Dagu Wild Thumper all terrain chassis and stick a Raspberry Pi on top of it as the brains.

This page is my robot building diary, starting with the initial details at the bottom and with updates on progress in chronological order, most recent at the top.

All the software involved and the PCB/schematic information is pushed to my github repository at

Need A MK II
5 November 2016

It's been a long time since I last updated this page and that's because I've accepted that the infra-red sensors that are at the centre of the docking mechanism aren't going to be good enough; they are simply drowned out by daylight.  I could spend more time reading proximity data from the other sensors on board but I don't feel confident that it's going to be good enough.  In the meantime I've been occupied with lathes and milling which, I hope, will give me the capability to be more subtle in my design of a robot MK II.

So I am going to pause this design here.  I have software I can re-use and I've learned something of PCB design (and what not to do with battery charging).  I'll need to spend an interlude on the outdoor railway and using my astrophotography kit, and can mull over what RoboTwo will do in that time.

Charger Base
23 April 2015

The charger base is now assembled.  The outer ring of the bearing is held both up and in position by two segments of 4 inch sewage pipe, kindly donated by my colleague Damian.

                part of bearing support
                part of bearing support

With some brazing I've fixed a brass bar to a collar which then fits onto the spindle of the stepper motor.  The central white tube of the charger base, which is a push-fit into the inner ring of the bearing, has two slots cut in it so that it engages with the brass bar and hence the white tube is rotated as the stepper motor rotates. 
Note: I decided not to use the slipring as it was too weedy and I was happy enough, now, that the software would prevent the pole rotating too far and tangling the cables.

Brass bar brazed to collar
Brazed bar engage with the central white tube

I've also brazed a nut onto the end of the longer piece of brass bar that holds the charging probe of the robot itself, and screwed it into the robot, so that's all nice and solid and wired up.

Nut brazed to charging probe of RoboOne
Charging probe screwed into place and wired up

Then there's the mounting of the quarter-inch jack socket on the central pole of the charger base.  I deliberately wanted to make this arrangement quick and dirty as I'm sure it is going to change.  So I bought a silicon-rubber funnel from our local cookshop, chopped the end off it, found an old plastic pot that once held a role of 35 mm film and drilled a hole in the end, into which I fitted the quarter-inch jack socket.

Small silicon funnel
Old 35
                mm film role container with quarter inch jack inserted

When I tried shoving the quarter inch jack plug into this assembly at random angles (as the robot would) I found it got stuck on the rim of the socket. So I took the top from the same film role container, drilled a hole in it, cut it down to size and glued it into the funnel around the socket.  This seemed to make the plug insertion flow a lot better.

Film role container cap drilled
                down to size

And then, to complete the Heath Robinson assembly, I attached all this to the upright plastic tube with cable ties.

Socket box
          attached to charger base pole

At the top of the pole, I fixed the Pololu IR beacon in place.

IR sensor attached to
          top of charger base pole

So, with all the electronics mounted neatly in the lid of a box, and with the power supply in the bottom of the same box (grommets on order to route cables neatly later), there we have it: the first version of the charger base assembled.

Charger base

All that remained was to test it.  Here's what happened:

As you can see, though it sort of works in daylight it works properly in the dark.   Those Pololu infra-red beacons are being saturated with daylight from all around and hence are desensitized to the signals they are meant to monitor.  I think some fiddling with shields and reflectors is in order.   Or maybe I have a robot which comes out to feed at night.  Anyway, I'd better get that robot moving towards the charger now.

Activity Over The Last Year
19 March 2015

There has been lots of activity over the last few months after a 6 month break while I had my loft converted into a robot hatchery.  First of all, Sharp IR distance (4-30 cm) sensors were added:

Sharp IR2Y0A41SK0F 4-30cm

...around the whole robot:

IR sensors in position

...connected into the A/D ports on the Orangutan.

Then I began assembling the charger base.  Aside from the components below, I decided that I wanted a ball bearing with an internal diameter that exactly fitted the upright of the base (so that the upright could be simply pushed into place) and, as I might have expected, a quick internet search found exactly the 1 7/8 inch bearing I was looking for at Bearing Boys.  Here it is, sitting atop the stepper motor that has now been mounted inside the charger base.  A beautiful and sufficiently greased thing.

Bearing above motor in

Then I have attached the power connector (a quarter inch audio jack) onto the robot as follows:

charging connector

So what remains is to get the remainder of the charging base sorted, something like this:


However, I had a few attempts at assembling the circuitry around the charging base;

Charger circuit board

...and managed to blow-up three Raspberry Pi's by connecting more than 3.3 Volts to their GPIOs.  Not good.  At the same time, I was running the robot from the "mains power" of the charging base (i.e. with the chargers of the robot on) and found that it sizzled two more batteries:

More sizzled

Definitely not good: both a fire hazard and a waste of batteries.  It is occurring because there is one charger board for each battery but, since the three batteries driving the Orangutan are paralleled, the chargers are sensing the aggregate voltage of the set, not that of each individual battery.  So I decided to take some time to build coulomb counting into the charging software for RoboOne (since the DS2438 chips tell me how much current has been fed into the batteries I can use that information to limit the charging) and, as a backup safety feature, to add TMP36 Analog Devices temperature sensors:

TMP36 temperature

...snuggled up against each battery:

TMP36 at battery

...and wired into the spare analogue mux on my PCB connected to the OneWire bus and thence the Pi, as a further safety net.

To make all of that work I needed some additional software which I am currently testing.  Then I can set to work on finalising the physical design of the charger base, using some sewage piping that Damian Harris-Dowsett has been good enough to provide to me from his on-going loft conversion work, before I am tolerably close to trying out a docking manouvre.  Maybe.

It Moves
29 April 2014

After five months work, and some ribbing from work colleagues over the fact that my six-wheeled robot hasn't yet moved an inch, I have finished enough software (hardware server, state machine server, tasking server and monitor/dashboard application to use them all) to make the robot move.  Here are its very first steps.

My interface to the 'HW API', at the moment, is to set a speed and ask the robot to move a given distance at that speed.  However, what I'm finding is that the distance travelled varies from what one would expect (from distance = speed * time), and also depends on what speed I set the robot to run at.

Distance versus speed

This will need some calibration.

PCB1.1 Done
28 March 2014

PCB Pool showed this morning that PCB 1.1 is now manufactured. Exciting.

PCB 1.1

Auto-Off Fix, 12V Detect, More Watts, PCB 1.1
22 March 2014

My first attempt to provide an "enable" signal to the Darlington driver array was this:

          to provide an "enable" function for the Darlington
          array  Prototyping

...where "out-bar" would be connected to the ground pin of the Darlington array and "in" would be connected to an output pin of one of the GPIO chips.  However, when I prototyped it I found that, though "out-bar" goes low it doesn't go low enough, sitting at about 0.7 Volts, and this is not low enough to give the relay coils the 5 Volts they need to switch.  Instead I managed to find a Darlington array that actually has an enable-bar input, the MIC5801 from Micrel.  This left me with the problem of providing an enable for the external relays and for this I used a high-side MOSFET driver, the EL7212, and this circuit:

Circuit to provide an "enable" function for
            the off-PCB relays  Prototyping

...where "out-bar" provides the 5 Volt supply to the external relay blocks and "in" is connected to an output pin of one of my GPIO chips.  This worked most excellently, "out-bar" drooping to about 2.5 Volts with the relay blocks at full load without any ill effects on their operation.  Note that the value of the pull-up resistor is a little low, probably should be more like 10 k.

Finally, I decided to add something to detect when 12 Volts is present:

12V detect circuit

The LED lights up when 12 Volts is detected and this can also be connected to a GPIO pin that I can monitor.  So now I've committed to production of PCB revision 1.1.

On another note, I've been finding that the
1 mW XBee S1 802.15.4 boards tend to drop characters a little too often and so I've changed over to the 60 mW versions which are a lot more reliable indoors.

Slightly Scary Battery Incident
18 March 2014

I've been playing with the drive to the 4 channel and 2 channel 10 Amp relay boards, trying to get the pull-up resistors so that they drive the logic and obey TTL switching levels (meaning that I can read back the correct 1/0 from the device directly).  The logic inputs of the relay boards are of relatively low impedance, drawing slightly over a milliamp and making this difficult without overloading the littul PIO chips.  Anyway, while experimenting I left both 12V and battery power switched on to the Pi.  This has the side effect that 12V is applied to the battery connected to the Pi. I was lucky enough to hear the sizzling sound and wonder what it was.  This was the sizzler:

Sizzled battery

...and quite hot it was too.  I've now inserted a diode to stop this happening: drops me some volts but I have volts to spare.

Auto Off
16 March 2014

A side-effect of the Open Drain issue below is that when the data sheet says that an IO comes up "off", of course it actually means "undriven" which, for an open drain output means "pulled up to 5V" or, in other words, "on".   Hence when my IO devices come out of reset they switch on all the relays, which is not how I had intended things to work, and actually switches the Pi off again.  This, I have discovered, now that I have attached pull-up resistors to the IO chips. Darn.  I have a fix (but see above), which is to use a dual MOSFET (MC34152D) plus two pull-ups between the ground pin of the Darlington driver array and actual ground, effectively an "enable", which will keep the relays floating, only pulling them to ground when I'm good and ready.  The schematic and PCB in the github repository now reflect this design, though I'll be sure to prototype it before committing to a spin of the PCB.

Arch Linux
13 March 2014

Having got a little way into compiling with my cross-compiler on Windows and downloading to the Pi board as a target, I hit an issue where the C library on the Pi (glibc) is a rather old version, 2.13 compared with 2.18 which is pretty current.  Rather than trying to take everything backwards, at Ray Donnelly's suggestion, I've moved to Arch Linux.  This has taken a few days but it is a good move for two reasons:
  1. Arch Linux keeps things simple, no GUI guff that I don't need.
  2. Arch Linux doesn't peel off version numbers, it sticks with the very latest.
So that I know exactly what I've done I've recorded every step in a text file, pi.txt, which I've kept in the github repository above.

Open Drains And Random Numbers
5 March 2014

I've been able to write the drivers for the DS2408 IO chips now and have hit upon two issues.  The first is that all eight of the OneWire chips on the PCB are identified by their unique addreses on the OneWire bus but I've no way of knowing which is which, I just get back eight unique random numbers.  I need to write a procedure for this and possibly think about building something into the circuit to make it easier. The second, and more important one, is that I've realised that the outputs of the DS2408 are open drain.  This means that when you switch them on they drag the output to ground and when you switch them off they should float to VCC but, of course, you need a 10K pull-up resistor on each IO line to make them float.  Darn. Now this is not an immediate issue as I can introduce pull-up resistors in somethings through the cables themselves but it means I will have to re-spin the PCB to do a proper job of it.

It's Alive!
1 March 2014

The PCB is all wired in now and power is getting to the right places.  The first problem to investigate was that the Pi could see the OneWire driver chip but none of the OneWire devices attached to it.  It turned out that I'd accidentally connected the data line of one of the OneWire battery monitoring chips to ground.  Having fixed that the Pi could see seven of the eight OneWire devices.  That problem was that one of the OneWire IO chips didn't have its ground pin connected to anything (it looked like it was connected to the wrong place on the schematic but actually the end of the wire must have just been lying on top of the other wire, rather than being really connected to it).  A spot of track cutting and two bits of jumper wire later and all eight chips are visible.  I've also tried connecting the 12 V charging supply and that seems to cause the four charging circuit LEDs to do the right kinds of things. 

RoboOne assembled

28 February 2014

The PCB arrived today and beautiful it was too.  I took the afternoon off and immediately set about populating it.  The most difficult surface mount components were these:

The three-legged reset
The ESD protection
            diode, considerably smaller than a grain of rice

In less than three hours I was done.

The surface mount
            sideThe top of the PCB

The only mistake so far has been that the 2-way screw terminals were slightly larger than I had allowed for and the leads on the 0.05R resistors slightly thicker.  Some judicious work with a 1 mm drill did the trick though.  Tomorrow will be bring-up day.

Streaming Audio
27 February 2014

I've been like a kid waiting for Santa today, hoping that the post will bring the PCB from Ireland.  I can see the post van come but it hasn't delivered yet.

In the meantime, having got audio working, it occurred to me that I could stream audio to my robot.  I followed the instructions here: install gstreamer/gmrender on the Pi and, hey presto, RoboOne appears as a "Play To" option in Windows Media Player on the PC where my music is kept.  Magic.  Here's a little video of the robot, all wired up but with wires in the air and clips abounding 'cos it's sans PCB (a curled up bit of paper marking where the PCB will be), playing "I Spent My Last $10.00 (on Birth Control & Beer)" by 2 Nice Girls.

That PCB had better turn up tomorrow or it will be a very frustrating weekend.

26 February 2014

Having done all the cabling I can do without the PCB, and being otherwise bored while waiting for the PCB to be cut and put in the post (which happened yesterday), I decided to give the robot a pair of mouths (stereo) and an ear (mono).  I have purchased the smallest USB microphone I can find from eBay (USB being the only way to connect audio input to the Pi):

USB microphone

...a 3 Watt stereo power amplifier module based on the PAM8403 chip
(to which I have connected the Pi audio-out socket via a 3.5 mm stereo connector and cable that I happened to have lying around), also from eBay, pictured here strapped to the robot because the PCB was too small to add mounting holes:

3 Watt stereo

...and two 40 mm x 28 mm speakers from Maplin, pictured here attached to the robot with a bit of brass plate and some screws:

tiny 4 watt speaker

Though the speakers aren't imbued with much audio quality, they are fine for my purposes.

PCB Done
20 February 2014

Overnight PCB Pool has moved my board through the "exposing", "tin strip", "UV curing" and "surface finish" stages, which I think means it's completed so just has to be cut to size and put in the post now:

The finished PCB
The finished PCB

Mods To Pi/RIO And Orangutan Boards
19 February 2014

For the record, a few mods were made to the purchased boards.

On the RIO, a 9-pin DSub serial connector was soldered as follows to allow the positioning system to be calibrated from a PC (for which they supply software):

9-Pin DSub
1 (Gnd)
24 (Rx Data)
4 (Tx Data)

RIO calibration serial

On the Pi, a 0.1 inch pitch header was soldered to P6 to allow it to be reset by shorting the pins:

                  pins for the PI
                  pins for the PI

On the Orangutan, two header pins were added to the spare holes beside the power switch and, due to a lack of spare holes, the reset switch was removed and replaced with two header pins, all of this to allow remote power-on and reset of the Orangutan from the Pi.

                  pins for the Orangutan
Reset pins for the Orangutan, replacing the reset

PCB Manufacture
19 February 2014

The PCB Pool website is obviously a labour of love.  Not only does it use little traffic lights to tell you how your PCB is doing (mine has gone from "checking" to "production"), it tells you who is processing your order (Natanya Ogrin) and who is manufacturing your order (Luzuko Sonti), including a little picture of each of them.  Plus this morning it e-mailed me to say that there is now a picture of the layout artwork and the PCB in its first stage of manufacture, the drilling stage.

First PCB Pool picture of my
            PCB The drilled PCB

Very neat indeed.

The Base
17 February 2014

While the PCB is being made I've been thinking about the base.  So far I have purchased the following:

A JSP base (the heavy duty base) and pole, intended to form part of a cheap demarcation system, from Cromwell.
The base
                  for the base  Base for the
                  base with pole
A standard 200-position stepper motor from Hobbytronics (ultimately from Sparkfun).
Stepper motor for base
A 12 way 2 Amp slipring from Amazon (ultimately from Hossen in Hong Kong).
And finally, some electronics to tie it all together, consisting of:
                  electronics for the base

For the actual socket that will connect the base to the robot for charging, I'm currently thinking of a 1/4 inch audio jack but would prefer something a bit more robust; needs thought.  I need to consider how to put all these bits together.

In The Beginning
16 February 2014

My basic concept is to have generic wheeled robot communicating wirelessly but requiring no human control to carry on its functions.  A charging unit will supply current, the charging circuits themselves being mounted on the robot.  In order to avoid the need for too much trajectory control, the charging base will be able to rotate so as to meet the on-coming robot head-on. I will use electronic modules wherever possible to keep things simple.  All code will be written in C.

The first thing I found was that, since the last time I played with hobby electronics (in my teens), the world has grown ARMs.  Everything has an ARM in it, often two ARMs, and usually these are not accessible to me, performing local functions in each module.  Seems like overkill but hey, these modules are quite complex.

In terms of suppliers, Maplin (the only place that would sell components to consumers when I were a lad) are now a bit pants and places like Hobbytronics (extremely quick delivery) and Digikey (they have everything and have unbelievably quick delivery from the USA, though you wouldn't know they were in the USA unless you looked at their "contact us" page) are now the places to shop .  There are various other UK hobbyist sites for robotics, amongst them Active Robots and RoboTeq.  In terms of very, very useful module suppliers, there is Pololu, who sell the Wild Thumper and make numerous really useful things of their own, available from Hobbytronics in the UK.

Another thing I discovered, while looking for battery monitoring chips, was the wonderful Maxim OneWire interface.  This is a whole suite of chips that talk and power themselves over one wire plus ground, shorting the wire to ground for different lengths of time to signal a one or a zero.  They need very few additional components and come with a C library to drive them, ported to Linux, which is just right for the Raspberry Pi.

And a final thing - as a teenage hobbyist I recall there being nights of frustration where nothing quite worked and I'd not want to go to bed until I'd finished something, or I was frustrated by a lack of knowledge/help.  No more - the interweb has fixed all that.  Knowledge and advice is always at hand from anywhere, anytime you need it.  Quite a different experience.

So, having thought for a while, I bought the following:

Dagu Wild Thumper 6WD All-Terrain Chassis, Black, 75:1 from Pololu in the USA.
Dagu Wild Thumper chassisDagu Wild
                  Thumper chassis underside
Orangutan X2 controller with VNH2 motor drivers plus LCD display, also from Pololu in the USA (note: the VNH2 has current sensing that can be employed to protect the motors while the VNH3 does not).  This will be the main control unit for the motors and the IR sensor, communicating with the Pi via USB.  Rather pleasingly I was able to run Free RTOS in its 16 kbytes of data and 64 kbytes of code space.  The LCD is only really required for diagnostics.
Orangutan X2 controller    LCD for Orangutan X2
A Pololu IR Beacon transceiver pair.  These will form a simple, directional, means of allowing the robot to sense the base and vice-versa.
                  IR Beacon
Raspberry Pi development kit from Maplin, a camera to go with it from Amazon, plus a RIO AHRS gyroscope/accellerometer/magnetometer board from Roboteq mounted on top of the Pi.  I wanted the RIO AHRS for its attitude control capabilities and because it can power the Pi from a battery supply.  It is meant to also provide I/O via that weird grey CAN bus connector on the right which I found to be so much of a pain (oh for the simple 0.1 inch pitch header that everyone else uses) that I decided to add my own I/O instead using OneWire chips.  And the RIO uses up the Pi serial port for its own control/calibration purposes.  So on reflection this might not have been the wisest way to gain attitude control and it would have been better to look at the Pololu options here.
Pi with RIO AHRS on top of it
An NZXT USB expansion board from Amazon.  These are intended for use inside PCs but incidentally provide a really neat way to get eight USB ports from two, with separately supplied power.  Each one of those rows of four (or five, the fifth being shield ground which can be ignored) pins are a complete USB port, despite the numbering. Note that seven of the ports are connected to one of the USB inputs and the last one is connected to the other, so you do need to connect both of the USB inputs (on the left of the PCB in the picture) to both of the USB ports on the Pi to get eight separately powered USB ports.
NZXT USB expansion board
Two 1 mW XBee S1 802.15.4 boards with antennas plus two XBee Explorer USB adapters from Roboteq (but see above).  These can be a bit temperamental, especially after running a software update on them, so it is advisable to solder two pieces of wire to one of the USB adapters so that the device can be reset during configuration and/or programming (see good advice here).  I run them at 33.8 kbits/s which works fine for a telnet interface, though there will be dropped characters. In case you're wondering, Wifi does work with the Pi but is known to be flaky so I'd prefer to have another method of control access, leaving Wifi for streamed video from the camera.
XBee module mounted on USB adapter
A PL2303 USB to TTL-level serial board (which is known to be supported by the Raspberry Pi) from Amazon to give me back the serial port that the RIO AHRS took away.
PL2303 USB to serial (TTL level)
Having decided to use four 6-cell NiMH battery packs, one to power the Pi/RIO and three to power the Orangutan driver board and hence the motors, I purchased four 7.2V NiMH charger modules from BatterySpace in the USA (warning: delivery is very costly, in the end I used a friend in the states to purchase them locally and then have them shipped more cheaply to the UK).  To these I soldered sensible connectors, taking out the status LED to do so.  The LED will be attached again on my own PCB that is intended to monitor the charge state of each battery.
7.2V NiMH charger moduleCharge
                  module with connectorsThe four
A selection of relays; one 4 channel and one 2 channel 10 Amp relay board (that can be driven by 5 Volt TTL) from Hobbytronics, two 5 Volt 3 Amp SPDT PCB mounting relays and three 5 Volt SPST reed relays from Maplin.  The (six) 10 Amp relays will be used to switch the charge current to the four batteries and external or internal battery power to the Orangutan; they will be driven directly from some OneWire IO chips.  The two 5 Volt 3 Amp SPDT relays will switch external or internal battery power to the Pi/RIO and the three SPST reed relays will allow control of power/reset to the Orangutan and reset to the Pi; these will be driven via a Schottky array from the same OneWire I/O chips.
2 channel 10 Amp relay4 channel 10
                  Amp relay5 Volt 2 Amp
                  SPDTrelay5V SPST reed relay
A really neat, tiny, 5 Volt step-down voltage regulator, D15V35F5S3 by Pololu and available from Hobbytronics. I had originally intended to get my 5 Volt supply from the RIO but decided to go this way instead to avoid the hateful connector.
                  Volt step-down voltage regulator

In addition to the above I purchased the following OneWire chips (all surface mount):
And, of course, various other bits and bobs, including:
My original intention was to mount my relays etc. onto Vero board but I quickly realised that the number of components and the complexity of the wiring would make that really difficult in the space I had available (90 mm x 100 mm) once everything else was mounted on the robot.  Thankfully I had lost my fear of soldering surface mount components (just buy a very fine tipped iron, some 0.3 mm diameter solder, some "helping hands" (do a Google search) and be careful) so I decide to go for my own PCB.  I downloaded DipTrace, which I heartily recommend.  Really easy to use and free for the hobbyist who needs up to 300 pins; my schematic needed 295.  Here it is:


The PCB is double sided and I've just sent off the file for manufacture to PCB Pool in Ireland, having worked out that the cost of having them do it is one quarter to one third that of purchasing all my own etching kit; and in any case, the board is double sided and rather complex.

The overall wiring of all of the components above is as follows:

Wiring diagram

Software-wise I am writing in C as that is commonly available for the Orangutan controller and the Pi.

For the Orangutan I am using AtmelStudio 6 (the IDE) with WinAVR (the compilation tools) and Pololu's own C libraries, all as recommended by Pololu.  AtmelStudio is a really nice IDE "powered by" Visual Studio.  As I am used to using an RTOS and wanted the robot to be able to multi-task sensibly I have used Free RTOS, a really simple RTOS which has already been configured for the Atmel AVR ATmega processor used on the Orangutan (as this happens to be used on Arduino's as well) by feilipu.  I am only really using the configuration file from the port but it has helped a lot.  The whole thing is running, with my program as far as I have taken it so far, in 16 kybtes of my 64 kbytes code space and 14 kbytes (including the memory pools) of my 16 k bytes data space.  Very neat.

For the Pi, I have decided that I need to compile on the PC to save time and am using something called crosstool-ng to do that.  Ray Donnelly, who is active on the crosstool-ng development, has provided me with a crosstool-ng configuration that works for the Pi and can be built using MSYS2 (a bit like cygwin but more focussed on just the Linux build actions running on the PC).  Crosstool-ng builds GCC on the PC with the Linux of the Pi as the target.  It takes a few hours to do this but you only do it once (or whenever you switch GCC versions).  The crosstool-ng Pi configuration is in beta at the moment but should hit the crosstol-ng distribution proper very soon now.  I am using Eclipse as my IDE because I'm used to it but everything is built with makefiles.  Maxim provide the OneWire C code ported to Linux and the DS2480B serial driver chip here (pick out Linux and "userial" from the list).

I transmit files to the Pi, and the Orangutan via the Pi, using teraterm, an old scriptable terminal package, recently revived it would seem, that still supports good 'ol zmodem.  This way I can do everything over the XBee interface that appears as a lazy, slow, USB-to-serial port on the PC.  Otherwise I talk to the Pi using PuTTY.

Back to Meades Family Homepage