Monthly Archives: February 2012

Time Blindness

As a details-oriented person (and thus a bit of a pessimist), one of my biggest frustrations is people around me who are “time blind”. Let me give you an example…

It’s 9:15 am, you’re deep into solving some difficult problem, and someone calls you up and asks you to review an estimate for them. Let’s assume you can’t just say no.

You go sit down with this person and you review this quote. It involves changing the auto sequence on some widget maker so that on this one particular recipe it stops the conveyor, runs backwards 2 stations, dispenses some new chocolaty cream filling, and continues on.

The first thing you point out is that the quote only specifies 90 minutes total for 2 customer meetings. “That seems a little low, don’t you think,” you say… “after all, from the time you step out of your car at their office, it takes 20 minutes before you even get to their board room, we always spend about 10 to 15 minutes waiting for some last minute guest to arrive, and I’ve never been in a meeting with them that didn’t go at least an hour.”

“So, you think we should put down 2 hours total?”

“No, I think it’s more reasonable to expect each meeting will take 90 minutes, and by the way, in what universe can you make it across town and back in 30 minutes? You’ve only got 1 hour here for total travel time for those meetings. It’s 30 minutes one way in normal traffic. What about walking to and from your car? What about waiting in the lobby?”

“No, you can get there in 20 minutes most days.”

“So you rounded down to 15?”

“We have a contingency amount of 10% over here.”

“10% of 15 minutes is 1.5 minutes… besides contingency is for unknowns… never mind.”

Of course this goes on forever. At 11:30 you leave this meeting, your co-worker looks at his watch and says, “How long are you logging for his meeting? An hour and a half?”

Time Blindness

Rampant in business circles, typical sufferers include new hires with no experience, and overly optimistic managers. Unfortunately those afflicted with Time Blindness also tend to be in denial. Some are experts at hiding it from themselves, going so far as to work extra hours without counting those hours against their projects, reinforcing the “truth” of their misguided beliefs about how long things take.

Treatment

There is none. Just don’t get sucked into their unrealistic commitments, and be careful not to get blamed when their projects invariably go over budget.

OWI-535 Robot Arm with USB Controller from C# and .NET

I got the OWI-535 “Robot Arm Edge” 5-Axis robot arm and USB Controller add-on for Christmas:



The robot arm comes as a kit that you assemble yourself, and my 3 year old and I had lots of fun putting it together (it helped to have some tiny fingers around, honestly). It comes with a manual controller that allows you to rotate all 4 joints, plus the gripper. It’s fun to play around with, but let’s be honest, everyone wants to hook it up to their computer.

Unfortunately the software that comes with the USB controller works on Windows 7, but “32-bit only”. That was a little annoying, but hey, I didn’t really want to stick with their canned software anyway. I figured I would see if I could get it to work from C#. I was surprised to find a great site by Dr. Andrew Davison in Thailand who wrote some Java code as part of his site for his book Killer Game Programming in Java (chapter NUI-6 Controlling a Robot Arm, which doesn’t appear in the book). Surprisingly he went as far as to do the inverse kinematic equations so you can give the arm a set of X,Y,Z co-ordinates (in mm) in “world frame” and it will calculate all the join angles to get to that location, and then used timed moves to get the arm into that position.

His Java library uses libusb-win32, and that library has a .NET equivalent called LibUsbDotNet. The API’s don’t appear to be the same, but thankfully I managed to find a thread on SourceForge about controlling the OWI-535 using LibUsbDotNet. So, over the course of a couple of nights, after the kids went to bed, I ported Dr. Davison’s Java code over to C# (quite easy actually) and replaced the libusb-win32 calls with LibUsbDotNet API calls. It worked!

Here is the .NET solution that I wrote called TestOwi535. I used Visual C# 2010 Express Edition to write it, so that’s free. Also, you must download and install LibUsbDotNet first and run the USB InfWizard first to generate a .inf file (you have to do this with the robot arm plugged in and turned on), and then use that .inf file to install LibUsbDotNet as the driver (technically you’re installing libusb-win32 as the driver and LibUsbDotNet is just the C# wrapper).

If you right click on the C# project in the solution explorer, you’ll find 3 options for startup object: MainClass is the original code I found in the SourceForge thread, but it’s just proof of concept code and only moves one joint in one direction for a second. The ArmCommunicator class is an interactive console application that allows you to move all joints (and control the gripper and light) by typing in keyboard commands. Finally the RobotArm class is the full inverse kinematics thing. In the last case, make sure you start with the arm at the zero position (base pointing away from the battery compartment, and all joints in-line straight up in the air, gripper pointing directly up, and gripper open). It will do a move to the table, to the front right of the arm, close the gripper, and then move back to zero and open the gripper.

Unfortunately that’s where you start to see the obvious deficiency of the arm: it has no position feedback. That means even though it tracks its position in the code, the physical position eventually drifts away from the internal position tracking, and the arm eventually doesn’t know where it is (it’s just using timed moves). One of the biggest areas where you could improve it is to change the joint rates so that it knows that the joints move faster when going down than when going up.

Still, it’s a neat little toy for the price. I’m going to start hunting around for a way to add joint position feedback, as that would really improve the performance. I also want to rewrite a new module from the ground up that allows concurrent joint moves (this one only moves one joint at a time). Ideally you want to control this thing in “gripper frame” instead of “world frame”.

Happy hacking!