nppilot | Blue Duck Valley Rd

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.

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.

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.

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.

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?

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.