Jon's Place

Monday, January 19, 2015

Work Stuff

Some of you might be interested in the stuff I am doing at my day job (Mozilla - been working for them for two years now).

In general, I'm building tools for measuring power consumption on FirefoxOS phones. Those tools include hardware and software components. I did a post a little over a year ago, when I first started working on power stuff.

This year, I'm building a new version of the battery harness, one that is portable. The idea is, you attach it to your phone, and spend the day wandering around, doing whatever it is that you do, and all the while the battery harness is logging power usage data to a micro SD card.

I assume the people reading this are more interested in how it all works, so I'll dive down into the details now.

The battery harness basically pulls the battery out of the phone, and provides a secure mechanical adapter to power the phone from the battery, while allowing the positive line to be intercepted, between the battery and the phone. This shunt goes to the ammeter (a custom board that I designed and built), and the ammeter measures voltage drop across a resistor to get instantaneous current.

Normally, the ammeter is in a small 3D printed box, and is connected to a PC view a USB cable. There is an AVR on the ammeter running some custom C code, and it sends power usage data over this USB cable to a Python application running on the host PC. With this new portable harness, I mounted the ammeter directly to the harness, and mounted a Sparkfun OpenLog board under it, connected to the debug hardware serial port on the ammeter (which normally isn't used). You can see these pieces on the following pictures:

Portable Harness with Ammeter

Bottom of Portable Harness, with OpenLog Board

You can also see a small Pololu Voltage Regulator board tucked in there in the second picture. It is a step-up/step-down regulator, and produces a steady 5 volts from anything between 2.7 and 11.8 volts.

Normally the ammeter is powered from the host PC over USB, but with this setup there is no host PC. We can't power it from the phone, because that will interfere with the power consumption measurements. So I got another little single cell 850 mAh Lipo battery from Sparkfun, and mounted it where the phone battery would normally go. It provides 5 volts (using the regulator) to power both the ammeter and the logging board.

Here's what it looks like together:

Portable Battery Harness
I designed and 3D printed a cover, so you could put the whole assembly into your pocket without electrocuting yourself or damaging the electronics. In the above picture, the cover is on the left, and contains an on/off power switch, a charge port (for the small lipo battery), and a neat little turning catch to hold it in position.

Here's what it looks like put together:

Portable Battery Harness with Cover
It make the phone somewhat thicker of course, but it allows you to still use all the features of the phone (including the camera) while measuring power consumption.

Here's a picture with the power switch on. The three LEDs are on the ammeter - green is power, red is a flashing heartbeat, and yellow is an indicator for a software switch on the ammeter. The OpenLog board has a small blue LED, but you can't really see it in the picture.

Portable Battery Harness - Powered Up
There is still a lot of work to do on this - the charging system is not ideal, and I'd like to integrate it better, I also need to write some software on the phone itself, so it logs specific events (like "Took a picture") that can be correlated with the power log. I also need to figure out a way to monitor the voltage on the small LiPo, so I don't accidentally drop its voltage down below 3.0 volts (which can cause permanent damage to these batteries).

Friday, January 16, 2015

Arduino Robot

So, its been quite a while since I last posted here. Sorry, haven't been working on anything robotics related in a couple months. Today I got a robot in the mail from a contest I won over at Diigiit Robotics. This is the first robot I've owned (other than bioloid kits) that I didn't design & build from scratch myself.

Not sure what I'm going to do with it, but you never know...

Wednesday, October 15, 2014

NanoSeeker v2.1 Populated Board

So I built a board tonight, and its working (after removing and rotating one of the h-bridge chips I put on backwards). I've validated that micropython works on it, and I can turn on and off the four LEDs. I've also successfully paired my cell phone with the bluetooth module on the board, so I'm pretty happy about that.

Tomorrow I'll test more of the functionality, making sure that everything works.

NanoSeeker v2.1 PCB Populated

Here's a picture of the entire sub, with the PCB attached.

NanoSeeker v2.1
The hole in the top of the nosecone is where the pressure/depth sensor will go.

New PCB Arrived

So the new PCB from DirtyPCB's arrived today!

It looks awesome, and I like the black color. Here's a picture of the top and bottom of the board, followed by a side-by-side of the previous yellow board with this new one. The only real difference is the bluetooth module footprint (and the color).

Top and bottom of new PCB

New PCB next to previous version
So I'm pretty happy about this - I'll see about getting this board populated tonight after work.

Thursday, September 25, 2014

NanoSeeker v2.0 PCB - Time for a redo!

I made a couple mistakes with this new board for NanoSeeker. One mistake was recoverable - I forgot to include a power line on the schematic going to the IMU chip, so I had to solder a wire in place to provide that. Ugly, but it ends up being usable.

NanoSeeker v2.0 PCB, with power wire for IMU

The second mistake was not recoverable. I chose a bluetooth module strictly based on its size, assuming it would work like other bluetooth modules I've used in the past. The module I chose, the BLE113 from BlueGiga, is a bluetooth 4.0 module, and is pretty much useless out of the box. You have to program it in order for it to be useful, which means you have to have some sort of programming interface designed into your board. Okay for a manufacturer who is going to build thousands of boards - not okay for a hobby-level board that is a one-off.

I found a nice, small module made by ST (same company that makes the MCU chip I'm using), that is bluetooth 3.0, and supports SPP out of the box. The module part number is SPBT2632C2A. I got a couple of them from Digikey, and I'm going to ensure that it works before I do anything else.

So, I'm redoing the board, and replacing the old bluetooth module with this new one. I've also made sure to add a power drop to the IMU. I'm going to try a new PCB place ( - they have similar prices but much better shipping options that SeeedStudio, who I used for the last board run.

Sunday, August 31, 2014

NanoSeeker v2.0 PCB Running

So, this morning I populated one of my new boards, and hand-soldered a few of the through-hole parts needed for it to run...

NanoSeeker v2.0 PCB, Populated
Here's a video with a very simple script running, cycling the four LEDs on the board:

The script is from this page:

leds = [pyb.LED(i) for i in range(1,5)]
n = 0
while True:
  n = (n + 1) % 4
I'll be testing the individual parts on this board over the next little while...

Tuesday, August 26, 2014

NanoSeeker - PCB

So, its been three and a half weeks, and my new board showed up today. So hopefully in the next few days I'll get a chance to build one, and see if it works.
NanoSeeker v2 PCB
These boards were ordered from SeeedStudio.

Friday, August 1, 2014

NanoSeeker - New Board

I've been working over the past couple weeks on the design of the new board for NanoSeeker, and its done now, and sent off to SeeedStudio for manufacturing.

Here's the schematic:

NanoSeeker v2.0 Schematic
The layout was difficult, because the board is only 26mm wide:

NanoSeeker v2.0 PCB - Top & Bottom

NanoSeeker v2.0 PCB - Top Only
The board is going to be done in yellow, which I think is a nice color for an underwater vehicle. Since the shell is clear, it will all be on display. I'm having a surface mount stencil made by OSH Stencils.

I'm again using one of the awesome Pololu 3.3 volt switching up/down voltage regulators to provide power for everything, from the 180 mAh 7.4 volt Lipo battery.

While I'm waiting for the new board to arrive (will be ~4 weeks), I'll work on getting some of the mechanical parts together (dive plane/rudder plus linear actuators), as well as getting started on some of the software that will be needed on the sub.

Friday, July 18, 2014

NanoSeeker Version 2

So, its been quite a while since I last posted here. I spent most of April and May traveling, including going to Maker Faire in San Mateo, and JSConf in Florida. While I was at JSConf, I ran into some of the guys from OpenROV, and we immediately starting talking about ROVs and AUVs. I had brought NanoSeeker with me, just to show to anyone who was interested, and we found out completely accidentally that the battery holder tubes for an OpenROV are exactly the right size to make a transparent shell for NanoSeeker.

NanoSeeker with a clear shell
Eric Stackpole, one of the founders of OpenROV, gave me a spare one they had with them, and I immediately started thinking about what I could do with a new version of NanoSeeker. I built the first version of NanoSeeker in 2009, and a lot has changed in the home-brew electronics space since then.

I decided right off the bat that it should run MicroPython (and thus use an STM32F405 as the processor), and incorporate a full 9-axis IMU, as well as a depth sensor and a speed sensor. I started working on the CAD model, and got it to the point where it was ready to be printed. I bought my own material cartridge for the 3D printer I use for work, so over the past week I printed the parts I would need.

NanoSeeker v2, beside the old v1
I need to find another o-ring that is the right size, and of course I need to completely redesign the electronics, but I think this is going to work out nicely. I'm going to include a bluetooth module on the board, which will allow me to update the python scripts driving it while it is on the bench, without having to open it up.

I'm really looking forward to having a micro AUV that I can program in a reasonable language, without having to go through a lot of crazy hoops.

Friday, February 14, 2014

MicroPython Board With a Crystal, and a New Motor Driver Board

So, I ordered a few of the crystals Damien used on the official MicroPython board, and although physically it isn't a perfect fit, it works, so I now have a nice clean board.

I also got rid of the orange LED, and replaced it with a proper blue LED (I didn't have any of those left when I put the board together). So, everything is as it should be, and is working nicely.

I also ordered a couple new motor driver boards, and have one hooked up now - it is working great. uCee will be back together again shortly, driving around with my custom MicroPython board (all the videos shown up until now were with the Teensy 3.1 running MicroPython).

New Motor Driver Board
Things are back to working, which is a good thing. I'll be bringing uCee (along with Roz) to PyCon in April in Montreal, since both robots are powered by Python.

Friday, February 7, 2014

Of H-Bridges and 3.3 Volts

So, in another twist of this ongoing saga, it turns out the h-bridge I was using for uCee is not designed to work properly with 3.3 volt logic. I had it hooked up, but the motors weren't turning. I took it all apart, hooked up my logic analyzer to the logic pins, and sure enough I was getting a valid signal. I took my multimeter and was going to test the battery voltage to make sure everything was okay, but when I touched the battery probe to the ground pin on my MicroPython board, the motor started running.

That was weird. So I reset it, and tried again. Same results. I tried it with the tip of a screwdriver, touching one of the +5 volt pins - same results.

I went and found the (now discontinued) product page on, and sure enough, the minimum required voltage is around 4.2 volts.

This is only the second robot I've built with 3.3 volt logic (NanoSeeker was the first), and the ARM chip I'm using (STM32F405) has 5-volt tolerant logic pins, so I haven't had to think about it too much so far. Clearly, I didn't think enough about it. It worked fine with the Teensy 3.1, but it clearly doesn't with my new board.

Anyways, I found this cool Canadian company called Diigiit Robotics, that had one of Pololu's new much cheaper h-bridges in stock, so I ordered it. This h-bridge will work with logic down to 2 volts, so I should be safe.

I'll have to print a mounting plate to hold this board in place - the board is much smaller than my current h-bridge, and has no mounting holes. I'll design a plate that is in the shape of the old h-bridge, with the middle cut out and some clips to hold the board in place.

Monday, February 3, 2014

MicroPython Board Working

Things weren't looking that great as of my last update, but I soldered in an 8 MHz ceramic resonator I had in one of my parts bags, and the USB stuff magically started working!

So, I have a fully functional MicroPython board now. Below is a picture showing my new board on the left, with my Teensy 3.1 carrier board on the right. The new board is a few millimeters longer, but the same width. The connectors are laid out in a much more usable fashion. The four wires you see coming out of the connector go to a couple push buttons, and allow me to reset the board, and also put it into DFU programming mode. Once the MicroPython software gets more stable and complete, I won't be re-flashing the board much, so I can remove the buttons. Its hard to get at the surface of the board while its in the robot, so I didn't want to put push-buttons on the board.

Two Boards Running MicroPython

Sunday, February 2, 2014

MicroPython Boards, Crystal Trouble, Flashing LEDs

So, its a long and sordid tale. I got my boards back on Friday:

They sure look pretty. I soldered up the first board, and found out that I had switched the polarity of my battery connector between the Teensy and this board, so I let out a bunch of magic smoke when I first plugged it in. Fortunately, it was just the 5 volt regulator that smoked, and not the ARM chip, so I replaced the regulator and fixed my battery plug. I hooked everything back up, and...

Nothing. No response over USB. I did a lot of troubleshooting, and determined that it was probably an oscillator issue.

That picture shows the BOOT0 line (third row), the RESET line (second row), and the oscillator (top row) hooked up to my logic analyzer. So you pull BOOT0 high, and then, while its high, pull RESET low. At that point, the chip is supposed to start up the external oscillator, which clearly isn't happening.

My brother suggested I could use one of the serial interfaces to the bootloader, and he went so far as to put together a blinking LED "Hello World" style application I could flash, along with the serial bootloader programming code from the Espruino project. I re-purposed my IMU port (which uses I2C normally, but the SCL/SDA lines are also Tx/Rx from USART3 on the chip). I removed the I2C pullup resistors, removed the crystal, grounded the USB D+ and D- lines, and plugged in an FT232 USB to TTL converter to my Ubuntu laptop. I was able to program the chip successfully using that setup, so now I know the other issue is a crystal issue, and not something else fundamental wrong with the ARM chip or my board.

So, I'm not sure where to go from here. The math says I should be using 6 pF capacitors with the crystal, but something clearly isn't working.

I'm going to code up an 8 MHz signal generator using my Teensy 3.1 board, and see if I can get USB working with an external clock source like that. If that works, then I need to try and figure out why this crystal isn't working.

Tuesday, January 28, 2014

Custom MicroPython Board

One of the things I've been working on in my spare time is a new board for uCee. I was originally going to use the actual MicroPython board that I will get from the KickStarter campaign, but I decided to build my own instead for a couple reasons:

  1. It will fit better, and be easier to connect everything to
  2. I want to start playing with more advanced micro-controllers, and building your own board is definitely a good way to make that happen
The other thing I decided after my work-related adventures with the ammeter board, is I wanted to use a PCB design tool that can generate the PCB with the appropriate connections from a schematic. Most hobbyists use Eagle for that, but I absolutely detest the user interface, so I decided to try a different package, namely KiCad. The user interface definitely takes some getting used to, but once I figured out most of the idiosyncrasies, it is quite usable.

Damien George (the guy behind MicroPython) very nicely published the schematic for his latest revision of the MicroPython board, so I shamelessly copied what I needed and added my own parts that uCee needs, and I ended up with something that should work.

Here's my schematic:

And here's what the PCB looks like, first with the bottom layer hidden (which makes the top much more understandable), and then with the bottom later visible:

KiCad can also show you a 3D rendering of what your board would look like, but you have to supply 3D models of any custom parts you include. My board has a whole pile of parts that I had to create my own footprint for (usb connector, uSD connector, all the Hirose DF-13 2, 3, 4, and 6-pin connectors, etc). So I went to the manufacturers website, and found CAD files for most of them, and the imported them into Rhino, scaled and positioned them correctly, and then exported them as STL files. Wings 3D, although nowhere near as capable as Rhino, has a WRL exporter that KiCad is designed for, so I imported the STL models into Wings 3D, colored them, and exported them as WRL files. I then applied the 3D model to each component footprint, which allows me to generate this:

All in all, not bad.

I plan on sending in this board to get made later this week, so hopefully I'll have my own MicroPython board inside uCee within a couple weeks.

Saturday, January 25, 2014

uCee With A Lid

So, the plan all along has been to print a lid for uCee, i just haven't gotten around to it until today.

Way back when I first started this project, the very first thing I did was create a CAD model of the robot:

uCee - CAD Model

Now that the robot finally has its top, you should be able to see the resemblance:

uCee - Real Robot

So, I think it has turned out pretty good, all in all. I just ordered a new pair of batteries for it, so by next weekend it will hopefully work a little better (the batteries I have now are ones I bought back in 2006 for NanoSeeker, and they are pretty much toast). I also have to put together 3 ProxDot sensors, and mount them.

For now, I'm going to work on the software, which can be found (in its current simplistic form) in my GitHub repository.

Here's another video, this time with the top on:

uCee - Machining Axles

So, this morning I cranked up my Sherline lathe, and machined some brass axles for the four idler wheels (the ones that aren't attached to a motor).

Idler axles machined from 3/8" brass rod
To give a sense of scale, the smaller part of the axle is 3mm in diameter and about 13mm long. The larger part is around 9mm in diameter, and 2.5mm long.

Here's a neat picture I took while I was putting it all back together again:

You can clearly see the white encoder disks on the two motors, as well as the rather tight space between the h-bridge board (on the bottom) and the Teensy carrier board above it. I don't have the ProxDot sensors assembled or installed yet - they plug into the small right-angle plugs on the bottom of the carrier board.

Friday, January 24, 2014


So uCee is now running MicroPython on the Teensy 3.1, and moving around, avoiding obstacles (in a very simplistic manner).

Its pretty cool, and I can already do a lot of the stuff I need to in order to run this robot. We need to add interrupt on change for input pins, so I can handle the encoders, and some I2C stuff to talk to the IMU. The rest is just coding...

You can see my current code in my Github repository.

Thursday, January 23, 2014

uCee Coming Together

So my Teensy 3.1 carrier board I ordered from OSH Park finally showed up (took 5 weeks to get here from when I ordered it, but I can't complain - the price was right).

I still have the idler wheel axles to machine (I'm going to machine them from brass on my Sherline lathe), and I still have to put together my ProxDot sensors, but everything else is put together now, so I'll hopefully only have to strip the robot back down one more time before it is ready to roll.

uCee - Getting Closer
 The h-bridge is mounted and wired up under there, although you can't see it. Here's a picture of the Teensy carrier board (populated), with a blank one beside it (OSH Park gives you three boards):

Here are some more pictures of the robot:

I also have to order the batteries, although for now I can run it off a wall supply. My brother has MicroPython (in its current form) ported to run on the Teensy 3.1, and he's got a cute little robot running off it, so I'll have this guy running Python pretty soon.

Thursday, January 2, 2014

uCee Motoring

Perhaps "motoring" is a bit of a stretch, because it certainly isn't moving yet, but the motor code is running and working.

Here's a quick video showing a simple test of the PWM speed control of one of the motors:

As I move my hand closer to the IR range finder sensor, it slows the PWM down. Very simple, but an easy way to test that speed control is working.

The code for this is on my Github repository. Right now the current readings I'm getting from the h-bridge board are all over the place when its running at full speed. I don't expect to ever run this robot at full speed, and the current readings settle down as the motor slows down, so hopefully that will make them useful. The encoders are rock-solid, using the interrupt pin capabilities of the Teensy 3.1.

I'm going to use this PID library to implement closed loop speed control with the encoders. There's a really good multi-part writeup discussing how it all works - highly recommended. I'm going to translate the encoder ticks into mm/second, and use that as the Input for the PID library. I will specify the requested speed (Setpoint) in mm/second also, and if my conversion routine is correct, the robot's speed should be fairly precise.

Sunday, December 29, 2013

uCee - Of Rangefinders and ProxDots

So, today I've been working on uCee (note the slight spelling difference from my previous post - I like uCee as a name better than uC).

Specifically, I've been working on getting my range finders working in a reasonable fashion. I'm using three GP2Y0A41SK0F Sharp IR analog range-finders. I'm powering them with 5 volts, but since the maximum voltage they return is about 3.1 volts, I can hook them directly to the analog inputs on my Teensy 3.1, which allows a max of 3.3 volts on analog inputs.

However, as anyone knows who has used them, Sharp IR range-finders have a curious piece of behavior that occurs as the object being sensed gets close enough - the signal inverts, and starts acting as if the object is moving away instead of getting closer. For the sensors above, that happens at 30 mm away. I was going to use a ProxDot sensor in conjunction with the range sensor, but they trigger when the object is about 45-50mm away. However, since ProxDots have 2 IR LEDs, I tried covering one with a tiny piece of black electrical tape, so there would be only half the strength of light for it to sense. Sure enough, with one LED covered, the ProxDot triggers at almost exactly 30mm, which is perfect.

The code (without the ProxDot) is as follows:
  int value = analogRead(sharpPin);
  float voltage = value * 0.0032258; // 0-1023 -> 0-3.3 volts
  float exactDistance = (100 * ((1.25 / voltage) - 0.15));
  int distance = (int)exactDistance;
  if (distance > 200)
    distance = -1;
So now I'm going to combine in the ProxDot sensor, and add a few lines of code:
  int value = analogRead(sharpPin);
  float voltage = value * 0.0032258; // 0-1023 -> 0-3.3 volts
  float exactDistance = (100 * ((1.25 / voltage) - 0.15));
  int distance = (int)exactDistance;
  if (distance > 200) {
    distance = -1;
  } else {
    int proxDot = digitalRead(proxDotPin); // signal is low if something is sensed, high otherwise
    if (!proxDot)
      distance = max(0, 55 - distance);
And presto - I get a much more useful distance value at close ranges.