small screen for the raspberry pi 3

I thought I’d do some prep work for a project that I’d like to finish before the Christmas break:  a time-lapse rail kit for the Nikon D750 DSLR camera. I’ll be going to Arches National Park in Utah for that week and wanted to do some astrophotography and sunset time-lapse videos. Here’s vaguely what the rig will look like:

pi-lapse

This photographer/inventor David Hunt has done a pretty good job on his rig and has produced some stunning videos. I hope to take things up a notch since I have access to a 3D printer and a variety of extruded 80/20 aluminum rails from ActoBotics, for example.

Oh… and the entire rig will need to be portable since I’ll likely be backpacking it into the park. Fortunately, I have a sewing machine and a good supply of marine-grade canvas to create something to hold and carry all of this.

TFT

Fortunately, Fry’s Electronics sells some of what Adafruit has to offer and in this case, it’s a tiny TFT screen with a touchscreen built in. It’s technically called a “Pi Hat” since it connects right to the top of a Raspberry Pi 3, for example.

adafruit-1601

I’ve got it connected to a Raspberry Pi 3 and have inserted a new 4GB microSD card for this project and furthermore, have loaded Raspbian Jessie Lite for that image. Although my version won’t have a nifty graphical desktop like the photo above, it will still run touch-based graphical menus.

Python

Looks like I’ll be using the Python programming language for this project. I’d prefer JavaScript but I only have a few weeks to get this “production-ready”, so to speak.

Kivy

The next step in developing graphical menus which respond to touch is to install the Kivy  framework for Python. The menu should allow you to set some configuration options for the spacing of the photos, the number of photos for the series and things pertinent to stepping the camera along the rail using a motor. Finally, there would be start and stop features for each session as well as on-going status.

Nikon

The Nikon D750 has a remote-shutter system and I’ve managed to find a good third-party version of the cable which should come in handy for this. I’ve spec’d out that interface so I should be able to remotely fire off the camera from the Raspberry computer.

Overall

This should be a fun project. I hope I can finish it in the perhaps five weeks left before Christmas break.

Advertisements

da plane

Obviously, I watched too much television growing up. Every week on Fantasy Island, Hervé Villachaize’s character would point to the sky and make this exclamation.

da-plane

In a 3D printer, it’s really important to start printing on a known, flat plane. And yet, many print beds aren’t made of something rigid like glass so bigger parts end up shaped like the print bed itself. Even small deviations can mess up a print. It’s a problem to be solved, actually.

OctoPrint

The software that’s running on my Robo C2 printer is a fork of the popular OctoPrint open-source software. What’s cool about this software is that it will allow you to write plugins to adjust the way it works.

GCODE

The language the printer listens to during the print job is called GCODE. Think of it as a list of common instructions that almost all 3D printers use now.

Autoleveling

One of the GCODE commands in question is G29 and this tells the printer to run through an autoleveling routine. In some cases, the printer’s extruder will actually touch the print bed in several locations. In others, the extruder assembly will use a light plus a photoresistor to hover above the bed and to gauge its height above it. Using either method, the printer can make a reasonable “map” of the print bed and mathematically create a virtual plane to represent it. If the print bed is a little lower on one side, this routine should allow the printer to compensate for that.

Only…, it doesn’t really work that great, to be honest. Someone deserves a round of applause for trying to fix the problem but honestly, a manual approach is possibly the better way to go here.

Although these printers have a built-in autoleveling feature, manually leveling the print bed is preferred by those who are more advanced at 3D printing.

The Problem

I’m currently now working to manually adjust my print bed so that it is perfectly level and an exact height from the extruder. In fact, I have two replaceable print beds for the same printer so both of them need to be perfectly level and exactly the same height all around. To complicate matters, I anticipate designing and creating a third print bed for this which is heated. And that one should also be perfectly level and the same height as the others. The final goal will be to easily and quickly swap print beds without the task of fussing with any settings.

So now, having created a number of GCODE files over the last four months, I really don’t feel like editing them to remove that unnecessary G29 command. Once you’ve manually leveled everything, an autolevel routine is not only overkill but it can cause problems to the print quality. I needed a way of programmatically switching off the command when seen.

The Solution

I’ve created an OctoPrint plugin which helps to solve this problem. Assuming that I no longer need autoleveling at the start of each job, the plugin tells the printer basically to ignore any G29 commands. I now don’t have to edit countless GCODE files or worry if someone sends me a file—the printer will dutifully ignore this command.

Github:  Toggle Autolevel plugin

 

to type or not to type…

that is the question.  Rather than a Shakespeare reference, I’m here referring to a term in software development which determines how a language deals with variables, for example.

Define: type

When you create a variable in a computer language, it’s usually something like this:

var someVarName = 1;

In a case like this, we might infer that someVarName stores a number (an integer).  We might say that the someVarName‘s type is integer.  Using a pet-ownership metaphor, it’s like purchasing a dog house first (“someVarName”) and then next buying a dog to put into it (“1”).  You wouldn’t buy a fish bowl to store a dog… although this seems to work out great if you own a cat.  JavaScript, e.g., is like this picture:  it doesn’t seemingly care if you want to store a cat in a fish bowl.

cat-in-a-bowl

Two Schools of Thought

There are two camps out there:  those who like languages which force the variable type and those who don’t.

A statically-typed language usually involves a step in which your code is converted into something else (compiling) and any type-related issues must be fixed before a program can be created.

A dynamically-typed language is run “as is” and the code is evaluated at the moment of truth—determinations about the type of a variable are made at this time.  If there is a type-related issue, your end-user could be the first person to see the error.

Statically-Typed Dynamically-Typed
Java JavaScript
C++ Python
C# PHP
C Objective-C

The Pendulum Swings

Over the past three decades, the popularity of either approach has waxed and waned.  It’s safe to suggest for the moment that the less-strict languages are gaining rapidly in popularity over their stricter counterparts.

most-popular

We have the world of open source to thank for the popularity and speed of development we’re currently seeing in these dynamically-typed languages like JavaScript and Python.

Seeing the Future

Honestly, though, there are too many people in that strict-is-better camp and their influence is felt within software development companies.  If I were to guess at the future of JavaScript, I’d probably have to say that TypeScript and Flow will gain in popularity as larger development teams look to lower the number of bugs in their code.

I don’t know, though.  Maybe it’s time that we just relax and let the cat hang out in the fish bowl.

 

magnetic card readers

Continuing in the series of fun recycling projects for these Dell Vostro 200 computers, I purchased a MagTek Dynamag USB-based swipe card reader for a new project to track visitors in the office’s entrance.

dynamag

Overview

The solution includes an Ubuntu server which only runs a single application to receive the card swipe details, to find the Track 1 data and to then submit this information to a Microsoft IIS—based website. The pages here then offer up an API for the incoming card swipe details and an administrative page for registering new visitors, reviewing the log details and the visitors as seen, to include the ability to export those details to Excel. The data is stored in a Microsoft SQL Server database.

To save cost, I decided to have each visitor just use a magnetic swipe card already in their wallet. In this way, I wouldn’t have to buy a magnetic card encoder, purchase card blanks nor worry about designing or issuing them (or trying to get them back later).

Typical Cost of an Access Control System for Visitors

From this webpage 2016 Average Card Access Cost

“Expect to pay an average of $1,500 to $2,500 per door for a high-quality system for up to 150 people. … It will cost an average of $1,000 to $1,500 for the hardware for the door. It will cost an average of $3 to $5 per keycard. Monthly service fees can range from $10 to $100 per month.”

My total cost for this project was just eight hours’ labor plus the $48.36 for the card reader! This included the database and website coding plus the I.T. work to setup the Ubuntu server and to create the Python script to talk to the USB-based reader, to test everything and to write up the documentation. This isn’t bad, considering the cost of an average system.