How to piss off a programmer…

This is me, venting about programming. If you’re not a coder, feel free to stop reading here.

I’m fantasizing about strangling one of my client’s programmers. I’ve no idea who he or she is, but I really wish that I could re-write all of their code from scratch. Some of their sins:

  • No comments. None. At all. Zero.
  • No parameter passing. They used over a thousand global variables instead.
  • Typecasting when there is no need. NOT typecasting when there is.
  • Apparently they skipped the coding-for-dummies chapter on state machines.
  • Using arrays to handle single values. Yep, literally defining arrays of one element.
  • Never ever accounting for garbage collection. Pointers are saved to globals and not checked.
  • Duplicating large blocks of code many times, changing just one value for each copy.

Overall, this system works by luck and not design. So I’ve just one message for this anonymous coder:

I don’t know who you are. I don’t know what you want. If you are looking for a working system, I can tell you I don’t have the time to fix everything. But what I do have are a very particular set of skills, skills I have acquired over a very long career. Skills that make me a nightmare for people like you. If you document your code now, that’ll be the end of it. I will not look for you, I will not pursue you. But if you don’t, I will look for you, I will find you, and I will kill you.

How to destroy the world’s economy in two, simple (and inevitable) steps…

There are just a couple of things that need to be invented. The first is a cheap and reliable synthetic vision system. This is already in work by the likes of Google, Nvidia, and IBM. If object recognition (which also implies distance and orientation recognition) can be had for under a couple of hundred dollars, then we need…

The second thing: cheap, reliable, efficient, and fast-acting artificial muscles. The power-to-weight and response time needs to be on par with human muscle fibers. And conversion efficiency (electrical power to mechanical power) needs to be at least fifty percent. These are also in work. Cheap options include muscles made from shape-memory alloy and even fishing line. Both are very inexpensive, but not terribly efficient and with a horrible response time. But better is certainly coming. And then we’ll have the ability to…

Replace pretty much every manual task with a robot. It won’t even make sense to keep sweatshops around when the factory owner can pick up something for a thousand dollars that works without error, 24-7. Sure, they may consume a kilowatt or so of electricity, but in most places that’s less than twenty cents an hour.

In about fifteen years’ time, self-driving cars will become available. Fifteen years after that, normal. Right now, the most common job in the United States is “driver”, be it trucker, cabbie, delivery driver, or bus driver. Those are going to go away. Add in vision systems and artificial muscles with the aforementioned parameters, and every manual labor task will also fall away. If technology continues on its current path (and there’s no real reason that it should not), then this is an inevitability. So the end result will be cutting off the lower two-thirds of employment. Most of the jobs on the global market are those that could be automated, but currently are not due to a lack of robot hands and artificial vision.

Unfortunately, we’re planning our economy as though none of these will ever exist. All throughout this election cycle, I’ve heard calls to “bring manufacturing back to America!” But the sad truth is that it never actually left. It’s just done by automation and, soon enough, will be done everywhere by automation. We as a society have to start planning for this, or we’ll wake up wondering why unemployment is at eighty percent.

Here are a few links to give you something to think about:

Google Self-driving Car project
The Autonomous Tractor Corporation
Fruit-picking robot could replace seasonal contractors
AI Driving the Fourth Industrial Revolution

There are a couple of ways to deal with this (okay, really more than a couple, but I’ll consider the two extremes). First, we can decide that a person’s livelihood is entirely up to them. If they cannot find a job, well that’s just tough. Sort of like how we’ve been doing it for the last few thousand years, and particularly throughout the current industrial revolution.

Or we can take a socialistic approach and say that everyone owns “shares” of collected resources. In that case, you wouldn’t have to work (or work as much, if you liked your job) because the output of the robots would be collectively owned. The automated farm would produce food for everyone, equally. Automated factories would produce goods that people could “purchase” with their collective resource shares. This latter option is much more humane, but our economic system is not at all set up to manage that.

So I’m not offering solutions here. Just something to think about.

You wanna do what?!

So I have this fun idea. It’s something that can be done for about $10K or so, but I’m having a hard time with one particular aspect of it. Allow me to explain…

Imagine that you have two velocipedes (yes, they have to be velocipedes for… reasons) and you mount them side-by-side and about three feet apart with tubing. In between, you hang a lightweight, but comfortable chair. Perhaps something like a lawn chair. Using the same tubing, you mount four electric motors around the outside in a quadrocopter arrangement, complete with propellers. Electric motors are becoming quite efficient, and you can find some on the order of one HP per pound at reasonable prices.

So far, you have a person-sized, velocipede, steampunk quadrocopter. Which is great, but would be way too heavy to actually lift off. Which is why you need a 30′ helium balloon. This would be attached to the rest via the same tubing and a kevlar fiber net over the top. Internal to the balloon is an electric compressor such that the balloon can be dynamically deflated and inflated. So it can provide just enough lift that the quad motors can lift it the rest of the way. But since they’ll be relying in part on ground-effect, the system is tuned such that you can only get about 10′ high.

I have it all laid out in my head, and trust me, it’s awesome! But now for the hard part. How much trouble would I get in to for this? Technically, it’s a “manned, un-tethered, gas balloon” according to their regulations. But since the balloon is not providing the lift (just weight-offset), it’s also technically an ultralight. But since it relies on ground-effect, it’s also a hovercraft and outside of the FAA’s purview.

So my guess is that the FAA won’t be able to decide between laughing at me and having me shot. Any thoughts?

The model A versus the model S

Modern aircraft are rather simpler to operate than in days gone by. Flat-panel displays and GPS navigation have largely replaced the many dozens of “steam-gauges” that the pilot has to watch. But we’re still a long way away from a truly easy-to-fly airplane. And there are a few good reasons for that:

  • If something goes wrong, you can’t just pull over.
  • For historical reasons, modern displays often mimic older ones.
  • For regulatory reasons, certain instruments and controls are required.
  • Navigating in three dimensions isn’t a natural human function (we’re used to two).
  • We don’t really trust autopilots yet.

None of these are great reasons (just good ones), and I believe that aircraft controls will become much simpler in the future. By way of analogy, let’s look at the start-up sequences for a Ford Model A versus a Tesla Model S. First the Ford:

  • Check the tires (flats were not at all uncommon)
  • Check the radiator level
  • Check the fuel level
  • Get in the car and sit down
  • Turn on the cut-off switch
  • Set the gas mixture to between 3/4 and 1
  • Make sure the parking brake is pulled on (toward you)
  • Turn on the gas
  • Set the spark advance lever to “full retard”
  • Pull the throttle lever to about 1/3 down
  • Turn the carb adjusting knob all the way to the right
  • Turn the carb adjusting knob back one full turn to the left
  • Put the gear shift in to neutral
  • Turn the key
  • Pull back on the choke
  • Press the floor starter button
  • After it turns over once, release the choke
  • After the engine turns over, set the spark advance to about 1/2
  • Close the carb adjusting rod to about 1/4 turn open
  • Set the mixture to between 1/2 and 1/4

Now for starting up your Tesla Model S:

  • Get in the car and sit down

Both procedures get you to the same place in your respective vehicles: engine on and ready to go. Modern aircraft are a little bit better than their 1920’s counterparts, but really not by much. And while we don’t have to worry about the engine startup sequence so much, we do have a lot of new things to do before taking off: setting transponders, navigation systems, electronic flight plans, etc.

So we are not up to the Tesla Model S in terms of usability. In my opinion (having worked on quite a lot of different aircraft, and flown a few of them) it doesn’t need to be this way. Sure, airplanes are inherently more complex than cars: a car has two degrees of freedom (forward-backward, left-right) while an airplane has up to six (up-down, forward-backward, left-right, pitch, yaw, roll). But that still doesn’t account for a lot of the overhead that is absolutely screaming for automation.

I think that in the future (and I mean that in a vague and nebulous sense), planes will do most of the thinking for us as far as navigation, take-off, and landing. The flat-panel displays should be alerting us to potential issues, only, rather than faithfully recreating the steam gauges of the past.

End of rant.

Hacking aircraft for fun and profit

Modern commercial jets make use of AFDX networks for sending and receiving control and sensor data. The AFDX protocol is based on Ethernet, and (if you’re familiar with the OSI model) is identical up to layer 2. This means two things. First, that AFDX traffic can be (mostly) routed by standard Ethernet hardware. And second, that Ethernet software tools can (sometimes) be used to troubleshoot and hack AFDX networks.

The problem is that such tools are not designed to handle a number of the things that AFDX does. AFDX is deterministic, redundant, and more fault-tolerant than standard Ethernet. And so you generally need specialized hardware and software to interface with AFDX.

But it doesn’t have to be that way. A laptop’s Ethernet port should be able to read and write AFDX traffic just fine. The only reason that it cannot is that it doesn’t understand the upper level protocols. There have been a few projects to rectify this, and they have made use of the WinPcap libraries for low-level traffic reads and writes. And then they stopped there, because those involved were happy to leave it at the C-code level and lock it away behind corporate-secrecy firewalls.

I was somewhat less than happy with this, and so I’ve written a suite of LabVIEW libraries that can hijack a PC’s Ethernet port [note to the NSA: when I say “hijack”, I’m talking about taking control of an Ethernet port, not an airplane] and read, write, and otherwise manipulate AFDX traffic. If I get clearance to do so from my client, I’ll open source these libraries. And maybe write an article on it. I’m really hoping that I can share this with the world in some way because it’s a really neat thing and fills an as-of-yet-unfilled niche.

Stay tuned for details!

A delicate balancing act…

There is so much that I do that I would want to write about. Much of the work that I do would make for some fantastic conference or journal articles. And some it would’ve even made a great master’s or doctorate’s thesis. BUT… the reality of the situation is that I am almost constantly under some non-disclosure agreement or other. Not that the work I do is terribly secretive. There’s no national security issue (usually) and no chance of any disclosure actually hurting whatever company I’m working for.

But the knee-jerk reaction nowadays is to hide everything that everyone does, all the time. Just in case. As though my obscure bit of network queuing code would sink the company were it ever revealed. From the standpoint of furthering the art, this is not a wise policy. From the standpoint of furthering my career, it’s damned annoying.

As always, XKCD said it best…

What I am up to (part 2 of N)… Arduino!

So let me expound upon the virtues of the Arduino platform for a minute. In case you are not familiar, this is a family of hobbyist microcontrollers with minimal memory, no OS to speak of, and a lot of I/O. Very useful for making things that read information from, or control things in, the real world. Right now, I’m making good use of the Adafruit Feather line. Useful (to me) features:

  • Support for single Li-ion battery use, charging, and monitoring
  • Built-in micro-SD card reader (on my model, at least)
  • Really, really tiny

Anyways, my favorite part about it is the programming environment.  Being so resource constrained, and with such a simple programming model, it feel a lot like coding in the early 1980’s.  Yes, I’m old.

I cannot (yet) go in to detail about the project, but I will put something up on the “Projects” page when I am able.  As soon as I’m no longer sworn to secrecy.