Computing stuff tied to the physical world

Archive for June 2009

JeePlugs have arrived

In Hardware on Jun 30, 2009 at 00:01

Got some JeePlugs in today – yippie!

Here’s how I’ll probably use them most often – with one or two sideways headers:


(These boards were sent off before the big URL rename – such is life…)

Note that both ends and the middle rows are connected in a pairwise fashion. The middle row traces are thin and can easily be cut if necessary.

I used flat headers, soldered in the underside of the plug. That way you can chain them and they’ll hold the plug slightly above the plane for pins sticking out, etc.

Here’s one way to use them on a JeeNode:


The blue is the new green – all boards from JeeLabs will be blue with white markings.

Note the orientation here: in this setup, components are mounted on the outside.

And here’s another way to use the plugs, as mini shields:


The headers are soldered onto the inner rows, leaving the connections to each header pin available from both sides on the outer rows.

There’s nothing JeeNode-specific about these boards, by the way. They have plated through holes, which makes them more convenient for soldering components and wires on either side. And the pairwise pad connections can save a bit on wires.

Breadboard limits

In AVR, Hardware on Jun 29, 2009 at 00:01

Here’s something which isn’t a good idea with breadboards:

Breadboard limits

I used a socket with wire-wrap pins to be able to connect a few wires yet still be able to use the whole thing in a breadboard. If you look closely, you can see that the 5-pin metallic connectors inside the breadboard are pushed out – making the adhesive separate from the rest. Whoops.

Wire-wrap pins are clearly too thick to be pushing into breadboards…

Arduino Mega + shield

In AVR, Hardware on Jun 28, 2009 at 00:01

Got myself an Arduino Mega – an Arduino on steroids:

Arduino Mega + shield

Compatible with current Arduino shields, but extended to support a lot more pins.

Ordered it from NKCelectronics, along with their new extended shield for it:

Arduino Mega + shield

There’s a lot of them pins on there…

I decided to attach a solder-less breadboard to it, to be able to experiment with projects which need more I/O lines or comms than a standard Arduino:

Arduino Mega + shield

It fits, but just barely. Had to cut off the little hooks on the plastic. Using a breadboard in this way covers up all the identifying pin texts on the silkscreen, alas.

Actually, it doesn’t quite fit – couldn’t get all headers on:

Arduino Mega + shield

I’m using a mix of 4- and 6-pin headers, since I had them lying around. As you can see, the last 4-pin header makes it impossible to fit that other header in, so I left off pins 22 and 24. It might have worked with an 8-pin header i.s.o. 2x 4-pin.

And here’s the final “stack”:

Arduino Mega + shield

Conclusion so far? I’m not sure this is the way to go. I think it’s an abomination, to be honest. There are so many pins to connect that the two boards are very hard to separate once stacked up. You don’t want to pull too hard on one side and end up with bent pins when the thing finally comes apart.

And how often do you need that many I/O pins one one fixed board setup? Sure, the ATmega1280 has 128 Kb of flash memory, which is plenty to get fairly complex sketches going. But it also builds on that trend of using stacked shields – and let’s face it: a single shield is often great, but with 2 or 3 you end up with pin allocation nightmares (for designers) or conflicts (for users). Multi-stacking is tricky, requiring special stacking headers.

Nah, I’d much rather go with ports, and extensions for that, and connecting two or three independent units over a bus if need be. But then of course I would, that’s why I went for such an approach with JeeNodes after all.

New Jee Labs forums

In News on Jun 27, 2009 at 00:01

Right on the heels of yesterday’s shop announcement, I’ve now also set up a site for discussion about everything related to the Jee Labs:

Again, a very basic design with with only a limited set of features in the form of a new bulletin board called bbPress – from the makers of WordPress:

Picture 3.png

If this turns out to be a convenient and effective setting for discussions, I will remove the jeelabs mailing list at Google Groups again. With apologies to everyone who already signed up there.

To summarize, there are now three different sites for the Jee Labs, using the new domain names:

So much for the world domination side of things – now I can put on my lab coat again and get on with it.

New Jee Labs shop

In News on Jun 26, 2009 at 00:01

I’ve set up a web shop to simplify getting JeeNode kits – and whatever else comes out of Jee Labs – to those of you who are interested. The shop has its own web site:

It’s a basic design, because this is not about trying to become the next Amazon. Or acting like it. Or trying to “project a corporate image”. I’ll leave that to others.

Nah, the JLS is just a an easy-to-use shopping cart setup for dealing with PayPal and bank transfers:

Picture 3.png

No muss, no fuss. I hope you like it.

Note that there’s a Product News page in the shop, which is a blog I’ll use to announce the “availability of new products”. I won’t clutter this daily weblog with that sort of sales/marketing drivel. To track both types of news, simply subscribe to both blogs.

JeePlugs are on their way

In Hardware on Jun 25, 2009 at 00:01

Ok, I’ve decided to get a bunch of JeePlugs made.

A JeePlug is a little prototype board designed to fit exactly on one or two port headers of a JeeNode (or JeeLink). Here’s the layout:

Picture 6.png

See an earlier post for a description of how these plugs can be fitted to the JeeNode / JeeLink.

Some of the holes are connected in a pairwise fashion. With traces which can be cut when such a connection is not desired. The outermost two rows are for header pins and wires to connect to each pin, respectively.

The main intended use for these plugs is as a mini-breadboard hanging off the side of the JeeNode, so that up to four of these can be attached at the same time. But sometimes a single AIO + DIO pin just isn’t enough, in which case these plugs can be used as mini-shields bridging across two opposite ports.

It’s pretty low-tech obviously, but I expect these plugs to be a huge time-saver. Not just because they make it easy to hook up all sorts of sensors, indicators, and actuators, but because the result really is a plug. They can be mixed and matched at will, since all ports are equivalent. All that’s needed is to adjust the port number in the sketch / code to match the chosen header, a trivial 1-line change.

And because ports are so versatile, each plug can be an analog + digital I/O line, or an I2C bus, or a serial line. There are definitely limits to this approach, given that a JeeNode is after all based on a micro-controller, not a full-blown PC – but still.

Being flexible, modular, and inexpensive – that’s what JeeNode ports are really about. Oh yes… and wireless :)

I hope to get various plug examples going in the Jee Labs in the months ahead.

Meet the JeeLink

In AVR, Hardware on Jun 24, 2009 at 00:01

I’m proud to announce a new board next to the JeeNode, called the JeeLink. Yes, there’s a pattern in the naming choices made for products on this site.

The JeeLink is very much like a JeeNode, but in the format of a USB stick and with a few small differences listed below. Here’s the layout:

Picture 2.png

As you can see, the JeeLink has basically the same headers as the JeeNode, but with a USB plug in the place of the JeeNode’s FTDI connector.

The JeeLink is useful in two different ways, I think: first of all, if you have a couple of remote JeeNodes, you’ll probably need a central node as well to tie the whole network to a personal computer. The second use case is that it can be used as a JeeNode with built-in FTDI-to-USB conversion – which is exactly what it is, technically speaking.

A major difference with the JeeNode also, is that the JeeLink is built with SMD parts. The intention is to make it available in pre-assembled form and as bare board. No kits with parts – that’s reserved for the JeeNode since I don’t want to stretch myself too thin.

There will be a more detailed description of the JeeLink once it is ready and working, but here’s a first overview:

  • the dimensions of a JeeLink are slightly different, obviously
  • the I2C and SPI/ISP headers are not in exactly the same position as on the JeeNode
  • there’s no battery connector (who needs one with USB?)
  • the FTDI-type USB connection includes two on-board activity leds

So there you have it – a new descendant in the Jee family. With on-board RFM12B wireless radio of course, and 4 ports to connect absolutely anything you like to. Just like the JeeNode.

The JeeLink is the initiative of – and was designed in collaboration with – Paul Badger of Modern Device. We’ve been having a heck of a time together, hammering out all the details and making sure the result will be as good as we can possible make such a new concept. I’m proud of the result, and hope you’ll like it as well. Should have properly working JeeLinks in my hands in July, assuming Mr. Murphy doesn’t barge in to spoil the party.

New name and new domain name

In News on Jun 23, 2009 at 00:01

I’ve decided to switch to a real top-level internet domain name for this weblog, and am moving this entire site over to its new location:

Did you notice the extra “s”? Did ya? Did ya?

Actually, the weblog home is at to be pedantically precise – but you can pick whichever URL you prefer, since you’ll automatically be redirected to the right place. Both names have been permanently tied together – inasmuch as permanent means anything on internet, that is.

The “” URL (no “s”, see?) will continue to work as a redirect to the new location, at least for a while so everyone can gradually adjust all bookmarks.

This change will be instant because it’s entirely virtual. This is merely a naming issue.

I’ve also adjusted the name of this blog. The “Jee Labs” plural form feels right for various reasons. Several people were in fact referring to this weblog in that way already.

More JeeNode v3 changes

In Hardware, News on Jun 22, 2009 at 00:01

Here are a few more details about the upcoming JeeNode v3 board.

First off, I said no more changes w.r.t. the pinout. Not true – the I2C/PWR pinout has also changed:


For a couple of reasons which I don’t want to go into just yet. The GND pin is now on the outside, just as on the FTDI header. Note that PWR is the incoming voltage, not the regulated 3.3V at which the ATmega operates (including those SDA / SCL pins).

The other change worth mentioning here, is that components have been rearranged slightly to make room for 2 pads to connect a battery or battery pack – along with holes for strain relief. Both leads are clearly marked “+” and “-” to avoid polarity mistakes.

The JeeNode is well suited for battery use due to it’s 3.3V design and because it has no on-board LEDs. The regulator lets you choose from a huge range of battery options (hence the soldering pads i.s.o. a fixed battery choice): 3x or 4x AAA or AA, NiMH or Alkaline, or one of the increasingly popular 3.6 .. 4.1 V Lithium batteries, which are great as long as you take care not to short-circuit them and not to discharge them beyond their advised limits.

So there you have it. The new JeeNode v3 board is just about ready to send off to manufacturing. I hope to get my hands on them early July.

More SMD stuff

In AVR, Hardware on Jun 21, 2009 at 00:01

My adventures in SMD miniaturization-land continue:

SOIC chips

Those are two Atmel chips – an ATtiny85 (SOIC-8) and an ATtiny84 (SOIC-14).

Compared to 0603 parts, these are actually quite large. The distance between the pins is 1.27mm (0.05″), half of regular through-hole parts.

But you do need fine tweezers, and a ZIF socket to flash them or try them out without soldering is also nice:

SOIC chips

The lid snaps down, making a firm connection with each of the 14 pins.

Hm, I see now that the SOIC-8 dimensions are a bit wider than the SOIC-14 package. So the smaller package doesn’t fit in this (pricey) ZIF socket.

So not only is this stuff small – it’s also easy to overlook such differences!

Fortunately there are datasheets.

JeeNode v3 pinout

In Hardware, News on Jun 20, 2009 at 00:01

There are two important pinout changes in the upcoming JeeNode v3:

  • On all four ports, pins 4 and 5 will be swapped (AIO and +3V)
  • Pins 1 and 2 of the SPI/ISP header will become pins 7 and 8

So the final pinout for ports is:

Preview of “jeenode-v3.graffle”.png

The change isn’t being made on a whim – I’ve got several things plugging into ports here which will need to be changed to work with the new pinout. And it will affect everything plugged in for years to come. One of the reasons for the change is that it lets you plug in a 3-wire servo (pins 3..5). Another reason is that it is compatible with the BBB board already out there (also pins 3..5).

As before, a 4-pin connector on pins 2..5 is often all you need. The outer two pins are for more advanced uses.

As before also, pin 1 carries the input voltage to power the board, and can be anything from 3.5V to 13V. With an FTDI connector it will usually +5V. Batteries work great, anything from a 9V block, or 3x AAA/AA (both NiMH and alkaline), or even a LiPo battery.

Note also a small change in pin names: the 3.3V regulated power supply is now called “+3V” instead of the somewhat ambiguous “VCC”, and the interrupt line is called “IRQ” instead (was INT).

Every future JeeNode design will use this pinout on every port.

The new SPI/ISP header is (pin 1 at top left):


This is an “extended” ISP header. The main reason for this change is that pins 1..6 are now compatible with a standard 6-pin in-system programming connector, through which the ATmega’s fuses, flash, and EEPROM can be programmed. Note that the JeeNode is a 3.3V device, it should not be driven by an ISP programmer set to 5V voltage level.

The two extra pins are tied to digital I/O lines B0 and B1, and allow connecting more SPI devices to the JeeNode. Note that SPI is used internally by the RFM12B radio module, so these pins should not be re-configured for other purposes, although you could use SEL0 and SEL1 as general-purpose I/O lines if you want – a LED and a push-button switch perhaps.

I’ve made a few experimental add-ons using the SPI/ISP connector, such as this one. They will need to be adjusted for v3, but as with ports the same new pinout will be used for all future JeeNodes and derivatives from now on. Although some of them might not have such a connector at all.

That’s it – no more changes. Now I can “standardize” everything I want to connect to the JeeNode ports!

What a waste

In Uncategorized on Jun 19, 2009 at 00:01

What a waste… this box arrived today:


Stuffed with lots of brown paper.

And the contents was that single item laid out in front: a 15 ml resin flux pen!

Flammable, sure. But does it really have to be delivered that way? As a separate shipment and delivery? And by UPS, those huge brown trucks – always the largest delivery vehicles coming here.

Does that make me a major carbon emitter, energy waster, and polluter? I guess in a way it does :(

Don't sneeze

In Hardware on Jun 18, 2009 at 00:01

Ok, so this is what 0603 SMT parts look like:

Don't sneeze

That’s a 0.1 µF capacitor and a 10 kΩ resistor.

Trouble is, they are small

Don't sneeze

The “0603” part designation for SMD’s stands for 0.06″ x 0.03″ (roughly), which is 1.6 x 0.8 mm. Here’s a good overview, from that same SMT page on Wikipedia:


Well, it sure is something new for me to try out such miniature components!

Fortunately, that’s as small as it gets (I’ll leave 0402 components to the industrial parts-placement machines). Other capacitors (3216), voltage regulators (SOT23), and microcontrollers (SOIC) are all a bit larger.

JeeNode headers

In AVR on Jun 17, 2009 at 00:01

More details about how to connect stuff to any of the four “ports” of a JeeNode. Each port has this pinout:

A few notes:

  • the DIO pin is for digital I/O only, the AIO pin can be for analog in or for digital I/O
  • a port has six pins, with both 3.3V (VCC) regulated and +V (PWR) unregulated power
  • with just a 4-pin header on pins 2..5, you still get the most important pins
  • if all you need is a single I/O line, you could even use a 2-pin header on pins 3..4
  • the IRQ signal is shared between all ports

Another thing to note is that the ports all have an identical pin-out, when looking from the outside of the board:

(the above two diagrams are from the JeeNode v2 PDF documentation)

And then there is the aspect of distances between the port headers:


This is where the story gets a bit fuzzier:

  • JeeNode v1 uses A and B as distance between the port headers
  • JeeNode v2 and v3 use A and D as distance between the port headers

If you want your plugs to remain usable on all future JeeNode designs, then you will need to make sure that they can deal with separations between the headers as small as C and E.

I’m not saying there will be such JeeNodes any day soon, I just want to keep the option open to go there.

Prototyping with JeeNodes

In AVR, Hardware on Jun 16, 2009 at 00:01

Here’s a little board I used for a while with a JeeNode:

Pulse prototype

It has 6 female header underneath, which get plugged into a JeeNode with its header pins sticking upwards. It has an LDR, a diode I tried to use as voltage reference, a plugged-in SHT11 temperature / humidity sensor, a 3-pin connector to plug in a Parallax PIR sensor, and a 2-pin header (top right, behind the SHT11) which was used to connect a couple of 1-wire temperature sensors).

There are a couple of issues with this, though some are probably unavoidable for such one-off / ad-hoc solutions. For one: it’s a bit of a mess. One reason is that with this setup the 1-sided perf-board I used has to be mounted upside down to allow soldering in the female headers. That’s awkward, because it means you have to “surface mount” most components.

One option is to use perf-boards with plated-through holes. These are several times more expensive than single-sided boards, though. But more importantly, cheap one-sided boards are often based on “Pertinax” (SRBP) which is a lot easier to handle than FR-4 epoxy: you can simply break them on a sharp edge, with the row of holes acting as perforation.

The other problem with putting everything on a single board is reduced flexibility. In this case I had to add a second 4-pin female header on top to accommodate the SHT11 plug I had already made – which would have fitted just as well directly on the JeeNode.

One nice benefit of per-port prototyping is that it is easy to re-use this stuff in different configurations. In fact, as with the SHT11 plug showing in the picture, that’s precisely what happened.

So I’ve been thinking a bit about ways to use JeeNodes for experimentation. Which happens a lot around here. One simplifying convention is to always use male headers on the JeeNode. That leaves essentially two choices (ignoring sideways mounting for now):

Picture 1.png

I’m thinking of having a bunch of, ehm, “JeePlugs” made: tiny boards with a 6×8 “prototype” area containing plated-through holes, plus a 6-pin female header and connecting pads. Three ways to use these:

Picture 2.png

You’ll need male headers for use with a breadboard, but I’m assuming you’ve used the breadboard to figure out the connections with the bare parts, so this post focuses on using female headers for the JeePlugs.

In all cases, the orientation of the pins is the same, so once you have a plug set up with stuff on it, you could still use it in multiple ways. And plug them onto any of the 4 ports at will, of course.

One last refinement is to make these plugs around 20 x 25 mm – i.e. long enough to optionally plug onto two ports in that inverted 3rd example shown above. Here’s a first design:

Picture 3.png

It’s really not much more than a tiny perf-board of the proper size for JeeNodes with a couple of doubled-up connections. Using plated-through holes so components and wires can easily be soldered from either side.

The plugs are not labeled with pin numbers or signal names, because those depend on the orientation in which you use them. For that, use the markings on the JeeNode itself (starting with v3, that is).

These JeePlugs only makes sense in larger quantities, so I haven’t yet decided whether I really want to order them. I sure could use some, but it wouldn’t be practical to have less than a hundred or so of them produced.

Reflow experimentation

In Hardware on Jun 15, 2009 at 00:01

Got this little skillet/grill thing recently:

Heating plate

Quite a convenient size (and it can be stored upright) – the usable area is around 25 cm diagonal. It’s also relatively weak at 700 Watt, but since it’s so small it still easily reaches the solder melting point within a few minutes (with the lid closed).

I’ll be experimenting with this thing for SMD reflow soldering. Will need to measure and control the temperature (an NTC resistor rated for 300° no doubt, but I don’t know which type yet).

If the heat collection in these plates makes the thing too slow to control properly, I could take the plates out and use some sort of grid instead:

Heating plate

Note the heat sensor in the middle, triggering a thermostatic switch.

Ideally – of course – I’d want to control this thing with a JeeNode, but I’m not willing to spend very much time on that right now. We’ll see. First thing will be to measure the temperature ramp-up/-down behavior of this thing, with the lid open and closed.

If this works, it’s a pretty good deal for €19.95 !

New JeeNode v3 design

In AVR, Hardware on Jun 14, 2009 at 00:01

Here’s an – improved! – board design for the JeeNode:

Picture 1.png

The main two changes are: labeling of all the components and pins, and a change in the ISP/SPI pin header (pin 1 is now also pin 1 for ISP). All connectors are in exactly the same place, but the board is a tiny fraction wider.

For details, see the EAGLE files (jee-pcb-011.sch and jee-pcb-011.brd). The PDF of the schematic shows that the functionality is unchanged – other than the ISP/SPI header pinout change, this board should be 100% compatible with the JeeNode v2.

The v3 board was designed in collaboration with Paul Badger of Modern Device, to whom I’m most grateful.

I’ve just ordered a batch of these boards. Should be able to report here in ten days or so as to whether they are working properly. Let’s hope so!

Bad things happen

In Hardware on Jun 13, 2009 at 00:01

Looks like one of the sensors broke:

Broken sensor

That’s an IMU (Inertial Measurement Unit) with a dual accelerometer and a gyroscope. The gyro is the “big” one on the right. It senses rotation around the Z axis perpendicular to the board. The accelerometers are working fine, but the gyro appears to be toast. No matter what I try, it produces a noisy but fixed analog voltage. Connecting either of the self-test pins doesn’t doing anything.

Ouch, the gyro is also the most expensive part (in the €25..50 range). And this was a rather nice and sensitive one. Oh, well…

(that’s an Arduino with a battery pack by LiquidWare underneath, btw – so I can move this thing around and hook up the scope without having to attach power)

Ancient technology

In Hardware on Jun 12, 2009 at 00:01

This is fun. For one of my numerous projects, I wanted to resurrect a 15 year old LaserPrinter which has been gathering dust for a while:

Ancient technology

A “state of the art” 600 DPI PostScript laser printer for the Mac. With a whopping 6 MB RAM and LocalTalk / RS-232 / Parallel interfaces. Those were the days.

Plugging it in and running a self-test from the menu was all it took:

Ancient technology

As you can perhaps guess from the Dutch report in the bottom left, it has printed a mere 8050 pages in its lifetime so far.

Yeah. Back then, they knew how to make things. You just turn it on and it works. That toner cartridge must be at least 10-years old, btw!

Got some ideas about hooking up a JeeNode to this thing, probably via the serial port. The printer draws a lot of power and does not really have a standby mode, so the RFM12B could be used to control a remote KAKU power switch, for example. We’ll see…

JeeNode v2 kit notes

In AVR, Hardware on Jun 11, 2009 at 00:01

Just to make sure I didn’t forget anything – here’s the contents of a JeeNode v2 kit with parts:

JeeNode kit contents

For those of you who are about to receive the kits: they should match what’s shown above. If I forgot anything please let me know and I’ll take care of it right away.

The ATmega168 is pre-flashed with the standard Arduino boot loader and the RF12demo sketch.

As for assembling these kits, the main thing to keep in mind is the orientation of a few components and the ways things should be hooked up – see the recent post and the reference doc and close-ups on this site such as this one:

JeeNode v2

These are first-generation boards without silkscreen (I’m still learning about all this PCB design stuff!), although there are tiny markings on the top copper layer if you look really closely.

One important detail I forgot about is the antenna: for these 868 MHz units, I use a piece of 85 mm insulated wire. It needs to be connected to the ANT pin, which is the one in the corner as you can see in the above picture. You need an antenna, I’ve not been able to bridge even the shortest distance without one.

A tale of stand-alone builds

In AVR, Software on Jun 10, 2009 at 00:01

The JeeBot Duo runs off a Baby Orangutan controller by Pololu, which isn’t entirely compatible with the Arduino IDE. Well, it can be made to work with it but in this case it looks like just using avr-gcc and avrdude directly from a Makefile would be just as simple.

Boy, was I wrong.

I’ve spent nearly two days trying to understand why this thing wasn’t working. Or rather, it was. Sometimes. But with resets all the time, and the watchdog being tripped even though I never enabled it.

One problem is that the BOC has no other signaling on board than a single LED. So first thing was to set up serial communication. Well, that worked. But then it didn’t. And then things got really totally erratic…

The problem turned out to be in the highlighted portion of this Makefile:

Picture 2.png

Without the $(CFLAGS) on the linker line, everything   s o r t   o f   works.

Until you start using RAM for data, such as statics/externals and strings. Or C++ classes inside the Pololu libraries for example.

Then the system goes berzerk. Because the linker wrongly assumes that RAM starts at 0x0060. So strings and data variables end up being written into the extended I/O area. Want to know what’s at address 0x0060? The watchdog control register.

Anyway. It took me many hours of complete despair to figure this one out. Salvation came from “avr-objdump -h”, which clearly showed that the “.data” segment was in the wrong place compared to an Arduino sketch. With many thanks to Ben @ Pololu for nudging me towards the solution and for patiently responding to my emails, some of which must have been pretty weird…

I think that what baffled me most of all was the fact that the simplest bits of code worked just fine. You can get a lot of little tests going without ever using strings or allocating static variables. And the failures being random resets (from the watchdog) kept me looking for hardware problems – silly me.

At one point, I had figured out the incorrect starting RAM address and added this linker option: “-Wl,-Tdata,0x800100”. Unsure why it had to be specified but it got past the most erratic behavior.

But then interrupts wouldn’t work. Disassembly (with “avr-objdump -D”) showed that the generated code was using an incorrect set of vectors. And then it dawned on me: the $(CFLAGS) includes “-mmcu=atmega328p” which the linker needs to put things in the right place and to use the right vectors.

Doh. Totally obvious in hindsight.

Now I can finally generate and upload code without having to go through the Arduino IDE.

Building the JeeNode

In AVR, Hardware on Jun 9, 2009 at 00:01

Now that a few people have started building JeeNodes for themselves, here’s a close-up:

MCP1702 detail

Make sure you put that MCP1702 voltage regulator in exactly as shown. That’s the TO-92 package in the middle.

The board was intially designed for an LP2950, which has a different pinout. The MCP1702 does not have ground in the middle, hence the twisted positioning.

Note also how I use flat 6-pin headers, even for the FTDI connector. All the header pads are large enough to solder them on in any orientation you like.

FWIW, I’ve still got 9 JeeNode boards left (and probably all the parts needed as well). So if you want ’em let me know. I can send bare PCBs for €5 each. Or the PCB with all parts including 868 MHz radio and pre-flashed ATmega168 for €17.50. Shipping included if you order more than one.

JeeBot Duo schematic

In AVR, Hardware on Jun 8, 2009 at 00:01

Heh – my most “sophisticated” robot so far. Here’s the plan for the electrical hookup of the JeeBot Duo:

Picture 1.png

There’s quite a bit of functionality in there, all the way to an on-board LiPo battery charger. Other things to note: the Baby Orangutan controller (BOC) can shutdown all power (to avoid running down the battery too far) and the JeeNode can reset the BOC if need be.

The two processors communicate with each other via an I2C bus. The on-board FTDI header connects to the BOC serial port and supplies power to the LiPo charger. The FTDI header on the JeeNode can be used for monitoring, control, and uploading, as usual.

JeeBot Duo – in progress

In AVR, Hardware on Jun 7, 2009 at 00:01

To continue this bot-craze, here’s another design, the JeeBot Duo

More JeeBots in progress

This design is considerably more advanced. From left to right:

  • two 50:1 micro motors with wheels and encoders (Pololu)
  • a 6-pin FTDI header
  • the Baby Orangutan 328 motor controller (Pololu)
  • underneath: a low-voltage boost regulator (Pololu)
  • at a 45° angle: IMU board with 2-axis accelerometer and gyro (SparkFun)
  • a JeeNode v2 with on-board RFM12B 868 MHz radio module
  • underneath: a 860 mAh LiPo battery

It’s called a JeeBot Duo because there are two processors on board. The plan is to put the self-balancing smarts in the Baby Orangutan – which has all the hardware needed to connect to all sensors and motors. The JeeNode is available for telemetry, remote control, and perhaps to connect to further gimmicks later on.

Initial tests show that the motors have plenty of speed and torque, and draw 40 .. 300 mA each, depending on load. The boost regulator can produce a constant 5.4 V for the motors, while the battery level gradually decreases. There’s a tiny bit of slack in the gears, which translates to about 1 mm of slack/travel on the wheels.

The remaining space is for a compass module and an on-off switch. That makes this a relatively complete autonomous unit, able to sense its vertical position and change, as well as the distance traveled and the compass heading. With the proper software, it should one day be able to respond to commands such as “go 2 meter north”, or “drive around in a 1-meter circle”.

But that’s a long way off. Lots of tuning and software development will be needed to get there…

JeeBot Mini – in progress

In AVR, Hardware on Jun 6, 2009 at 00:01

Here’s a second design, called the JeeBot Mini – no less:

More JeeBots in progress

The first JeeBot used servo’s but that’s not really such a great fit for self-balancing. This one uses miniature (and pretty weak) motors, directly driven by the ATmega’s I/O pins. The small socket is for the same Memsic 2125 accelerometer as on the original JeeBot, but placed at a 45° angle to use both X and Y axis together.

On the right is a tiny 100 mAh LiPo battery – plenty for simple trials. No gyro, no regulator, and no resonator (so far). No JeeNode either – just a serial FTDI interface and a bare ATmega168 chip running the LilyPad bootstrap @ 8 Mhz, straight off 3.7 V from the battery.

I’m waiting for some wheels for this thing. Am not sure the wheels will turn fast enough to regain balance once detected. If not, maybe raising the center of gravity by extending the “chassis” upwards will help. Or bigger wheels. Or both. Or maybe the design choices are hopelessly wrong already… we’ll see.

Reliable RF12 communication

In Software on Jun 5, 2009 at 00:01

I’m currently adding a reliable communications option to the RF12 driver. This will deal with two important communication errors: lost packets (the receiver did not get the packet) and lost acknowledgements (the sender doesn’t know the packet has arrived). Both involve timers and re-transmissions, something which the current driver doesn’t provide for.

The current driver API is not affected, these changes only add functions. Here is how they should be called:

Picture 3.png

There are two parts, reception and transmission. Reception occurs at unpredictable times, which is why rf12_recvDone() has to be called fairly often. It’s very quick when there is nothing to do, so calling it inside loops is ok and cheap. The receiver code also handles all acknowledgements and other events, so it must be called even if you only intend to send data out. Also, you must always end with a call to rf12_sendReply() when accepting the data, even if the reply is empty.

Transmission can be started by you whenever you want, but you can’t flood the driver with sends, you have to wait until it has finished the previous one. This is why there is a check on “rf12_todo”. If it is ≥ 0, you have to either wait and re-check until it becomes negative, or give up this send and try sending new data later on. Note that sends can slow down indefinitely, for example when the receiver is out of range or even turned off completely.

There is a lot to say about how to design your communications structure, all way beyond the scope of this post. It becomes considerably simpler if you can set up things such that dropping packets is no big deal. By sending all values each time, for example. Or by adding a sequence number such that lost packets are easily spotted. The fancy term for this is to make requests “idem-potent” – the HTTP protocol and web browsers normally work that way too, BTW.

To send data reliably, set the “ack” argument of rf12_sendData() to 1 and be prepared to accept occasional slow-downs. To send data on a best-effort basis, set it to 0.

The last important comment to make here is about buffer management. The RF12 driver only does a limited amount of buffering – this has two important implications:

With received data, you may only access the incoming packet in rf12_buf between the rf12_recvDone() and rf12_sendReply() calls. At all other times, rf12_buf, rf12_crc, and rf12_len are indeterminate.

The other implication is that you have to provide a pointer to your own buffer with data to rf12_sendData(), and this buffer must remain available and unchanged after rf12_sendData() returns. The buffer is given back, i.e. available for your re-use, when rf12_todo becomes negative again. You can use multiple buffers and send a different one each time, as long as the current buffer being sent adheres to these rules.

Limited-bandwidth wireless communication such as with the RFM12B on the 433/868/915 MHz bands is more effective at best-effort packet delivery than at getting each and every packet across with 100% reliability. The RF12 driver is small and uses few resources, but it does come with some trade-offs. With the additions described above, you’ll be able to set up a reliable data stream when needed. I’ll report here when these additions are ready for use.


In AVR, Software on Jun 4, 2009 at 00:01

The JeeBot now has telemetry functionality, continuously sending real-time process data by wireless for analysis and display on a desktop PC.

It was quite simple to add this: send a buffer with the latest data every 200 msec, using the RF12 driver. No acks, no checking – the receiver grabs as much as it can off the air, and simply ignores invalid and lost packets.

Here is the essence of the code added to the JeeBot loop, which runs every 20 ms – in lock-step with the pulses it generates to control the servos:

Picture 2.png

A second JeeNode acts as receiver to pick up these data packets and transfer them to the serial port – here’s the complete sketch:

Picture 3.png

Sample output:

Picture 1.png

These values show what the JeeBot is doing while running on its own internal batteries … i.e. wireless telemetry in practice!

The next step will be to analyze and visualize this data to help me properly tune the PID control parameters. That’s more work.

Minimal motion

In AVR, Hardware on Jun 3, 2009 at 00:01

Now that I’ve been bitten by the robot bug, it’s hard to stop. Wanted to experiment with a minimal setup for self-balancing:

Minimal motion

These are 1.5 .. 3V motors with 1:96 gears from Conrad. What’s special about these is that they only need some 20..30 mA current, which is sort of within the direct-drive capability of an ATmega168. That means 2 I/O pins per motor can be used to create an H-bridge without any further electronics.

Here’s a small sketch to drive these from a JeeNode:

Picture 1.png

A couple of details show that this really is pushing the limit: without the capacitors, timing becomes erratic. Also, the delays between reversals seems to be needed to bring the motors to a stop. I suspect that there’s still some very bad stuff happening due to inductive kickback, so diodes to ground and VCC are probably required to avoid damaging the MPU chip.

But it does run. It’s all driven off a tiny 100 mAh LiPo battery in that picture above, and it kept going longer on a charge than I was willing to wait for. Probably over an hour – total power draw is in the 50 .. 60 mA range.

Anyway, this is even more spielerei than the JeeBot. Just wanted to find out whether these components might be used for a little baby balancer one day. This would also require wheels and at least an accelerometer.

Vertical JeeBot

In AVR, Hardware on Jun 2, 2009 at 00:01

Here’s a first example of the JeeBot standing upright:

Vertical JeeBot

When held upright on startup, it actually stands on it’s own two wheels very calmly, compensating immediately for slight imbalances for a couple of seconds. But beyond a minor error, it fails to regain its balance – so my hands are right outside the picture, ready to catch it :)

Have added a Memsic 2125 accelerometer to provide a sense of what’s up. It’s connected to port 1, with the X and Y axes each producing pulses at around 100 Hz.  The gyro kicks in when it’s falling either way. Having both near the center of gravity helps, as the counter force of the servo won’t disturb the accelerometer as much.

Here’s the main code. It has a crude low-pass filter and PID control loop:

Picture 1.png

The parameters were set using (much) trial and (much) error. I’ll clearly need to learn more about PID control to make this thing properly self-balancing. The loop runs 49 times per second on average, which also happens to be the servo pulse rate – maybe there’s some accidental interaction with the SoftwareServo library.

But still, a lot better than I had expected after one day!

Horizontal JeeBot

In AVR, Hardware on Jun 1, 2009 at 00:01

The JeeBot has made its first explorations, using a Nunchuk controller:

JeeBot baby steps

It drives on two wheels plus a coaster ball to support the batteries – although not very fast and veering slightly to the right. It will also turn, by rotating the servos in opposite directions. The batteries push down hard on the coaster ball, making the wheels slip when turning if the surface is not hard enough. The control mechanism is somewhat proportional, although it seems to work best by just pushing the joystick to its limits.

Here’s the current primitive control loop:

Picture 1.png

Some more close-ups:

JeeBot baby steps

From left to right: the Wii adapter, batteries with coaster ball underneath, on-off switch, JeeNode, and the edge of the servos.

Not much wiring needed to get it going:

JeeBot baby steps

The two resistors divide the battery voltage in half, so it can be measured by an ADC pin. Note the use of wire to “bundle up” the Nunchuk I2C “bus”.

Port layout so far: 1 = unused, 2 = left servo + battery level, 3 = right servo, 4 = Nunchuk via I2C.

I’ve also mounted the gyroscope (not connected yet) in the proper orientation to sense rotations around the wheel axis:

JeeBot baby steps

Will need to add an accelerometer as well, no doubt.

The center of gravity is just about on the power-switch, between the battery pack and the JeeNode. Which is quite low when this thing is placed upright, not sure the servos + control loop will respond fast / accurately enough for balancing.

Current consumption is around 30 mA when idle, 160 mA with wheels turning freely, and up to some 300 mA under load – these 4 NiMH batteries give about 5.2V under no load when full, but I’ve seen it drop to 3.7 V under load after a bit of use – not so good…