Shallow Thoughts : : Feb
Akkana's Musings on Open Source Computing and Technology, Science, and Nature.
Sun, 19 Feb 2012
We had to get two tires recently, after the Civic got a flat.
Naturally, we wanted the new tires on the front. That's where
steering and braking happens, as well as the drive wheels and
most of the car's weight ... so that's where we wanted the newer tires.
The shop (America's Tire) refused. They said it's a company policy
that a new pair of tires must always go on the rear.
They've even printed up glossy signs
their reasoning -- a fancy poster image that is, unfortunately, wrong.
They show two scenarios. In the one on the left, the rear tires are
losing traction, and the rear end of the car is sliding out. That's
called "oversteer". The car might spin, especially if the driver has
never experienced it before.
That part's all true.
The problem with their diagram is the scenario on the right, where the
presumably better tires are on the rear. In their diagram, magically all
four tires are holding -- nothing ever loses traction. Good deal!
But what really happens if you put the bad tires on the front is that
if something slips, it'll be the front. That's called "understeer".
Understeer can be just as dangerous as oversteer. With practice (I recommend
a driver can learn to detect oversteer and steer out of it before it
gets to be a problem. There's an old saying among racers and
performance drivers: "Oversteer is when the passenger is
scared. Understeer is when the driver is scared."
Most passenger cars, especially front-wheel-drive cars like our Civic,
are designed to understeer severely to begin with.
Putting the poorer tires on the front makes that even worse.
And don't forget the importance of braking. Most of a car's braking
ability comes from the front tires. Don't you want your best rubber
working for you in a panic stop?
While I do understand why the default might be to put new tires on
the rear -- it's better for inexperienced or panicky drivers -- to
insist on it in all cases is just silly.
We drove the Civic home and rotated the tires ourselves.
How did the policy get started?
Dave and I first encountered this policy a couple of years ago.
In the intervening years, it's become pervasive -- just about every
tire shop insists on it now. How did that happen?
If you ask at the tire shop, they may tell you that it's a federal policy --
DOT or some such agency -- or even that it's a state law.
Neither is true. It's merely company policy.
Some will also tell you that it arose from a lawsuit in which a tire
company was sued after a customer spun out. So two years ago, we went
looking to see if that was really true.
Back then, googling either "oversteer" or "understeer" led inexorably
to a Wikipedia page with a reference to "San Luis Obispo County Court
Case CV078853". Unfortunately, Wikipedia's link next to the court case
reference actually led to a general page for a law firm that appears to
specialize in vehicular personal injury lawsuits. (Nice advertising, that.)
There was no information about any such case.
Nor did there seem to be any official records online of such a case;
and the SLO courthouse didn't respond to an email request for more information.
Googling the court case, though, got lots of hits -- nearly all of them
pasted verbatim from the Wikipedia page, then using that as "proof"
of the supposed safety argument.
The test of time
Now, a few years later, it seems that nearly all tire manufacturers
have adopted this as a firm, non-negotiable policy.
Some shops are even using it as a reason to
(See, the front tires wear faster on most cars,
so if you rotate tires between front and rear, now you're putting the
more worn tires on the rear ... which is dangerous! Better to just
let those front tires wear out and make the customer buy a new pair.)
The news is better on the Wikipedia end. Someone eventually heeded
Dave's attempt to fix the Wikipedia page, removed the bogus
advertising link to the ambulance-chasing law firm, and added
"citation needed". Subsequently,
several people rewrote the page in stages, with comments like "This is a
complete replacement. The existing version was wrong from the 1st
sentence and has little relationship to the standard terminology."
The page is much better now.
What isn't better is that the sentence from the old Wikipedia page is
still all over the net, word for word. Google for the court case and you'll
find lots of examples. Many of them are content mills copying random
Wikipedia content onto pages that bear no relation to cars at all.
But unfortunately, you'll also find lots of cases of people using
this phantom court case to argue the safety point.
Sadly, it seems that once something gets onto Wikipedia, it becomes
part of the zeitgeist forever ... and however wrong it might be, you'll
never be able to convince people of that.
[ 19:38 Feb 19, 2012
More misc |
permalink to this entry |
Thu, 16 Feb 2012
I just got an Arduino
Nano. Cute little thing -- I'm looking forward to
using it in portable projects. But I had one problem when first plugging
it in. It was getting power just fine, and blinking its LED -- but it
wasn't showing up as a USB serial port in Linux. dmesg said things like:
usb 1-3.4: new full speed USB device number 7 using ehci_hcd
usb 1-3.4: device descriptor read/64, error -32
usb 1-3.4: device descriptor read/64, error -32
with several different device numbers each time, and an occasional
unable to enumerate USB device on port 4
A web search found a few other people seeing this problem on Linux
or Linux-based devices, with some people saying that pressing the RESET
button multiple times helps. It didn't for me. What solved the problem
for me was switching cables. The mini-USB cable I'd been using -- which
has worked fine for other purposes, including programming other Arduinos
through an FTDI Friend -- apparently was missing something the
Nano needs for downloading. With a different cable,
dmesg showed a much more civilized
usb 1-3.4: new full speed USB device number 20 using ehci_hcd
ftdi_sio 1-3.4:1.0: FTDI USB Serial Device converter detected
usb 1-3.4: Detected FT232RL
usb 1-3.4: Number of endpoints 2
usb 1-3.4: Endpoint 1 MaxPacketSize 64
usb 1-3.4: Endpoint 2 MaxPacketSize 64
usb 1-3.4: Setting MaxPacketSize 64
usb 1-3.4: FTDI USB Serial Device converter now attached to ttyUSB0
What was wrong with the cable? I did some testing with a multimeter versus a
diagram. Didn't get a definitive answer, but I did find that on the
cable that doesn't work for the Nano, it was hard to get a solid
connection on the D- (#2) pin inside the Type A connector. But since
that's the connector that goes to the computer end (in my case, a powered
hub), if it wasn't making good contact, I would expect it to show up
everywhere, not just with the Nano. Maybe the Nano is more sensitive to
a good solid D- connection than other devices.
I'm not really convinced. But Arduino's
"Try a different USB cable; sometimes they don't work."
So I guess they don't know what's special about some cables either.
So if your Arduino Nano doesn't initially connect properly, don't panic.
Try a few different cables (everybody has about a zillion mini-USB
cables lying around, right? If not, here, have five of mine).
The Nano is happily composing random chiptunes as I write this.
[ 16:24 Feb 16, 2012
More hardware |
permalink to this entry |
Sat, 11 Feb 2012
This is the story of my adventures learning to drive a little toy truck
from an Arduino: specifically, how to drive the motors.
Motor control turned out to be trickier than I expected, and I don't
see a lot of "Arduino motor control for dummies" pages on the web,
so I'm writing one.
My truck is from a thrift shop. It has two brushed motors (about 280-350
size, in R/C plane parlance). It was originally radio controlled.
It has space for 4 AA batteries, nominal 6v, which I thought should be perfect
for the Arduino.
Connecting directly to the Arduino (don't)
First, you can drive a small motor directly by plugging one lead into
ground and the other into an Arduino digital or analog output line.
(Analog output isn't real analog output -- it uses PWM, pulse width modulation.)
Don't do this. You risk damaging your Arduino, either by putting
too much current through it (the Arduino maxes out at 40ma per pin, 200ma
total; a small motor can pull several amps), or from
the motor stops.
Lots of Arduino-oriented shops sell "motor shields". I bought a
motor shield because I could get it from Amazon and it was cheap.
It's a kit you have to solder together, but it's a very easy soldering job.
The demo code is easy, too. I wired it up to the Arduino, loaded the demo
code, hooked up my Arduino to the truck's onboard batteries, and ...
nothing. Sometimes the motor would twitch a bit, or hum, but the truck
I wondered if maybe it was something about the batteries (though they
were brand new). I tried plugging the Arduino in to the universal AC
power supply I use for testing. No improvement.
At first I suspected that the motor shield was junk because its 1 amp
maximum wasn't enough. But I was wrong -- the problem was the batteries.
Neither the truck's 4xAA batteries nor the (supposedly) 1 amp AC adaptor could
put out enough current to drive motors.
When it finally occurred to me to try
a lithium-polymer model airplane battery (2 cells, 7.4 volts, 500 mAh),
the truck immediately zipped across the floor and smashed into a chair leg.
So motor shields work fine, and they're very easy to use -- but don't
underestimate the importance of your power supply. You need a battery
capable of supplying a fairly beefy current.
But why is that, when the truck was designed for 4xAA batteries?
Well, the 4xAAs can drive the motors, but they can't drive the motors,
the Arduino and the shield all at the same time. If I power the
Arduino separately off a 9v battery, the truck will move. It doesn't zip
across the room like with the li-po battery, but at least it moves.
So I had a solution. Except I wanted something a little cheaper. A
$20-30 motor shield is fine for a one-time project, but I was also
shopping for parts to teach a summer camp class in robotics. We're on
a shoestring budget, and an additional $20 per team is a little too much.
On a recommendation from Eugene at
Linux Astronomy, who's been
teaching wonderful robotics classes for several years, I discovered
Pololu as a source of robotics
equipment. Poking around their site, I found the
Motor Driver Carrier, which is under $8 in quantity. Sounded like
a much better deal, so I ordered one to try it out.
The TB6612FNG comes with headers not yet soldered. I substituted female
headers, so it would be easier to plug in jumper wires to the Arduino
and the male leads from the motors.
Writing an Arduino program for the TB6612FNG is a little more
complicated than for the motor shield. It has two direction pins for
each motor, plus a STDBY pin you have to keep high. So there
are a lot more pins to manage, and when you change motor direction
you have to toggle two pins, not just one.
That'll make it more confusing for the students (who are
beginning programmers), but I've written wrappers like
drive(int whichmotor, int direc, int speed) to make it simpler.
The motor driver has the same power supply issue as the motor shield did:
I can't power it, the Arduino and the motors all from the 4xAA batteries.
Like the shield, it works okay with the Arduino on 9v, and great with
one li-po powering everything.
Electronic Speed Controllers
I also tried using ESCs, the electronic speed controllers I've used
with radio controlled airplanes. You can talk to them using the Arduino
Servo library (there are lots of examples online). That works,
but there are two issues:
- ESCs all have wierd proprietary arming sequences,
so you have to figure out what they are (e.g. run the voltage up to maximum,
hold there for two seconds, then down to zero, then hold for two seconds,
then you're ready to drive) and write that into your code. If you switch
ESCs, you may have to rewrite the arming code.
- ESCs only go in one direction -- fine for driving a truck forward,
not so good if you need to drive a steering motor both ways.
I'm sure ESCs have the same battery issue as the other two options,
but I didn't even try running one off the AAs.
Anyone who has ESCs sitting around probably has beefy batteries too.
All the cool robotics hipsters (cHipsters?) buy H-bridge chips
and build their own circuits around them, rather than using things like
motor shields or motor drivers.
circuit by Bob Blick is one popular example.
(Those double-transistor-in-a-circle things are Darlington transistors.)
But a web search like
arduino h-bridge circuit turns
up other options.
For driving big motors, you definitely need your own H-bridge circuit
(or an ESC), since all the available motor shields and drivers are
limited to 2 amps or less. For small motors like my toy truck,
I'm not sure what the advantage is. Except being one of the cool cats.
- For any sort of motor, either use a beefy battery (lithium polymer
is idea, but you need a special charger and safety precautions for them),
or use separate batteries for the Arduino and the motors.
- Motor shields are the easiest and most turnkey option.
- A motor driver is cheaper and smaller, but slightly more hassle to use.
- Use an ESC for big motors that only need to go in one direction,
or if you're already a model airplane junkie and have some lying around.
- Use a custom H-bridge circuit if you're a cHipster or you have a
really big motor project.
[ 13:45 Feb 11, 2012
More hardware |
permalink to this entry |
Tue, 07 Feb 2012
I've wanted an
for a long time. It's just so cute -- it's an Arduino compatible
that's barely bigger than the Atmega 328 chip driving it. Plus, it's cheap:
$10 including the chip.
Like most small or low-cost Arduino clones, the Ardweeny doesn't have its
own USB connection; instead, you use an adaptor such as an
which slides onto a 6-pin header on the Ardweeny.
I knew that ahead of time.
One thing I hadn't realized was that the Ardweeny gets its only power
from the USB adaptor. So if you want to use an Ardweeny by itself
with no computer connection, you need a regulated 5v power supply.
Those are easy enough to build (see the
Arduino), but don't forget to allow for that when designing projects.
The Ardweeny comes as a kit that needs soldering -- something that
isn't made clear in the sales literature, though for the price, it didn't
surprise me. I downloaded the Ardweeny
soldering steps (PDF) and got to work.
Easy initial build
The PDF estimates 15 minutes for the construction. The first part,
soldering the 10 components, was a snap, and took maybe 10 minutes.
At this point you can take the Ardweeny and nestle it down over the
Atmega chip, and test it to check your soldering work.
I plugged in my FTDI Friend and the LED immediately started blinking.
Success! (It's nice of them to pre-program the chip with blink code,
so it's easy to tell it's working.) Downloading my own version
of the blink sketch (use the Duemilanove w/Atmega 238 setting,
or atmega328 if you use my Makefile) also worked fine.
The last step: soldering the legs
Except that I wasn't done. The next step of the build is to solder all
28 legs of the Ardweeny directly to the Atmega chip's legs. Scary idea
-- won't all that heat kill the chip? But the instructions didn't have
any warnings about that. I took a deep breath and forged ahead.
This part put me way over the 15-minute estimate -- 28 pins is a lot
of pins, and I took it slowly, careful to be sparing with heat and solder.
When I was finally done, I plugged the FTDI Friend back in and
... nothing. Not a blink. And when I checked voltage on one of the V+
pins versus the ground pin, it measured around 1.5v, not the 5v I
expected to see.
So I'd messed something up. Somehow, even though it worked without
soldering the legs, that additional soldering had broken it.
I went through all the pins with a voltmeter checking for shorts,
and tested everything I could. Nothing obviously wrong.
It might have been nice to inspect my solder joints on the Ardweeny --
but once the Ardweeny is soldered to the chip, the solder is all inside
and you can't see it. But anyway, I'd tested it and it had worked fine.
Detaching the backpack from the chip
So I figured I must have destroyed the chip with heat or static during that
soldering process. My Ardweeny was a brick. Nothing salvageable at all.
Unless -- if I could somehow de-solder the legs and pull the two apart,
I could use the Ardweeny with another chip.
But how do you de-solder 28 legs? I tried a solder sucker (a
pen-shaped vacuum pump) and de-soldering braid, but neither one
broke the bond between the two sets of legs.
I tried sliding an X-acto knife in between the Ardweeny's legs and the
chip's while heating the leg with solder; no luck, the knife blade was
too good a heat sink and the solder never melted.
Dave finally found a solution. With my assurance that the chip was
probably dead anyway, he rolled the Ardweeny on its back, and used
the tip of the heated soldering iron to bend each chip leg inward away
from the Ardweeny leg. When he was done, the chip looked bent and sad,
like a squashed millipede -- but the pieces were separated.
Testing to find the problem
And now I could take the Ardweeny and stick it on an Atmega 328 I
pulled out of another Arduino. Plugged in the FTDI Friend and -- nothing.
Wait, it was the backpack that was bad? But I tested it before doing that
last soldering phase!
I took the sad squashed-millipede Atmega and carefully bent all the pins
back into shape, or at least close enough that I could plug it into a socket
in my Diecimila. And, amazingly -- that poor abused overheated
squashed bent 328 still worked just fine.
Okay, so the problem is definitely in the Ardweeny backpack.
Now that the solder joints were exposed again, I examined them all
and found two that looked questionable. I re-soldered them -- and
Lessons for the Ardweeny
I still don't know why my board worked the first time, then failed after
the step of soldering the legs. But it makes me nervous about repeating
that leg-soldering step. What if something else, something that's
working now, stops working?
For now, I'll probably solder just a few pins -- maybe the
four outermost ones -- and rely on pressure for the other contacts.
Of course, in a real environment where the Ardweeny might be subject
to vibration and temperature changes, that might not be good enough.
But until then, it seems the safest option.
[ 17:26 Feb 07, 2012
More hardware |
permalink to this entry |
Thu, 02 Feb 2012
I love this sign, along Interstate 5 near Coalinga.
Pleasant Valley State Prison.
I guess if you have to be locked away, Pleasant Valley doesn't sound
like the worst place to be.
Do Pleasant Valley ex-cons have a hard time getting respect when
people find out where they did their hard time?
I love picturing the local parents trying to strike fear into
their kids' hearts.
"If you don't straighten up, Junior, you're going to end up in ...
Or the local judges -- "You're not getting off this time. No, I'm
giving you ten years in ... PLEASANT VALLEY!"
[ 18:07 Feb 02, 2012
More humor |
permalink to this entry |