I’ve recently invested lot of time in transitioning to Wercker for my CI needs. So far, I’m reasonably impressed. One task I wanted was to automate was uploading an updated Conan package to conan.io on a successful wercker build. I’m not using the binary package functionality of Conan, just the dependency tracking. Here’s the wercker.yml from g2o_conan showing what I do. box: amarburg/lsdslam-dev-host:conan-latest build: steps: - script: name: Debug test code: | rake debug:test rake debug:clean - script: name: Upload to conan.

Being a bit soft in the head, I decided to build some portion of the software for the NSF CamHD Cloud-Capable Tools in Go. Never mind that I don’t know Go. Clearly others in the web-app world are excited by it, it must have some good properties which might apply to our CamHD-web-cache tools. I started with the online tutorial last week, and now have an array of Go tools, and more questions than answers.

I haven’t discussed the results from initial MaSCOT testing in great detail — though some sample data has been posted. One of the big take-aways for me was that two BlueRobotics Lumen R1 lights is simply not enough. Unfortunately, only two lights fit within the power budget dictated by my PoE system. So, we went ahead and re-engineered the power system, purchased a new tether which includes both gigabit and power conductors, and purchased four more BlueRobotics lights.

We’ve officially kicked off the project Cloud-Capable Tools for CamHD Data Analysis. Please see the Project page and Github for the latest news.

See also part 1, part 2 and part 3 I designed the board in Eagle, design files are on GitHub. {:.center} (click image for PDF version) The board is very straightforward. Lots of 0.1" header for connecting to the Jetson dev board and then breaking those pins out to pads. A TI MSP430FR2311 in a 20-pin TSSOP is the brains of the operation. I purchaed a MSP-FET just to have one around, and used the standard “full” 14-pin pinout using Spy-Bi-Wire for communications.

I’ve stared migrating my MaSCOT design files to Github: Project management files on Github Companion board design files on Github

TL;DR: I ended up needing to to design a micro-based “companion board” which handles power-on, watchdogging, out of band comms, and LED light control for the Jetson. The details can be found on GitHub. See also part 1 and part 2 A primary concern for me was ensuring the system was as usable as possible while inside the housing. Opening and closing the housing is time-consuming and somewhat risky in terms of getting a repeatable seal.

Oct 27, 2016: I’ve moved the contents of this page to a more permanent location {:.center}

Code for this post is on Github We have been developing a data acquisition application on the Raspberry Pi 2 — heavily biased towards serial comms. The timing is generally best-effort quasi-realtime. However, there is one thread (which services some A/D converters) where it would be nice if sample-to-sample timing is reasonably consistent. This led me down a path towards getting the best performance for this thread (and the whole application) within the constraints of non-realtime, userland Raspbian Linux.

As described in part 1, the prototype system architecture is: {:.center} The mechanical design was the one element I did not handle myself. I worked with a mechanical engineer at APL to design an inexpensive, easy to machine shallow water housing with enough space for the Zed and Jetson. The final design consists of a single 12" x 12" block of Delrin with a single cavity hogged through it. The front and back faces have o-ring seals and tapped holes for retaining bolts for the endplates, and a series of top-to-bottom through-holes along the sides provide mounting points.