RaspPi + SenseHat + Headless + What's my IP?

Camera box setup for PAN001
showing the arduino + hub +
DHT22 setup. Also a tangle of wires.

I'm playing with a little RaspberryPi3 + SenseHat. The ultimate goal for the setup is to replace the electronics in the camera box (see pic) with this simple setup. However, while testing I want this Pi plugged into our wired network which, unfortunately, doesn't have a static IP address. Since I want to measure power levels and generally don't want to deal with having an HDMI display around I wanted a quick way to get the IP should it change.

Quick solution consists of two components: one is a bash script that gets the IP address, the other is a python script that displays the IP address on the 8x8 led matrix provided by the SenseHat.

Code samples are listed below. Sorry about the lack of syntax highlighting and formatting. Blogger doesn't make that super easy for me and I don't have time to figure it out.

Video in action!

Added to $HOME/.profile:
/home/pi/get-ip.sh &
---

get-ip.sh:

#!/bin/bash
IP=`ifconfig eth0 | grep 'inet ' | cut -d ' ' -f 10`
/home/pi/show-ip.py $IP

---

show-ip.py:

#!/usr/bin/env python3

import os
import sys
from sense_hat import SenseHat

show_ip = True

fn = '/home/pi/show-ip'

# Don't want to run program twice
if os.path.exists(fn) is True:
    sys.exit()
else:
    with open(fn, 'w') as f:
        f.write('')

try:
    ip = sys.argv[1]
except IndexError:
    print("Must pass an IP")
else:
    sense = SenseHat()

    while show_ip:
        event = sense.stick.get_events()
        if len(event) > 0:
            break
        else:
            sense.show_message(ip)

    sense.clear()
    os.unlink(fn)

Planetary Frontiers Workshop - Desert Fireball Network

I had the chance to attend (most) of the 2017 Planetary Frontiers Workshop here at Macquarie University. The aim of the workshop is to bring together folks from across Australia who are working in planetary science. Traditionally this has been a lot of solar system folks although this is being expanded out to exoplanets. Specifically, the focus for the coming years will probably turn to the formation of terrestrial planets and meteors/comets in general.

As such, the workshop had a lot of geologists. Lots of talk about chondrites and other such things I know nothing about (although there were cool titles, such as "Giant convecting mudballs of the early solar system"). Thankfully it was split up so that most of the hardcore geology was on Thursday while the astronomy side of things mostly took place on Friday.

One thing of particular interest on Thursday night was the folks from the Desert Fireball Network. I've heard about their work before and have been interested as they have units spread out all over Australia in the same fashion as PANOPTES hopes to accomplish. Check out their map, which is pretty impressive. Talking to them they said most installations are just on farm land and that the farmers have been very supportive of hosting the units.

Also interesting for PANOPTES is that most of these units run on solar installations and also feature built-in Telstra wireless connections, for which the organization has a monolithic (i.e. 40+ sim cards) sort of "family plan". They have a model whereby the computed coordinates of the fireball are delivered wirelessly on a daily basis, which is minimal data, while the raw data is stored on 3 separate 10 TB hard drives that are offloaded manually whenever the unit undergoes maintenance (every 6 months to 1 year depending on ease of access).

Overview of the DFNEXT box. Nice and neat.

The design of their box is also pretty impressive and incorporates a few design elements that PANOPTES could benefit from. In particular, they have a tiny 5V fan that is hooked up to a 3D printed plastic that directs air over the front of the lens in order to deal with condensation issues. They've also got a custom printed PCB board that they use for power relays that seems well thought out. A few details and pics here although unfortunately nothing highly technical.

There box is also a piece of metal aluminium that they send off to be cut by a private company but which only costs ~$15. They provide the CAD files and say it is much more efficient than having users machine their own boxes.

All in all the DFN is a slightly different model from PANOPTES. They build the units in house (4 or 5 PhD students, full-time staff member, etc) and then send the product off to the users, who host and maintain the box. Still, could be a valuable partnership from which we could learn a lot.

The rest of the workshop was also fruitful and good for learning about the community here in Australia.

PANOPTES - Diving in

James has done a lot of work to get PAN006 up and running at Wheaton College in Norton, MA and this morning we attempted to do a polar alignment test so that we can drive the unit toward first light. Things went...sort of.

First, big thanks to Sean and Joe at Wheaton for helping out with the procedure. We had James remotely operating the unit via ssh while looking at webcam, Sean on the inside communicating with James and I on a Hangout, and Joe doing the dirty work (read: -1.4 C degrees cold work) in the dome itself. The relay switches aren't quite hooked up yet so Joe was mostly acting as a control in case things when horribly wrong. In the end, they went wrong, just not horribly.

Clearly some issues with the hacky web interface I created for doing a remote polar alignment, so we skipped that and had James manually driving. First we tested some basic Home->Park->Home commands to make sure the mount goes more or less where it should.  Despite one large bad sounding noise and some friction on the RA axis, not to mention some self-strangulation by the Dec. cable, we were able to test the basic mount movement commands. Having this accomplished we were finally able to get the procedure up and going only to be stymied by the inability to do a plate-solve on the images. Getting late, that is where we left things.

So now I am in the lab for the first time in weeks, remembering what a disarray I had left things in. 

"It is better to take what does not belong to you than to let it lie around neglected." Thankfully Mark Twain hasn't visited my lab.

Two simple goals for today: 1) try to reduce the startup time for the POCS shell, mostly by limiting the time the cameras take to do initialization, and 2) try to fix the solving.

I already passed some info off to James to play with the solving on his NUC so I'm checking that box for the day. Now to clean up this lab bench and get the cameras up and running quicker...

EDITED: 1) Turns out gphoto2 can take all the options at once, so we were able to drastically speed up init via this PR.