tanks a lot

I decided to build a very cool-looking robotic tank kit which is made by OSEPP. They have a variety of grown-up toys like this in the geekspace.

I guess I’ve been inspired lately by some of the local meetups which involve races with autonomously-driven cars.

To build this, I find that a surprising amount of hardware is going into this project as well as several programming languages all at once. I’ve had to bounce back and forth between Python and C as I interface the Raspberry Pi Zero W computer with the Arduino Mega 2560 R3 Plus board. This Arduino doesn’t come with Bluetooth, wi-fi or even an Ethernet jack so I opted to add in the Pi since it’s inexpensive and comes with a full operative system. The Pi of course includes a webcam for initially allowing the remote control features to be easy. Later, that same camera will be used to generate images to be processed for autonomous driving.

DSC_0072

Repository

Update:

I decided to design some plastic parts for the tank. It’s now looking awesome, has some quick-release pins and I’ve purchased a 12-battery AA charger and batteries for the project since it seems to be hungry for power.

DSC_0073

DSC_0074

Screen Shot 2018-09-12 at 2.00.44 PM

The first three attempts at managing the tracks for steering didn’t seem accurate enough for my own driving-related expectations at least. I finally had to resort to trigonometry in the last set of calculations; this appears to be a more natural steerage interface.

It looks like the first two phases of the project are now complete and I’m well into the third (autonomous) phase now.

Autonomous (Self-Driving) Mode

Next up is the part where a service is taking snapshots from the camera and then using this to make steering decisions. The strategy here is to use data image processing to find the road, so to speak, our position relative to the path ahead as well as any competitors also on the track.

The first interesting piece of the data processing involves some linear algebra and a variety of matrices which perform distinct functions, if you will. You basically multiply a particular matrix for a 3×3 array of pixels to replace the center pixel’s color in each case. The first and most useful matrix is named findEdgesKernel and looks like this:

-1 -1 -1
-1  8 -1
-1 -1 -1

This will allow a new, simpler image which should highlight only the track (masking tape) for the path ahead. This part is working quite well so the next step is to process this resulting path image to determine how the tank should steer both now and in the near future.

Screen Shot 2018-09-12 at 2.03.10 PM

hello

Since I’m now an instructor, I thought I would create a repository which demonstrates  code for the many languages out there which could produce a command line tool/interface (CLI).

HelloCommandLine

Currently, there are nine languages represented but I may add more later. Note that everything here is decidedly OSX-specific. Each subsection includes the instructions for running and/or compiling each, noting that some are compiled languages and some are not.

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.

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.