Wasting your and my time


I had a really interesting experience recently which I hope might enlighten others as much as it did me:

I was approached (via LinkedIn) by a recruiter from one of the big tech firms, as they put it "based on the work you've been publishing on image analysis and learning models".  I would have to admit that doing this kind of work for one of the holy trinity sounds like a dream job for a hardcore geek like myself.

So I went along late one afternoon (they kindly offered to meet with me at their premises in town at the end of the day to allow me to focus on my current job).  To be completely honest, I am happy where I am, but what's the harm in hearing what they have to say, right?  What they had to say was truly fascinating.

After the usual niceties, we got down to my professional history.  "I see you've been working in the technology industry since the early 1980's.  That must be a misprint right?"  I briefly explained the somewhat circuitous path that led me to the giants of hardware and software over the years, and how in almost 40 years of work, the best thing I have learned is that I will always keep learning.

"But you don't have a higher qualification in anything relevant.  Just years on the job?  So who really did the work you've been publishing?"

True, I am for the most part self-taught.  I would have thought it's a good character trait.  I can assure you that work I publish is my own, and I'll always credit any and all sources and assistance.

"Wow.  That's impressive.  But if I had known you were so old, I wouldn't have wasted my time contacting you"

At that point, I simply apologised for the obvious inconvenience I had caused the recruiter, and asked to leave.  I was sorely tempted to leave with some cheap shot about wasting my time, and vow never to touch their products and services again but why just inflame an already uncomfortable situation.

I can't change the way someone else thinks.  We can only change our own minds.  This experience did give me cause to reconsider my own personal biases, and I'm going to do my best to see past them in future.

Thank you for your time.

Resuscitating a Scooba

 


I am not 100% sure where this is going, but it's going to be a fun journey...

 

I own an iRobot Roomba 630 floor cleaner, and it works well enough for our house.  But I discovered the iRobot "Create" which is designed for teaching and hacking in general.  As you can imagine, repurposing our cleaning robot for my hobby might not sit too well.

Using the local social networks, I picked up an iRobot "Scooba" for nothing.  According to the previous owner, it won't charge and the power light glows red when you plug it in.

I downloaded the service manual from one of those manuals websites, and learned this is likely to mean that the battery has failed and won't hold a charge.  I figured I could probably re-pack it and things would be sweet.

As with so many of my projects, the problem was a little more complex than I expected.  The reason why it won't charge is that the battery was missing, rather than simply faulty.  Given it's a specialised package, this could prove to be expensive.

I then had the brainwave of making one myself and somehow hooking it into the existing wiring.  I'm not going to be mopping floors, so being water resistant isn't a high priority.

My first DIY pack consists of twelve 2500mAh "AA" cells as shown in the next photo.

 

Using a set of alligator clips I connected it to the battery terminals and got an error.  Then I re-checked the service manual, and there's a thermistor connected to the other two terminals.  Master Instruments make a replacement battery pack, and their catalogue says it's a 5K device.  So I strapped a 4K7 resistor across the thermistor terminals, and tried again.  Success!  For about one minute, then four beeps, meaning the battery is faulty.  What gives?


 

As a test, I replaced my battery pack with a 12V SLA battery and it charged perfectly, so it looks like the charger circuit is functional.  But why didn't my pack work?

I hooked it up again, this time with a multimeter to measure the charge current, and there was no current at all.  When I put my SLA battery on there, I got about one Amp, so my pack is obviously the problem.

Diving further into the manual, it describes a number of charging phases, including the sixteen-hour "recovery" mode which used 430mA to recover a long-discharged battery.  I looked up the specs for the cells I am using, and found that a constant 240mA should do the same time.

It took a while, but my pack eventually did start to charge, so one (or more) of my cells was really flat.  When I reconnected it, the charge process worked just fine.  Just for fun, I added a DS18B20, and fed the temperatures into Splunk (see below), and the temperature curve matched the service manual.




To make it compatible with the Scooba, I used a zip-tie to hold the thermistor against the centre-most cells, hoping this will give me a sufficiently accurate reading.  A decided to also retain the DS18B20 as "my" temperature sensor, and added a 10K/1K voltage divider so that a micro could be used to monitor the pack voltage.  This gives me visibility of the battery health outside of the reports I can get out of the serial interface on the robot.

For security, and short-circuit prevention, I wrapped the whole package in vinyl tape.  The finished result is shown below.  The single orange wire is my voltage divider output.



Because I don't have an original battery case, I still have to figure out the connections in a manner better than alligator clips.  More on that in the next installment.



 

OpenCV and CUDA - updated build notes

Yes, this comes up a lot, and if you're getting mysterious build breaks, maybe it's a mismatch between what version of gcc/g++ CUDA requires, your default compiler.

The symptoms are that cmake completes just fine (so it found a compiler, all the libraries, etc) but then you get a "failed to compile" error when you do a "make -j[number]"

The first thing to do is to run a single-instance make, because the errors will likely be less obtuse.  When I did this, I got:

"error: #error -- unsupported GNU version! gcc versions later than 8 are not supported!"

gcc --version told me it was version 9, so there's the problem.  But how to get around it?

  1. Make sure you have a suitable version of gcc and g++ installed (version 8) in our case.  On Ubuntu, you can do this with:
    "sudo apt install -y gcc-8 g++-8"
  2. Tell cmake about it when you do the pre-build with:
    "-D CMAKE_C_COMPILER=gcc-8 -D CMAKE_CXX_COMPILER=g++-8"
To wrap up, the cmake command line looks like this:

cmake -D CMAKE_BUILD_TYPE=RELEASE \
-D CMAKE_INSTALL_PREFIX=/usr/local \
-D INSTALL_PYTHON_EXAMPLES=ON \
-D INSTALL_C_EXAMPLES=OFF \
-D OPENCV_ENABLE_NONFREE=ON \
-D WITH_CUDA=ON \
-D WITH_CUDNN=ON \
-D OPENCV_DNN_CUDA=ON \
-D ENABLE_FAST_MATH=1 \
-D CUDA_FAST_MATH=1 \
-D WITH_CUBLAS=1 \
-D OPENCV_EXTRA_MODULES_PATH=../../opencv_contrib/modules \
-D HAVE_opencv_python3=ON \
-D PYTHON_EXECUTABLE=/usr/bin/python3 \
-D CMAKE_C_COMPILER=gcc-8 \
-D CMAKE_CXX_COMPILER=g++-8 \
-D BUILD_EXAMPLES=ON ..

This command makes some assumptions I should point out:

  1. You have already installed and verified the pre-requisites.
  2. The opencv and opencv_contrib source trees have been fully expanded and start at the same level under your source.
  3. You created a build directory within the opencv source, and you're executing from within that directory.

Hope this helps you out!


Wasting your and my time

I had a really interesting experience recently which I hope might enlighten others as much as it did me: I was approached (via LinkedIn) by ...