AltOS 1.4.1 — Fix ups for 1.4

Bdale and I are pleased to announce the release of AltOS version 1.4.1.

AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.

This is a minor release of AltOS, incorporating a small handful of build and install issues. No new features have been added, and the only firmware change was to make sure that updated TeleMetrum v2.0 firmware is included in this release.

AltOS — TeleMetrum v2.0 firmware included

AltOS version 1.4 shipped without updated firmware for TeleMetrum v2.0. There are a couple of useful new features and bug fixes in that version, so if you have a TeleMetrum v2.0 board with older firmware, you should download this release and update it.

AltosUI and TeleGPS — Signed Windows Drivers, faster maps downloading

We finally figured out how to get our Windows drivers signed making it easier for Windows 7 and 8 users to install our software and use our devices.

Also for Windows users, we’ve fixed the Java version detection so that if you have Java 8 already installed, AltOS and TeleGPS won’t try to download Java 7 and install that. We also fixed the Java download path so that if you have no Java installed, we’ll download a working version of Java 6 instead of using an invalid Java 7 download URL.

Finally, for everyone, we fixed maps downloading to use the authorized Google API key method for getting map tiles. This makes map downloading faster and more reliable.

Thanks for flying with Altus Metrum!

Posted Tue Jun 24 22:35:08 2014 Tags: rockets

TeleGPS Battery Life

I charged up one of the “160mAh” batteries that we sell. (The ones we’ve got now are labeled 200mAh; the 160mAh rating is something like a minimum that we expect to be able to ever get at that size.)

I connected the battery to a TeleGPS board, hooked up a telemetry monitoring setup on my laptop and set the device in the window of my office. This let me watch the battery voltage through the day without interrupting my other work. Of course, because the telemetry was logged to a file, I’ve now got a complete plot of the voltage data:

It looks like a pretty typical lithium polymer discharge graph; slightly faster drop from the 4.1V full charge voltage down to about 3.9V, then a gradual drop to 3.65 at which point it starts to dive as the battery is nearly discharged.

Because we run the electronics at 3.3V, and the LDO has a dropout of about 100mV, it’s best if the battery stays above 3.4V. That occurred at around 21500 seconds of run time, or almost exactly six hours.

We also have an “850mAh” battery in the shop; I’d expect that to last a bit more than four times as long, or about a day. Maybe I’ll get bored enough at some point to hook one up and verify that guess.

Posted Tue Jun 17 19:23:49 2014 Tags: rockets

AltOS 1.4 — TeleGPS support, features and bug fixes

Bdale and I are pleased to announce the release of AltOS version 1.4.

AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.

This is a major release of AltOS, including support for our new TeleGPS board and a host of new features and bug fixes

AltOS Firmware — TeleGPS added, new features and fixes

Our new tracker, TeleGPS, works quite differently than a flight computer

  • Starts tracking and logging at power-on

  • Disables RF and logging only when connected to USB

  • Doesn’t log position when it isn’t moving for a long time.

TeleGPS transmits our digital telemetry protocol, APRS and radio direction finding beacons.

For TeleMega, we’ve made the firing time for the additional pyro channels (A-D) configurable, in case the default (50ms) isn’t long enough.

AltOS Beeping Changes

The three-beep startup tones have been replaced with a report of the current battery voltage. This is nice on all of the board, but particularly useful with EasyMini which doesn’t have the benefit of telemetry reporting its state.

We also changed the other state tones to “Farnsworth” spacing. This makes them all faster, and easier to distinguish from the numeric reports of voltage and altitude.

Finally, we’ve added the ability to change the frequency of the beeper tones. This is nice when you have two Altus Metrum flight computers in the same ebay and want to be able to tell the beeps apart.

AltOS Bug Fixes

Fixed a bug which prevented you from using TeleMega’s extra pyro channel ‘Flight State After’ configuration value.

AltOS 1.3.2 on TeleMetrum v2.0 and TeleMega would reset the flight number to 2 after erasing flights; that’s been fixed.

AltosUI — New Maps, igniter tab and a few fixes

With TeleGPS tracks now potentially ranging over a much wider area than a typical rocket flight, the Maps interface has been updated to include zooming and multiple map styles. It also now uses less memory, which should make it work on a wider range of systems.

For TeleMega, we’ve added an ‘Igniter’ tab to the flight monitor interface so you can check voltages on the extra pyro channels before pushing the button.

We’re hoping that the new Maps interface will load and run on machines with limited memory for Java applications; please let us know if this changes anything for you.

TeleGPS — All new application just for TeleGPS

While TeleGPS shares the same telemetry and data logging capabilities as all of the Altus Metrum flight computers, its use as a tracker is expected to be both broader and simpler than the rocketry-specific systems. We’ve build a custom TeleGPS application that incorporates the mapping and data visualization aspects of AltosUI, but eliminates all of the rocketry-specific flight state tracking.

Posted Sun Jun 15 19:48:15 2014 Tags: rockets

Java Sound on Linux

I’m often in the position of having my favorite Java program (AltosUI) unable to make any sounds. Here’s a history of the various adventures I’ve had.

Java and PulseAudio ALSA support

When we started playing with Java a few years ago, we discovered that if PulseAudio were enabled, Java wouldn’t make any sound. Presumably, that was because the ALSA emulation layer offered by PulseAudio wasn’t capable of supporting Java.

The fix for that was to make sure pulseaudio would never run. That’s harder than it seems; pulseaudio is like the living dead; rising from the grave every time you kill it. As it’s nearly impossible to install any desktop applications without gaining a bogus dependency on pulseaudio, the solution that works best is to make sure dpkg never manages to actually install the program with dpkg-divert:

# dpkg-divert --rename /usr/bin/pulseaudio

With this in place, Java was a happy camper for a long time.

Java and PulseAudio Native support

More recently, Java has apparently gained some native PulseAudio support in some fashion. Of course, I couldn’t actually get it to work, even after running the PulseAudio daemon but some kind Debian developer decided that sound should be broken by default for all Java applications and selected the PulseAudio back-end in the Java audio configuration file.

Fixing that involved learning about said Java audio configuration file and then applying patch to revert the Debian packaging damage.

$ cat /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/sound.properties
...
#javax.sound.sampled.Clip=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider
#javax.sound.sampled.Port=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider
#javax.sound.sampled.SourceDataLine=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider
#javax.sound.sampled.TargetDataLine=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider

javax.sound.sampled.Clip=com.sun.media.sound.DirectAudioDeviceProvider
javax.sound.sampled.Port=com.sun.media.sound.PortMixerProvider
javax.sound.sampled.SourceDataLine=com.sun.media.sound.DirectAudioDeviceProvider
javax.sound.sampled.TargetDataLine=com.sun.media.sound.DirectAudioDeviceProvider

You can see the PulseAudio mistakes at the top of that listing, with the corrected native interface settings at the bottom.

Java and single-open ALSA drivers

It used to be that ALSA drivers could support multiple applications having the device open at the same time. Those with hardware mixing would use that to merge the streams together; those without hardware mixing might do that in the kernel itself. While the latter is probably not a great plan, it did make ALSA a lot more friendly to users.

My new laptop is not friendly, and returns EBUSY when you try to open the PCM device more than once.

After downloading the jdk and alsa library sources, I figured out that Java was trying to open the PCM device multiple times when using the standard Java sound API in the simplest possible way. I thought I was going to have to fix Java, when I figured out that ALSA provides user-space mixing with the ‘dmix’ plugin. I enabled that on my machine and now all was well.

$ cat /etc/asound.conf
pcm.!default {
    type plug
    slave.pcm "dmixer"
}

pcm.dmixer  {
    type dmix
    ipc_key 1024
    slave {
        pcm "hw:1,0"
        period_time 0
        period_size 1024
        buffer_size 4096
        rate 44100
    }
    bindings {
        0 0
        1 1
    }
}

ctl.dmixer {
    type hw
    card 1
}

ctl.!default {
    type hw
    card 1
}

As you can see, my sound card is not number 0, it’s number 1, so if your card is a different number, you’ll have to adapt as necessary.

Posted Sat Apr 5 22:30:55 2014 Tags: rockets

MicroPeak Approved for NAR Contests

The NAR Contest Board has approved MicroPeak for use in contests requiring a barometric altimeter starting on the 1st of April, 2014. You can read the announcement message on the contestRoc Yahoo message board here:

Contest Board Approves New Altimeter

The message was sent out on the 30th of January, but there is a 90 day waiting period after the announcement has been made before you can use MicroPeak in a contest, so the first date approved for contest flights is April 1. After that date, you should see MicroPeak appear in Appendix G of the pink book, which lists the altimeters approved for contest use

Thanks much to the NAR contest board and all of the fliers who helped get MicroPeak ready for this!

Posted Mon Feb 17 00:45:17 2014 Tags: rockets

AltOS 1.3.2 — Bug fixes and improved APRS support

Bdale and I are pleased to announce the release of AltOS version 1.3.2.

AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.

This is a minor release of AltOS, including bug fixes for TeleMega, TeleMetrum v2.0 and AltosUI .

AltOS Firmware — GPS Satellite reporting and APRS improved

Firmware version 1.3.1 has a bug on TeleMega when it has data from more than 12 GPS satellites. This causes buffer overruns within the firmware. 1.3.2 limits the number of reported satellites to 12.

APRS now continues to send the last known good GPS position, and reports GPS lock status and number of sats in view in the APRS comment field, along with the battery and igniter voltages.

AltosUI — TeleMega GPS Satellite, GPS max height and Fire Igniters

AltosUI was crashing when TeleMega reported that it had data from more than 12 satellites. While the TeleMega firmware has been fixed to never do that, AltosUI also has a fix in case you fly a TeleMega board without updated firmware.

GPS max height is now displayed in the flight statistics. As the u-Blox GPS chips now provide accurate altitude information, we’ve added the maximum height as computed by GPS here.

Fire Igniters now uses the letters A through D to label the extra TeleMega pyro channels instead of the numbers 0-3.

Posted Sat Feb 15 02:45:39 2014 Tags: rockets

AltOS 1.3.1 — Bug fixes and improved APRS support

Bdale and I are pleased to announce the release of AltOS version 1.3.1.

AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.

This is a minor release of AltOS, including bug fixes for TeleMega, TeleMetrum v2.0 and AltosUI .

AltOS Firmware — Antenna down fixed and APRS improved

Firmware version 1.3 has a bug in the support for operating the flight computer with the antenna facing downwards; the accelerometer calibration data would be incorrect. Furthermore, the accelerometer self-test routine would be confused if the flight computer were moved in the first second after power on. The firmware now simply re-tries the self-test several times.

I went out and bought a “real” APRS radio, the Yaesu FT1D to replace my venerable VX 7R. With this in hand, I changed our APRS support to use the compressed position format, which takes fewer bytes to send, offers increased resolution and includes altitude data. I took the altitude data out of the comment field and replaced that with battery and igniter voltages. This makes APRS reasonably useful in pad mode to monitor the state of the flight computer before boost.

Anyone with a TeleMega should update to the new firmware eventually, although there aren’t any critical bug fixes here, unless you’re trying to operate the device with the antenna pointing downwards.

AltosUI — TeleMega support and offline map loading improved.

I added all of the new TeleMega sensor data as possible elements in the graph. This lets you see roll rates and horizontal acceleration values for the whole flight. The ‘Fire Igniter’ dialog now lists all of the TeleMega extra pyro channels so you can play with those on the ground as well.

Our offline satellite images are downloaded from Google, but they restrict us to reading 50 images per minute. When we tried to download a 9x9 grid of images to save for later use on the flight line, Google would stop feeding us maps after the first 50. You’d have to poke the button a second time to try and fill in the missing images. We fixed this by just limiting how fast we load maps, and now we can reliably load an 11x11 grid of images.

Of course, there are also a few minor bug fixes, so it’s probably worth updating even if the above issues don’t affect you.

Posted Wed Jan 22 20:39:01 2014 Tags: rockets

AltOS 1.3 — TeleMega and EasyMini support

Bdale and I are pleased to announce the release of AltOS version 1.3.

AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.

This is a major release of AltOS as it includes support for both of our brand new flight computers, TeleMega and EasyMini.

AltOS Firmware — New hardware, new features and fixes

Our new advanced flight computer, TeleMega, required a lot of new firmware features, including:

  • 9 DoF IMU (3 axis accelerometer, 3 axis gyroscope, 3 axis compass).

  • Orientation tracking using the gyroscopes (and quaternions, which are lots of fun!)

  • APRS support so your existing amateur radio receiver can track the location of your rocket.

  • Software FEC, both encoding and decoding.

  • Four fully-programmable pyro channels, in addition to the usual apogee and main channels.

  • STM32L CPU support. TeleMega needed a more powerful processor. The STM32L is a 32-bit ARM Cortex-M3 which is definitely up to the challenge.

Our new easy-to-use flight computer, EasyMini also uses a new processor, the LPC11U14, which is an ARM Cortex-M0 part.

For our existing cc1111 devices, there are some minor bug fixes for the flight software, so you should plan on re-flashing flight units at some point. However, there aren’t any incompatible changes, so you don’t have to do it all at once.

Bug fixes:

  • More USB fixes for Windows.

  • Turn off the cc1111 RC oscillator at startup. This may save a bit of power, and may reduce noise inside the chip a bit.

AltosUI — Redesigned for TeleMega and EasyMini support

AltosUI has also seen quite a bit of work for the 1.3 release, but almost all of that was a massive internal restructuring necessary to support flight computers with a wide range of sensors. From the user’s perspective, it’s pretty similar with a few changes:

  • Graphs can now show the raw barometric pressure

  • Support for TeleMega and EasyMini, including alternate TeleMega pyro channel configuration.

  • Bug fixes in how data were extracted from a flight record for graphing — sometimes values would end up getting plotted out of order, causing weird jaggy lines.

Posted Thu Dec 19 02:22:57 2013 Tags: rockets

Back on Black (Friday) Event

Altus Metrum is pleased to announce our “Back on Black (Friday)” event!

For the first time since the Black Forest fire in June, we’re re-opening our web store this weekend with a host of new and classic Altus Metrum products, including a special pre-order discount on our latest-and-greatest flight computer design, TeleMega.

This weekend only, Friday, 29 November 2013 through Monday, 2 December, 2013, the first 40 TeleMega direct orders placed through our web store will receive a special $50 pre-order discount (regular $400, now only $350!).

TeleMega is an advanced flight computer with 9-axis IMU, 6 pyro channels, uBlox Max 7Q GPS and 40mW telemetry system. We designed TeleMega to be the ideal flight computer for sustainers and other complex projects. TeleMega production is currently in process, and we expect to be ready to ship in mid-December. Pre-order now and we won’t charge you until we ship. Learn more about TeleMega at:

http://altusmetrum.org/TeleMega/

We are also pleased to announce that TeleBT is back in stock. Priced at $150, TeleBT is our latest ground station that connects to your laptop over USB or your Android device over BlueTooth. Learn more about TeleBT at

http://altusmetrum.org/TeleBT/

Another new product we’re thrilled to announce is EasyMini! Priced at only $80, EasyMini is a two-channel flight computer with built-in data logging and USB data download.

Like our more advanced flight computers, EasyMini is loaded with sophisticated electronics and firmware, designed to be very simple to use yet capable enough for high performance airframes. Perfect as a first flight computer, EasyMini is also great as a backup deployment controller in complext projects. Learn more about EasyMini at:

http://altusmetrum.org/EasyMini/

Also in stock for immediate shipment is MicroPeak, our 1.9 gram recording altimeter available for $50. The MicroPeak USB adapter, also $50, has been improved to make data downloading a snap. Read more about these at:

http://altusmetrum.org/MicroPeak

http://altusmetrum.org/MicroPeakUSB

You can learn more about these and all our other Altus Metrum products at http://altusmetrum.org. The special discount on TeleMega pre-orders is available only on orders placed directly through Bdale’s web store at

http://shop.gag.com

Thank you all for your support of Altus Metrum during 2013. It’s been a rough year, but we’re having a great time updating our existing products and designing new stuff! We look forward to returning products like TeleMetrum and TeleMini to the market soon, and plan to introduce even more new products soon.

Posted Thu Nov 28 22:02:50 2013 Tags: rockets

Tracking Orientation with Quaternions

I spent the flight back from china and the weekend adding orientation tracking to AltOS. I’d done a bit of research over the last year or so working out the technique, but there’s always a big step between reading about something and actually doing it. I know there are a pile of quaternion articles on the net, but I wanted to write down precisely what I did, mostly as a reminder to myself in the future when I need to go fix the code…

Quaternion Basics

Quaternions were invented by Sir William Rowan Hamilton around 1843. It seems to have started off as a purely theoretical piece of math, extending complex numbers from two dimensions to four by introducing two more roots of -1 and defining them to follow:

i² = j² = k² = ijk = -1

Use these new roots to create numbers with four real components, three of which are multiplied by our three roots:

r + ix + jy + kz

With a bit of algebra, you can figure out how to add and multiply these composite values, using the above definition to reduce and combine terms so that you end up with a set which is closed under the usual operations.

Then we add a few more definitions, like the conjugate:

q = (r + ix + jy + kz)
q* = (r - ix - jy - kz)

The norm:

| q | = ✓(qq*) = ✓(r² + x² + y² + z²)

‘u’ is a unit quaternion if its norm is one:

| u | = 1

Quaternions and Rotation

Ok, so we’ve got a cute little 4-dimensional algebra. How does this help with our rotation problem? Let’s figure out how to rotate a point in space by an arbitrary rotation, defined by an axis of rotation and an amount in radians.

First, take a vector, ‘v’, and construct a quaternion, ‘q’ as follows:

q = 0 + ivx + jvy + kvz

Now, take a unit quaternion ‘u’, which represents a vector in the above form along the axis of rotation, and a rotation amount, ω, and construct a quaternion ‘r’ as follows:

r = cos ω/2 + u sin ω/2

With a pile of algebra, you can show that the rotation of ‘q’ by ‘r’ is:

q° = r q r*

In addition, if you have two rotations, ‘s’ and ‘r’, then the composite rotation, ‘t’, a rotation by ‘r’ followed by ‘s’ can be computed with:

q°° = s (r q r*) s*

    = (sr) q (r*s*)

    = (sr) q (sr)*

t   = s r

q°° = t q t*

That’s a whole lot simpler than carrying around a 3x3 matrix to do the rotation, which makes sense as a matrix representation of a rotation has a bunch of redundant information, and it avoids a pile of problems if you try to represent the motion as three separate axial rotations performed in sequence.

Computing an initial rotation

Ok, so the rocket is sitting on the pad, and it’s tilted slightly. I need to compute the initial rotation quaternion based on the accelerometer readings which provide a vector, ‘g’ pointing up. Essentially, I want to compute the rotation that would take ‘g’ and make it point straight down. Construct a vector ‘v’, which does point straight up:

g = (0, ax, ay, az) / norm(0, ax, ay, az)
v = (0, 0, 0, 1)

G is ‘normalized’ so that it is also a unit vector. The cross product between g and v will be a vector normal to both, which is the axis of rotation. As both g and v are unit vectors, the length of their cross product will be sin ω

a = g × v

  = u sin ω

The angle between g and v is the dot product of the two vectors, divided by the length of both. As both g and v are unit vectors, the product of their lengths is one, so we have

cos ω = g · v

For our quaternion, we need cos ω/2 and sin ω/2 which we can get from the half-angle formulae:

cos ω/2 = ✓((1 + cos ω)/2)
sin ω/2 = ✓((1 - cos ω)/2)

Now we construct our quaternion by factoring out sin ω from the ‘a’ and:

q = cos ω/2 + u sin ω sin ω/2 / sin ω

Updating the rotation based on gyro readings

The gyro sensor reports the rate of rotation along all three axes, to compute the change in rotation, we take the instantaneous sensor value and multiply it by the time since the last reading and divide by two (because we want half angles for our quaternions). With the three half angles, (x,y,z), we can compute a composite rotation quaternion:

   cos x cos y cos z + sin x sin y sin z +
i (sin x cos y cos z - cos x sin y sin z) +
j (cos x sin y cos z + sin x cos y sin z) +
k (cos x cos y sin z - sin x sin y cos z)

Now we combine this with the previous rotation to construct our current rotation.

Doing this faster

If we read our sensor fast enough that the angles were a small fraction of a radian, then we could take advantage of this approximation:

sin x ≃ x
cos x ≃ 1

that simplifies the above computation considerably:

1 + xyz + i (x - yz) + j (y + xz) + k (z - xy)

And, as x, y, z « 1, we can further simplify by dropping the quadratic and cubic elements as insignificant:

1 + ix + jy + kz

This works at our 100Hz sampling rate when the rotation rates are modest, but quick motions will introduce a bunch of error. Given that we’ve got plenty of CPU for this task, there’s no reason to use this simpler model. If we did crank up the sensor rate a bunch, we might reconsider.

Computing the Current Orientation

We have a rotation quaternion which maps the flight frame back to the ground frame. To compute the angle from vertical, we simply take a vector in flight frame along the path of flight (0, 0, 0, 1) and rotate that back to the ground frame:

g = r (0 0 0 1) r*

That will be a unit vector in ground frame pointing along the axis of the rocket. The arc-cosine of the Z element will be the angle from vertical.

Results

All of the above code is checked into the AltOS git repository

I added a test mode to the firmware that just dumps out the current orientation over the USB link which lets you play with rotating the board to see how well the system tracks the current orientation. There’s a bit of gyro drift, as you’d expect, but overall, the system tracks the current orientation within less than a tenth of a degree per second.

Even with all of this computation added, the whole flight software is consuming less than 7% of the STM32L CPU time.

Posted Mon Oct 28 15:57:27 2013 Tags: rockets