Robotics, electronics and other hobbies



My current robotics research platform is a two wheeled dynamically balancing (inverted pendulum) robot. It is heavily inspired by David P. Anderson’s (aka dpa) nBot. I’d like to thank dpa for documenting his robots so well and for the help he has provided over the years on the Seattle Robotics Society mailing list.

The purpose of the project is to develop a platform on which to test various sensors, navigation and map building algorithms (SLAM), and dynamic control algorithms. Hector is intended to be a stepping stone on a longer term roadmap that includes experimenting with a number of platform designs.


Hector has a aluminium and acrylic body. These two materials are reasonably easy to work with but result in a very robust platform. I have a small lathe which I use to manufacture all metal and acrylic parts for my robots.

Component parts of the base
Partially assembled base
Motor base assembled
Test fit of wheels

Hectors wheels and gear train are from Aliexpress. The wheels are 4.5″ model air-plane tail wheels. They are very reasonably priced but have aluminium hubs and good quality rubber tires. https://www.aliexpress.com/item/2pcs-Tail-Wheels-Rubber-PU-Alloy-Hub…

The gear train uses brass gears, again purchased from Aliexpress. 60 tooth brass gears and 20 tooth brass gears

I initially started out with a 1:1 gear ration with 30 tooth gears on both the motor output shaft and wheel shaft. I changed to a 3:1 ratio (60 tooth gear on motor output shaft and 20 tooth gear on the wheel shaft) in an attempt to provide the necessary speed to prevent the robot tipping over after a very small tilt angle.

The motors are DF robot FIT0186 motorsavailable from a number of places on the internet, but I purchased mine from Digikey (Digikey part no. 1738-1106-ND) . I initially started with FIT0403 motors (Digikey part no. 1738-1156-ND) but found the 122RPM output speed wasn’t sufficient, even with the 3:1 gear ratio change. The update to the 251RPM motors has resolved this and the robot is now able to generate enough speed to recover from a reasonable tilt angle.

The motor driver board is recycled from my previous robot AMI. This board is an adaption of a design by David Smith. It uses xx yyy drivers and aaasss mosfets to provide dual H-bridges and also includes headers for the encoder outputs from the motors. All the various input and output signals are combined into a single 20 pin header which links the motor driver board with the main robot control board. This is a pretty old design now, but still works fine and is sufficient for my immediate needs.

It needs a better heat-sink solution than the aluminium plate I’m currently using if the robot is to run for long periods of time, particularly if it spends a significant amount of time stationary (balancing in place).

Motor driver board
Motor driver board – connectors

Inertial Measurement Unit

The 9 degree of freedom IMU is neat little board I purchased of eBay. It includes a 3 axis ADXL 345 accelerometer, a 3 axis ITG3205 gyro and 3 axis HMC5883L magnetometer.

IMU bottom side
IMU top side

The IMU has far more capability than is required for this simple robot, and at least initially, I am only using the pitch axis on the accelerometer and gyro.

I’m using a basic kalman filter to perform the sensor fusion on the output signals from the gyro and accelerometer. You can see from the graph below that the kalman filter is really effective at smoothing out the noise from the accelerometer and removing the drift from the gyro.

Kalman output

Beaglebone Black Wireless

Beaglebone Black Wireless

The main control board for the robot is a Beaglebone Black Wireless single board computer. I was initially drawn to the BBBW because of the combination of the reasonably high power application processor and dual real time PRUs. It seems that a lot of people are not even aware of the two 32 bit Programmable Realtime Units (microcontrollers) on the Beaglebone Black, especially when comparing it to other single board computers like the Raspberry Pi. I will be relying on the PRUs to provide the deterministic realtime capability required for things such as the Sonar, IR, or LIDAR sensors I am intending to add to the robot.

The Linux OS is convenient with regards to having out of the box support for all the peripherals, and useful tools like SSH for being able to remotely manage the robot over WIFI.

However, Linux is pretty poor when it comes to realtime control. It’s difficult to write software that runs with deterministic timing, particularly when your requirements are getting down to the low millisecond or sub-millisecond resolution. For a lot of robotics related applications, deterministic timing is a core requirement. For example, my kalman filter implementation needs to be called with a consistent period in order to determine rates of change (e.g. angular velocity from the gyro). Although it is possible to write kalman filters with dynamic timing it is significantly more difficult.

I have managed to get by so far using POSIX timers and signals to run PID loops etc. The robot does occassionally display some erratic behaviour however, and I suspect it is due to another system process taking more CPU than normal and slightly delaying my application timer.

The ideal solution to this would be to abandon Linux completely and switch to a real RTOS such as RTEMS, and this is something I am beginning to investigate. I have the latest RTEMS build running on a second BBBW, however the board support package (BSP) for the Beaglebone is still not particularly complete in terms of peripheral support. I’ve used RTEMS in the past and have dabbled with BSP work for my old MRM 68332 board, so adding some of the missing drivers is something I’m keen to investigate.

PSU Project update 2

It’s been a long time since my last update as I have a large number of pressures on my time and I much prefer working on my projects to writing about them!

Some progress has been made, although slower than I would like. Since my last update I have completed the assembly of two prototype control boards. The second was required because during some rework on the first board I managed to lift some pads on the tiny MSOP-8 footprint for the ADC. These pads are really very small, and it is very easy to put just a fraction to much heat into them and lift them from the FR4.

As a result of assembling the two boards I have learnt a number of lessons and identified several improvements for the next revision. Some of key lessons learned have been:

  1. add test points for all important signals e.g. SPI lines
  2. orient all ICs in same direction
  3. add pin 1 indicator on silkscreen
  4. add component value on silkscreen
  5. Check, check and triple check the footprint matches the part you have ordered.

Point 5 above seems to be a common mistake, and all things considered I did pretty well for a first attempt. The footprint for my USBLC6-2SC6 was wrong, so USB will have to wait until the rev 2. board. One approach I have read of other people using to avoid these kinds of mistakes is printing the PCB one to one scale and laying the physical parts out on top to double check the footprints. I might try this before I send out my next board for manufacturing.


I’ve made good progress with the firmware development and have prototype code for the following functions:

  • Setting an output voltage using the DAC
  • Read back of the output voltage using the external ADC
  • Monitoring of the input voltage using the MCU ADC
  • Serial protocol for UART / USB interface
  • Rotary encoder reading for user input
  • ILI9341 320×240 TFT LCD display for user interface

Functions I have still to start are:

  • PWM control of the FAN (Intel FAN control spec)
  • Dithering of DAC output
  • Temperature reading

User interface:

The user interface has been an interesting challenge. To simplify the hardware in order to be able to focus just on the software I decided to use a temporary test platform using a “bluepill” development board which is a cheap STM32F103C8 based board available from Aliexpress for just a few dollars.

These little modules are really handy for mocking thing up on a breadboard and the STM32F103C8 is close enough to the STM32F070CBT6 part on my PSU controller that there is virtually no work required to port the code after prototyping. Here’s a picture of my prototype lashup with the ILI9341 TFT and rotary encoder attached.

Temporary UI development platform

The rotary encoder is the only UI input device at the moment. I may swap the TFT for a touch screen later depending how how this prototype goes, but navigating about using just the rotary encoder seems to work well enough for now.

The UI is based on a simple state machine. The user uses the rotary encoder to scroll through the various options VSET -> VCTRL -> CSET -> CCTRL, and uses the push button function on the encoder to select an option. They can then set the required voltage output in VSET state, or current output in CSET state. The encoder driver has “velocity control” built into it, so slow turns will increment the voltage in millivolt steps, slightly faster turns in 100mv steps and very fast turns in 1v steps, and similarly for the current control function.

Here is a short video of the UI in action:

Prototype PSU User Interface

As you can see I still have some issues to resolve with the fonts. Getting nice fonts to work was a challenge requiring reducing font files down to just the font sizes, and even characters I need to save space.

Final steps with the UI for now will be to integrate that code back into the main PSU firmware project, and figure out which SPI device – DAC or ADC – makes the most sense to share a SPI bus with the TFT screen.

PSU Project Update

It’s been a while since my last update on this project. This has largely been due to a month or so of big weeks at work delivering to a project deadline, and lots of family commitments in my personal time. Work is returning to normal now, so I’m hoping to sneak in a bit of progress on this and another couple of projects before the Christmas madness hits.

I’ve pretty much finished the board assembly now. I’ve just been waiting on the replacement 74HC4053 chips as I had mistakenly ordered SOIC wide i.e. 7.9mm wide instead of the standard 3.9mm  wide SOIC in my first digikey order  – doh!

Putting together this last Digikey order was a huge task. I feel like I need to find a better process / workflow for managing my BOM. It was quite a complicated process to keep track of what parts I need, for this revision, vs what was in the original BOM, minus what I have in stock… There must be an easier way than the spreadsheet/filter nightmare I’ve just been through so if anyone has suggestions please let me know!

Here is the board in it’s current state:

Mostly assembled board

I have a bunch of firmware development tasks I can work on with this revision:

  • PWM control of the FAN (Intel FAN control spec)
  • Dithering of DAC output
  • Read back of the output voltage using the external ADC
  • Monitoring of the input voltage using the MCU ADC
  • Temperature reading
  • Serial protocol for UART / USB interface
  • Rotary encoder reading for user input
  • ILI9341 320×240 TFT LCD display for user interface

Hopefully I should be able to get the bulk of of the firmware development done with the rev 0.1 board.  In parallel I’m going to start laying out rev 0.2 which will include the full regulator for the low voltage (8V at up to 8A) version.

I had initially thought that I may have to do a couple of prototypes of just the digital control portion before I started on the full board including the analog regulator circuit. However, I now think I may be able to get away with just the one version. Time will tell once I have got further into the firmware development.

One thing I have now realised is that I have messed up some of the pin allocations for the STM32 in rev 0.1 as some of the functions have conflicts. Hopefully I’ll be able to move some of the allocations around a bit and be able to stick with the STM32F070CBT6 part and not have to move up to a higher pin count device. I have a few unallocated pins to play with and  could potentially move the DAC and ADC to the same SPI master if I need to recover more, so I have some ideas about how to tackle this issue.



Lessons learned in PCB layout

My Programmable PSU rev 0.1 boards have been a great learning experience so far, which is exactly what I expected and hoped for. I’ve already accumulated a ton of lessons learned from the process and rev 0.2 will hopefully be a significant improvement and get me well down the path to the final product. Over the past couple of weeks I have watched a bunch of videos about PCB layout in general, and Kicad in particular and now feel much better informed and armed for tackling rev 0.2. Some of the key lessons learned so far are:

  1. Decoupling caps need to be right next to the IC
  2. Build logical groups of components (generally matching functional blocks in your schematic) and lay those out individually before bringing everything together as a whole.
  3. Use larger traces for power
  4. Use a copper fill if necessary to help with heat dissipation
  5. Get your crystal / oscillator as close to the micro-controller as possible.  I found a great resource at http://hoani.net/engineering/crystal-oscillator-design/  for crystal oscillator design including PCB layout
  6. Be careful USB – it requires differential pairs that need to be carefully handled.
  7. If you can fit component values on your silkscreen – do it. It makes assembly a lot easier than having to constantly refer to a schematic to check values

Item #4 above relates to the LM317 regulator I am using to convert down from the 12v input to a 3.3v supply for the STM32. I am using the SOIC-8 package version of this device, and it gets hot. It has 4 output pins and I have only connected one of them. One thing I will definitely do next time is connect all four pins together with as large a copper fill as possible between the pins underneath the chip. This should go someway to helping with the heat dissipation.

I learned one particularly hard lesson about Kicad and making sure you re-draw the copper fills before generating your gerber files.  You can read my debugging journey on this reddit thread. Once I had figured out what had gone wrong I tweeted about it  and got some great advice back. Apparently this has been fixed in Kicad 5 where you can select an option to check zone fills before plotting – clearly I wasn’t the first person to be bitten by this issue!

Unfortunately though it resulted in a couple dead shorts on the board where VDD was connected directly to GND e.g.:

This is what I saw in pcbnew.

This is what the generated gerber file looks like.

Some judicious cuts with a craft knife and the boards are salvageable which is fortunate. Ultimately they were just intended to prove the digital control portion of the design using the STM32F070CBT6 which I should still be able to achieve with the rev 0.1 design.

After spending more time than I care to admit on figuring out the previous problem, I then had to diagnose why my STM32 kept hanging every time it got to the SystickHandler. Long story short I had jumpered BOOT0 to VDD instead of GND – won’t be making that mistake again either!

So, after all that I finally had a booting board and here is a blinky video to prove it:

pcbway.com – can recommend!

So, a couple of weeks ago I placed my first order with www.pcbway.com. I have been super impressed with their service, right from the beginning of the ordering process to having the boards in my hands.

Even for a complete beginner, the pcbway website makes the ordering process simple and straight forward with sensible pre-selected defaults if you go for their small prototype offer. This is priced at an incredibly sharp $5 for 10 pieces for a 1 or 2 layer board as long as you can stay within the 100mm x 100mm size, which in fairness is plenty big enough for many hobby projects or even many commercial designs. They even give you a nice selection of solder mask colours to choose from, but beware Purple, Matte Black and Matte Green cost more – something I figured out after I was already part way through the process so had to upload my design again. To be fair there is a nifty pricing calculator displayed on the left hand side of the page that updates as you change options, so this was totally my fault for not paying attention.

Once you have selected your options and uploaded your gerber files they have an actual human engineer do a manual review! They turn this around within an hour, and will contact you if you have any problems. One of the foot prints on my board was for a barrel jack power connector, and it had drills over slots. The engineer emailed me to check if they should be drilled or slotted. Great service and incredible turn around time on the review.

Once through the review process, you pay for your boards and they enter manufacturing. This is one of my favourite parts of the website – they have a real-time progress indicator of your boards as they go through the various manufacturing stages! I loved seeing the update that my board was up to the next stage of manufacturing – it’s a little gimmicky I suppose, but it really appealed to me and I bet I’m not alone in that.

Progress indicator

The order process console on the pcbway website.

Time from placing the order to delivery in New Zealand was just 7 days (including a weekend) – amazingly quick turn around time. The boards arrived well packed in a nice pcbway box, with good bubble wrap and foam protection around them.

delivery box

Protective packaging

The actual boards themselves turned out really well. I chose the red solder mask which looks pretty sweet, although I’m keen to give the blue a try next time. I had used some reasonably small track sizes down to 6mil, and some pretty small package sizes like a tiny little SOT23-6 USBLC6-2SC6 part and everything has come out beautifully. The silk screen is sharp and easy to read – although next time I’ll include a bit more information such as the component values and maybe some graphics for kicks.


I can definitely recommend giving www.pcbway.com a try. Their prototype prices are pretty hard to beat and their service is excellent. They also have a neat feature where you can share your project and if other people order it you get 10% of the value of those orders. I look forward to using them again in the future and who knows – I might even enter their PCB Design Contest some time!

« Older posts

© 2019 jamesfitzsimons.com

Theme by Anders NorenUp ↑