Rolling Plague

Several years ago I bought a broken remote-control truck toy for a buck at a school fund raiser. I knew I wouldn't get the RF part working again, but the chassis had wheels and motors that looked like they were in good condition. I took the thing apart and verified all I had to do was power the wheels in the back to get them spinning, and apply pos/neg voltages on the wheels in front to get them to turn in either direction. I bought some L293D chips so I could flip directions on the motors and had plans to hook it up to an Intel Edison. The project fizzled out though because the Edison didn't have very good support and it was a pain to connect up your own parts to it.

A few weeks ago I got interested in I/O with the Raspberry Pi and decided I should revisit the RC car project. Rather than breadboard it up, I decided I should just buy a Motor Hat board for the car and be done with it. This morning I finally got the whole thing together- I'm calling it Rolling Plague, since I wound up using a copy of Camus's The Plague to lift the controller off the wheels. Plus, everything is absurd.

Parts List

It took a while to pick out the right parts for this project. The main things were:

• Raspberry Pi Zero W: Since this is an embedded project, I bought a Pi Zero W kit with the usual accessories. The Pi doesn't have to do much (handle a wireless connection and run I2C commands to the motors), so the smaller low-power board was appealing. I wanted the WH board, but didn't find it for cheap anywhere.
• UGEEK Stepper Motor Hat v0.2: There are a few Motor Hat boards on Amazon (I assume most are clones of the one from Adafruit). While all I needed was something to control the DC motors, I thought it would be nice to have one that could also drive multiple servos (maybe I'll put a multi-axis camera mount on it later and see what's under my house). The UGEEK hat (see AliExpress) has a sourceforge repo with some drivers and docs (well written, too).
• 4xAA Battery Pack: The Motor Hat needs an external power source to drive the motors. I picked a simple 4xAA battery pack (w/ on/off switch) so I could get 5v. It works, but the front wheels seem to need more power.
• 1300mAh USB Battery: To power the Pi I'm using a USB power bank (we bought this a while back as a backup for phones). It can source enough power to run the Pi, but I know the Pi3 board often complains about being lower than the recommended amount. The Pi can run for hours off this battery.

Hooking things Up

The biggest pain in this project was soldering the pins onto the Pi Zero board. I've never been great at soldering and the pitch is small enough that I had to get a magnifying glass out to do the soldering given my old eyes. I continuously felt like I was ruining the board. However, the board booted when I applied power, and the power/ground pins at least seemed to work ok. For this project all I really needed was the I2C pins to work, so I didn't test out all the gpio pins. I'm pretty sure this will be the last time I ever solder headers on though. If the WH version had been available. I would have gone with that.

I booted the Pi up with the stock Raspbian Stretch Lite image and used a TV/keyboard to setup the OS. I used raspi-config to set the keyboard to US, connect to my wireless router, enable sshd, and enable I2C drivers. The motor hat's sample code needed smbus to run (I may have pip installed it, but you can apt-get python3-smbus). Once ssh was running, I detached the Pi from the TV and switched to using a chromebook to connect to it via ssh. The Zero was sluggish at times, but its python was good enough to issue io commands.

The wiring for the board was pretty easy to hook up. I plugged the 5V batter lines into the HAT and then ran the DC motor lines into M1 and M2 on the board. I also hooked up a servo and tested it out with the example programs. Their library did all of the work of setting up the controller over the I2C. All I needed to do was issue some python commands on the Pi to get it to turn left and right. I did the same things with the DC motors. Basically you set the speed of a DC motor (0-255) and then send a direction command to tell it which direction to spin (forward, reverse, or disengage). The chipset sends a PCM sequence that throttles how much voltage is seen by the motor (averaged over time). It was pretty thrilling to see the back motors spin up and go. They needed a value of 30 or so to get going.

Back and Forth

I didn't want the electronics to get smashed so I put them in a small plastic bin that I could strap to the chassis. The bin didn't quite clear the wheels, so I grabbed a paperback version of The Plague and stuck it between the chassis and the bin. The whole thing is strapped together with a shock cord.

I set the back motor to the minimum power setting and told it to go forward. It immediately went backwards (I hadn't bothered to figure out polarity) and ran into something. I flipped the wires around and issued a few commands to go forwards and backwards. The extra weight of the batteries (and Camus) meant I had to provide a higher value (around 40) to the monitors to get the car going. Similarly, the front wheels didn't turn very sharply, even when using the top value (255). I'll probably need to increase the battery voltage to get it to work a little better.

Driving the car was pretty clunky, largely because I had to issue multiple commands to get each motor to change state (ie, set speed and then enable/disable the motor). My kids started driving their RC cars around me and there was no hope of me keeping up. I'll need to come back later and write some functions to simplify the driving.

Naming

In retrospect, Camus's book seems like an appropriate choice for this project. It's pretty ridiculous to put all this effort (and money) into building an RC car that's nowhere near as usable as a $10 car from a toy store. Still, it's important to keep doing the things you do, no matter how absurd they are.

Blimp Tracking Success

A little over a week ago a friend of mine that knows I track planes called me up to tell me he saw the Goodyear Blimp flying over Livermore. When I got home I went to my Pi-aware flight tracker to see if I could spot anything. Nope- nothing was on the current map and my logs didn't have any hits for the ICAO numbers Goodyear has registered with the FAA (their blimps have tail fins N1A to N7A). While I was disappointed, I wasn't too surprised- the one time I did see a blimp on the tracker it wasn't providing position info. I figured the one my friend saw had already landed, and that my logs weren't observing it because I only record planes with positions.

I had the following Friday off so I took some time to poke around a little more. I found someone had posted a video on youtube showing blimp N2A landing in Livermore earlier in the week. That helped me figure out which ICAO id to look for (N2A is A18D51). Amy called to let me know that she'd spotted it while she was driving to Dublin. I checked the tracker again and got a nice surprise- in addition to picking up its transmissions, there were enough pi-aware users in the area to determine its location via MLAT. So far the tracker always reports the blimp's altitude as being "on ground". Flight Aware says its somewhere between 1000 and 2000 feet. I've read that blimps are hard to track because the low altitude makes it difficult to get enough stations with line of sight to do the MLAT. I don't get much range with it- it disappears once it's out around Dublin.

I don't have a good idea of what it's doing out here. Usually the blimp comes out here for sporting events. The Warriors/Cavs championship games started this week, but they're in a closed coliseum. I guess the Giants and A's also have some home games this week. It's definitely been hanging around Livermore a lot though. On the way home from lunch today we stopped at the Livermore airport and watched it land, swap out people, and then take off again. From the tracks I captured it looks like they made a few trips out to Lake Del Valle and back. It was 90 today, so there were probably a lot of people out there cooling it off. It's funny having a giant blimp hanging out in our little town for so long. It's like a giant puppy wandering all over the place.

Antenna Mount

It's taken more than a half year to get back to it but I finally mounted the antenna on the roof. The main problem was that the mount kit they provided was a little small for the pipes I wanted to use on the roof. I wound up buying new u-bolts and cutting my own bracket plates to make it work. It's a little hacky but so far it's stayed put. I also had to buy some longer (LMR240) cable to get to the PI in the garage.

Moving the antenna outside of the garage seems to have had a positive impact on my reception. As the coverage maps show below, I'm seeing a good distribution of planes in all directions, though I'm missing a notch towards the south. The antenna is on the north side of the house and below the top of the roof, so it's likely the roof is interfering.

I'm pretty happy with the range, though. I see a lot more planes in the 150-200mi range now, and even a handful of planes 200-250mi away (usually international flights coming in over the Pacific). Previously, I used to lose planes around Sacramento. Now they disappear around Reno.

FAODEL 1.1803.1 Release

I'm pleased to announce that we've officially open sourced and released FAODEL (Flexible, Asynchronous, Object Data-Exchange Libraries) on Github. The 1.1803.1 version is a snapshot of all our libraries: Kelpie (a key/blob service), Obbox (an async comm engine), Lunasa (a network memory management unit), NNTI (an RDMA portability library from Nessie), and Webhook (an in-app http server for interacting with your app). It's been copyrighted by NTESS and we've received permission to open source it from the Department of Energy under the MIT license. We even show up in DOE Code now.

This was the first time I've done an open source release at work, so it was an adventure figuring our what we had to do. The initial step was just getting all of our code together in one repo we could export. We wound up merging several repos together and refactoring the build system, which made the whole thing easier to use. We then ran our tests over and over on different platforms until the code was in a stable form that ran everywhere. Once all of that was in order, we started through the legal parts of the release process.

Legal Process

In order to release the software we needed to declare the license we were going to use and do a copyright assertion. My initial instinct with the license was just to do the MIT license since it's simple and open. When I talked it over with the group though, I started to see how the protections provided in other licenses (eg BSD or Apache) might be better for us. The discussions dragged on and got more complicated (at one point someone even roped in a prof at UCSC). I eventually got fed up and decided to go with my initial instinct- I just want people to be able to use the software, so the MIT license is just fine.

The next step in the legal process was figuring out the right way to insert the NTESS copyright message. I see a lot of code these days where they stamp both the copyright and the full license on the top of every source file. It drives me crazy because I hate scrolling through code just to figure out what the API calls are. I read that adding all this junk is not necessary from a legal perspective if you have it all documented in the top directory. However, one of my developers noted that he does appreciate seeing a legal note on the files so he knows where it came from after installation. I agreed that this was useful, and wrote a script to prepend all our source with the 3-line copyright our legal people asked us to put. I also had to mark up directories for third-party libs (eg tcmalloc) that we include but are not the original authors.

Next, I had to do a code review with a reviewer to make sure that nothing bad was going into the release. This linting process meant going through all the code and determining whether there was anything sensitive that could cause problems. In addition to the things I'm used to looking for in these reviews, we had to look for crypto-related things because an open source release has to be treated as an international export. Interestingly, the fact that we reviewed the code got it marked as an export controlled item. For a few weeks there we were technically rated as EAR99, the lowest export control they can place on something. Fortunately, after everything cleared in the process we were changed to a publicly releasable code with no export issues.

DOE Approval

After all the signoffs, the lab submitted the release request to the Department of Energy for approval. The DOE has very positive policies for open sourcing software, so it wasn't much of a surprise that they OK'd NTESS's copyright assertion and open source release of this software. One of the perks of having DOE be involved in the process is that they route your info into gov code databases like DOE Code. According to one of the talks at the ECP meeting this year, we're supposed to be assigned a universal DOI record at some point. We're in the system now, but it doesn't look like the DOI has happened yet.

In any case it's great to be done with the release. I'm not expecting other people to use it, but at least we've got a placeholder now.

Code

The code is now hosted at github:

github:faodel/faodel v1.1803.1

I/O and Data Management for ECP

As the PI for the data portion of Sandia's ATDM Data and Viz project, I needed to give a status update about our work at the annual all-hands Exascale Computing Project meeting in Knoxville. I put together the below poster, which talks about (1) improvement's we've made to SNL's IOSS mesh database library and (2) our work with FAODEL.

Poster

ECP Poster Poster presented at ECP Meeting