Monthly Archives: August 2015

Measuring wheel speed

Each wheel on the robot is paired with a slotted disc, which passes through an optical sensor.  There are 20 slots on each disc, which translates to 20 “on” pulses per rotation.  However, it’s easier for me to count both the “on” and “off” pulse edges, so I’m dealing with 40 pulse edges per each wheel rotation.  I’m going to call these ticks as that’s a lot easier to say.
DSC_9248But ultimately, I don’t care about ticks.  I do care about speed, though.  So I’m going to start there, and figure out what I need in order to calculate that.

Simply stated:

speed=\frac{distance}{time}

or:

speed=\frac{1 tick}{timeSinceLastTick}

or, if I throw some averaging in there:

speed=\frac{numTicks}{elapsedTime}

I can already see that there’s going to be a problem when the speed approaches zero, as there are no ticks to measure the timings.  So I’m going to start by measuring both the number of ticks that have occurred, and the amount of time that’s passed.  If too much time has passed, I’ll consider the speed to be zero.

// Store up to 10 "tick" (or "no-tick") events
const uint8_t NUM_SAMPLES = 10;

// Keep track of how many of the "tick" or "no-tick" events have happened.
uint8_t _tickCount[NUM_SAMPLES];
volatile uint8_t _totalTicks = 0;

// Keep track of the event timestamps
uint32_t _timings[NUM_SAMPLES];

// Some pointers to the arrays above.
volatile uint8_t _oldestIndex = 0;
volatile uint8_t _newestIndex = NUM_SAMPLES - 1;

When a tick occurs, the system calls an interrupt:

ISR(PCINT1_vect) {
    uint8_t newState = PINC & (_BV(PINC2) | _BV(PINC3));
    uint64_t nowStamp = micros(); // timestamp in µs
    uint8_t changes = newState ^ _encoderState;
    _encoderState = newState;

    if (changes & (_BV(PINC2))) {
        _totalTicks = _totalTicks - _tickCount[_oldestIndex] + 1;
        _tickCount[_oldestIndex] = 1;
        _timings[_oldestIndex] = nowStamp;

        // Move the pointers along, overflowing back to zero if needed.
        _newestIndex = _oldestIndex;
        _oldestIndex++;
        if (_oldestIndex >= NUM_SAMPLES) {
            _oldestIndex = 0;
        }
    }
}

If a tick didn’t happen, we inject a zero into the mix:

// Called when... nothing happened!
void nothingHappened() {
    cli();
    // Overwrite the "oldest" item in the averaging loop, and adjust pointers.
    _totalTicks = _totalTicks - _tickCount[_oldestIndex] + 0;
    _tickCount[_oldestIndex] = 0; // nothing happened!
    _timings[_oldestIndex] = micros();

    _newestIndex = _oldestIndex;
    _oldestIndex++;
    if (_oldestIndexB >= NUM_SAMPLES) {
        _oldestIndexB = 0;
    }
    sei();
}

And finally, in order to calculate the current speed:

double getSpeed() {
    cli(); // Make sure the interrupt doesn't fire while we're in here.
    uint8_t totalTicks = _totalTicks;
    uint64_t oldestTime = _timings[_oldestIndex];
    uint64_t newestTime = _timings[_newestIndex];
    sei(); // Set the interrupts free!

    // To get the time difference, we can't simply subtract,
    // because micros() overflows every 70 minutes or so.
    // Implementation of getTimeDiff is left as an exercise
    // to the reader.
    uint64_t timeDiff = getTimeDiff(oldestTime, newestTime);

    if (totalTicks == 0 || timeDiff == 0 || timeDiff > 10000000) {
        return 0.0;
    } else {
        return (float)((totalTicks - 1) * 1000000) / (float)(timeDiff);
    }
}

There’s a little more to it, but you’ve got the idea.  It’s just a bunch of code that watches how far we’ve gone, another bunch that watches the clock, and at the end of the day, it’s just simple physics:

speed=\frac{distance}{time}

Interface board gets some feature creep

Yes, the parts count keeps going up.

A board I’m working on that’ll sit atop a Raspberry Pi.  It’ll replace the mass of jumper wire that’s currently serving the same purpose.  This board is primarily for the robot, but I have a couple of other usecases in mind.  Besides, I get three copies of the board from the PCB house, so I might as well make it slightly multi-purpose.

Now it has an I2S audio codec chip.  I’ve never tried to do anything with digital audio before, so I’ll probably end up with a Version Two at some point in the future.

foo

So far, it’s got:

  • Yet another ATMEGA328p microcontroller.  This one could easily be something with less horsepower, as it’s just there to manage the power supply and try to make sure bad things don’t happen.
  • Connection for “Motion Controller” board
  • Connection for I2C peripherals (the camera pan/tilt and a few other accessory things will attach to this bus)
  • Microphone input
  • Speaker output
  • Power toggle button

I think I should go to bed though, before this gets too many more features!

Why two motor controllers?

Someone at work asked me why I put two separate motor controller boards on the robot. Well, it would have been very easy to do so.  And in my original prototype, I had done exactly that, using an Arduino UNO and the fantastic Adafruit Motor Shield.  My motor controller boards use the same H-bridge chip as Adafruit’s motor shield, but that’s where the similarities end.

The core of the Dual Motor Controller is the ATMEGA328P microcontroller.  Among this chip’s many talents: six of the pins can output a PWM signal.  But two of them are special.  Two of them can go ultrasonic without messing up the other timers!

eagle

It’s those two, in the middle, highlighted in bright red.

These two can run a PWM frequency around 32kHz, which is well within spec for the TB6612FNG motor driver, but it’s conveniently outside the hearing range for most humans.  You know that “hum” you sometimes get when electric motors aren’t going at full speed?  This gets rid of that!  It’ll annoy all the neighbourhood dogs, though.

But there’s more!

Having a separate board for the front and rear motors made it possible to mount the optical encoders directly to the same board as the controller.  A slotted disc on each wheel passes through an infrared break-beam detector, and results in a number of pulses that the microcontroller can count, which correlates to the speed of the wheel.  (I can only measure speed and distance with these sensors.  I’m only able to infer the direction.)

And finally:

Building two separate boards also saved me a little bit of money on the PCB.  OSH Park does a great job of manufacturing PCBs for me, but custom PCBs are certainly not the cheapest things in the world.  At $5.00 US per square inch, they’re about the only thing more expensive than Vancouver real estate.  But you get three boards for that price.   So having a need for more than one board certainly makes sense to me!

Office Robot Modules

I originally wanted to design and build all the parts for this robot on a single PCB.  I figured that would look nicer.  But I’m really glad that I’ve opted for a modular approach to the whole thing.  It’s made it so that I can focus on one problem at a time, and it makes it easy to replace and/or reuse components.

Here’s a diagram of all the modules that will eventually be part of the robot.  Colour indicates what’s been done so far, and what remains.

OfficeBot Architecture

Blue

I’ve completed building the Motion Controller and Dual Motor Controller boards.  They’ll need some firmware changes to support additional boards, but aside from a minor hardware issue on the Motion Controller (which I’ve been able to work around by using other hardware for the testing, these are looking pretty decent!

Pink

Prototyped, or in-progress.  I’ve built a website that’s currently being served up by the robot itself.  That’ll be moved to a terrestrial web server, eventually.  The connections between the Pi and the rest of the hardware is now breadboarded.  Although it looks hideous with all those jumper wires, it does work nicely.  But I need to sort out an issue with the power supply before I can have the PCB manufactured, so it might just be a little while for that.  I can live with the ugly wires (for a little while).

Orange

What was I thinking?!

I designed the Motion Controller board with support for analog distance measurement sensors and collision switches, as well as lighting control for illumination and hazard lights.  What robot would be complete without a whole whack of blinkenlights?

Some parts of the Office Robot

A few quick snaps of the Office Robot.  The motor control boards are essentially complete (working out the kinks in the firmware, still).  The connection between the motor control boards and the web interface (courtesy of a Raspberry Pi) is obviously still pretty much crap.  But it does work, and I’ve transferred the schematic to Eagle.  All those jumper wires, and pretty much everything that’s plugged into that breadboard will be replaced with a single PCB!

DSC_9236

The motor control boards are a little prettier.  There’s one for each set of wheels, and an interface board in the middle.

DSC_9222

Destroyed the barometer, oops.

So, it turns out, if you populate the MPL3115A2 upside-down, it shorts out the I2C bus and nothing works.

But I did manage to scrape it off the board.  Unfortunately, I damaged the PCB in the process and won’t be able to reinstall the barometer.  But I was able to salvage the rest of the board, so I can use this one as a dev test board until I get the firmware completely sorted out. 😀

Building the Mini Weather Station v2

Last night, I gathered all the parts for the Weather Station and did some assembly.  Installing a few dozen parts by hand, on a 12.5cm² PCB is an intricate process.

I start out with a huge printout of the PCB layout, an unpopulated PCB, and this excellent anti-static parts tray from iFixit.  All the big and identifiable parts go here.  When I’m feeling more energetic, I sometimes print out a specially-formatted parts list that goes under the tray, but I didn’t do that this time.  Just out of frame, there’s a stack of bags with hundreds of tiny surface-mount capacitors, resistors and inductors.  Since they’re not easily-identifiable, I keep them in labelled bags and deal with one at a time.

IMG_3829.JPG

Next, I align the solder paste stencil over the bare PCB and squeegee the paste onto the board.

Before:

IMG_3830.JPG

After:

IMG_3831.JPG

That paste is made out of microscopic balls of lead-free solder, held together with a sticky material called flux.  As you can see in the photo above, it’s not a perfect application of paste, but the reflow process is somewhat forgiving: the surface tension of molten solder helps to settle the parts into better alignment.

About a half-hour with curved ESD-safe tweezers, and the board is fully-populated.  At this point though, all the parts are simply resting atop the sticky paste.

IMG_3834.JPG

Into the oven!

This is a modified toaster oven, that I use for the sole purpose of baking electronics.  There’s my new board, ready to get baked!

IMG_3835.JPG

I really did have far too much fun building this toaster… I ripped out the existing thermostat and timer, and installed my own completely custom control panel and temperature control circuitry.  And it does a pretty decent job of following the time/temperature curve that I programmed into it!

IMG_3841.JPG

A few minutes later, and after it’s all cooled down, I’ve got a completed board!

IMG_3846.JPG

One commented-out line of code…

So it turns out, the original Mini Weather Station v1.1 board does still work, and it is still sending data to the Internet.  Well, it was trying to, anyway.  Turns out it was getting stuck because a line of JavaScript just wasn’t getting called.

Mini Weather Station v2

Last winter, I built a device that I called “Mini Weather Station.”  It is a small plastic enclosure which contains a thermometer, barometer and hygrometer.  And of course, a microcontroller, realtime clock and a 2.4GHz radio module.

IMG_3827.JPG

It worked reasonably well for a few months, even though it had a few minor design flaws.

IMG_3828.JPG

Yeah, that little piece of red wire is a sign of one of those minor design flaws.  The other problem isn’t as obvious from the photo.  I had originally intended the microcontroller to run at 1MHz on its internal oscillator.  But when I did, the barometer stopped playing nice with the microcontroller.  While I am able to run everything at 8MHz for a little while, the µc starts to become unreliable as the battery depletes.

Last time, I thought the battery was dead.  So I replaced it with a fresh one.  But, no matter how fresh the battery, it’s no longer transmitting.  The culprit seems to be some corrosion on a few of the radio module’s solder joints.

While I’m disappointed that the board has failed so soon, it’s given me an opportunity to address the design problems.

EAGLE screen shot

Here, I have a new board design with space reserved for a 4MHz ceramic resonator, a new expanded debugging header, and a completely redesigned board layout to better suit the orientation of the finished PCB in the plastic enclosure.

This still won’t solve the corrosion problem, though.  I found something called a “conformal coating”: a nasty chemical which claims to protect against moisture, corrosion, fungus, thermal shock, and static discharges.  I haven’t bothered with it before, mostly because I didn’t know that it was even a thing.  But even though it’s starting to cost me far too much money, this whole fake engineering thing is about trying new things and learning, with eye protection and safety gloves, of course.

With any luck, this iteration will prove to be far more reliable than the last one!

The Office Robot

At my office, it’s pretty common practice to work from home.  But when I’m working from home, I lose touch with what’s going on at work.  And we have a few people on the team who live in a completely different province.  What if we could have a robot that could be controlled over the Internet, and provide a way for people to remotely interact with each other?

Continue reading