I was originally somewhat enthusiastic about the possibilities for self-driving cars, because (in theory), they would make it much easier to carpool and/or run point-to-point transit instead of one-large-size-fits-all buses on inflexible routes.

But then, I thought about how much these cars would initially cost, and who their initial market would be. Early adopters are not buying this buying it to carpool; they’re buying it so that they can get work done on their horrible long commutes.

And then I read that Google thus far had only made it work by mapping Mountain View down to the last detail, and mapping is labor-intensive. Getting the rest of the country mapped is going to be costly. On the other hand, with their algorithm, unless you have the data, you don’t have a self-driving car. How convenient for Google. But how to get the data?

And then I realized that it gets back to the first customers — if their main value from the car is for their daily commute, which is repetitive (probably) long, if a self-driving car is instrumented well enough to record the route, the early adopters will buy the cars, train it for their commute, and it will ship the road data to the mother ship. After some small number of training runs the car can drive itself — not everywhere, but on the commute, and for each customer, that is what is important.

Note that this is far from the crazy utopian vision of self-parking cars that deal with that particular hassle, and it’s not cars traveling bumper-to-bumper in an energy- and road-space conserving pack, and it’s not cars automatically negotiating their way through signal-free intersections — it’s for the commute. Eventually this will lead to enough mapped roads to actually count as “coverage”, and people will be able to buy cars and expect that they’ll know the way. But I don’t think that the cars will be programmed to optimize road use or energy consumption. Recall who is buying them and what for — the most likely goal is to drive in a way that someone riding inside and using a laptop or reading a book will not get carsick.

I’m being called in as IT consultant by my wife, who uses SPSS.
Today, mysteriously, it started INTERMITTENTLY failing with messages
like “Serialization scheme was not recognized” and “Could not instantiate a required server object”.

My snap answer (knowing that it has Java in it, and knowing that “serialization” is a magic word) was to suspect some sort of a Java version mismatch — but I didn’t see any evidence of a recent update at all. I go looking online, and all the advice tends to revolve around Java, but none of it has been updated (I looked inside the application’s package contents, nothing looked new there, there was no other new Java on the box). One thing that looked a little peculiar was in ~/Library/Application Support/IBM/SPSS/Statistics/22/Eclipse/configuration/nl/en_US/ . There, org.eclipse.osgi and org.eclipse.update had both been touched TODAY, “right around when the problems started”.

So WTFF Eclipse doing in my wife’s SPSS “Application Support”? She does not use Eclipse.

So I shut down SPSS (took it minutes at 100% CPU, ???) moved the IBM folder over out of the way (made sibling directory “NOT”, moved IBM and the other sibling SPSS folder into NOT) and restarted. This appears to have made things better.

Short trips in cars

April 9, 2014

Discussions about replacing car trips with bicycle trips often focus on commutes, and whether those are too long or too unpleasant/unsafe. However, it turns out that commuting trips are only about a quarter of all trips, and also disproportionately not-short, so this makes cycling look less practical than it actually can be. Here are bar charts, taken from data from ORNL about vehicle use in 2009, where the heights of the charts were chosen to (1) be roughly in proportion and (2) split evenly into four parts on the cumulative-amount scale. Each pair of bars shows the number of trips of a particular length in miles (blueish bar), together with the sum of all trips that long or shorter (reddish bar). The first chart, with height to scale, shows how this is distributed for commuting vehicle trips only, the second chart shows how this is distributed for all vehicle trips.

Thus, it’s easy to see that half of all vehicle trips are five miles or less long, versus commuting, where the median trip distance appears to be closer to 8 miles (extrapolating on the 5-9 scale). Note also that there are more “all trips” that are three or fewer miles long and not commutes (76.5 billion total, comprising 11.4 billion commuting trips and 64.1 non-commuting trips) than all commuting trips combined (60.8 billion).

Short trips, however, don’t amount to that many road miles. Putting people on bikes may make cities quieter, cleaner, and safer, and their riders healthier, but it won’t put that big a dent in fuel use.

Excel version of the spreadsheet used to make the charts.

Original spreadsheets from ORNL.gov.

The charts were produced in Numbers, exported as PDF (which is a vector PDF), then imported into OmniGraffle (Pro), with the irrelevant bits of the PDF quickly pruned out as objects. The four charts were then exported as SVG (which is what the “Pro” gets you).

This does not count carbon taxes (ought to be 25 cents per gallon) or pollution taxes (in the range of $1 to $1.50 per gallon, based on location) or noise taxes or crash risk to others (in theory insurance captures this, but insurance may not pay out if a smashed pedestrian or cyclist was “at fault” — but without the speed and bulk of the car, harm would have been smaller) or congestion costs. This is just the cost to build and maintain the roads. The images links to the spreadsheet containing all data and links to documents from which it was obtained; these are all government sources, either EIA, FHWA, or Federal Reserve.

No, bicycles do not tear up roads, nor do they pollute or make noise. Their crash risk to others is many times lower, and because they take up so much less space their congestion costs are correspondingly lower.

It is common to read car aficionados claim that people on bicycles don’t pay “their fair share” of the roads, even though anyone with a lick of sense would worry that a gas tax not adjusted for inflation since 1997 might not be covering costs — right now, it’s only covering about half, and the rest comes from other taxes.

However, it is also true that cyclists don’t pay any tax or user fee specifically targeted at the roads; sure, the drivers are 50% subsidized by other taxes, but cyclists are 100% subsidized (that the subsidy for drivers is four orders of magnitude larger(*) is irrelevant, of course, we’re talking about the principle here). This compromises our smugness, and that cannot be allowed. We must devise a user fee for bicycle riders, and pay it. Furthermore, we must not just pay 50% of costs; we should pay 100%, so that we may remain the smuggest of the smug. It may be a high price, but for smug, it will be worth it.

The best route for administering this user fee is through bicycle tires. Bicycles don’t run on any special fuel, but they do consume tires at a steady pace, and there is even some correlation between the size of the load and the size of the tire — larger tires, expected to carry heavier loads and last longer, could be assessed a higher fee.

How much should this fee be? The standard, conservative formula for road wear is that it is proportional to miles driven times the sum of the cubes of the weights on the wheels — that is, a 3000lb car with 4 wheels has 750lbs per wheel. Cubed and summed, the result is about 1.7 billion (1.7e9).

A moderately heavy cargo bike might weigh 400lbs, or 200 per wheel. Cubed and summed, you get 16e6, or about 105 times less. That car might get 25mpg in city driving, and pays an average tax of about 50 cents per gallon, or 2 cents per mile. Given that this is only 50% of cost, the full price would be 4 cents per mile. (Yes, gas taxes ought to be $.50 per gallon higher, if we are to stop subsidizing car use from other revenues. Can’t you feel a good smug coming on?). Since the bicycle does about 100x less damage, a fair user fee for a cargo bicycle traveling 1000 miles would be about $.40. In my case, at about 2500 miles per year, a whole shiny dollar. Per-tire, since a tire lasts about a year for me, $0.50.

However, my calculations are not exactly fair to all the non-cargo bike users. Someone who weighs only 170lbs riding a 30lb bicyle has only half the weight per wheel as my bike (when well loaded), and thus does only one eighth as much road damage — that is, $0.05 per 1000 miles. To account for this, I would tie the bicycle user fee to the tire size, since that correlates loosely with load; for a 60mm tire, it should be about $.50, but for a 30mm tire it should be closer to $.10 or perhaps even less. Perhaps a tiered pricing scheme would be best — $.50 for 60mm or more, $.35 for 50mm or more, $.20 for 40mm or more, $.10 for 30mm or more, and $0.05 below that, because those tires wear out faster and their users tend to be lighter yet. (Fine tuning these numbers might take a little more analysis, but they are clearly in the ballpark.)

It’s a stiff price, but I think it’s necessary to preserve optimum smugness and superior attitude. We’ll pay our full share, not just our fair share, and we can look can drivers in the eye again and say “hah! who’s the freeloader now?” We can call the highway department, “goddammit, I PAID MY ROAD TAX, why aren’t these potholes fixed?!” It will be awesome.

(*) back-of-the-envelope estimate — about 100 times as many people putting serious miles on a car as putting serious miles on a bike, and a bike is at least 100 times less damaging to the road, and a typical car is driven at least 3 times further. Roughly, 30,000x more road damage done by drivers, assuming they’re all driving average-sized cars.

This is the plan, anyhow. N-1, I designed long ago, finally built, and with the exception of broken wires, a confuso (OVERFLOW vs OVERVOLTAGE), and a units error (4000Hz “ticks” versus 1Hz “seconds”), it appears to work. The only remaining mystery is why not all the zero crossings are detected; I went so far as to determine that the cause is on the analog side, and I think before I worry too much about it I will check to see if it matters, or if I can fix it in software.

So, why do I think this one is better? First, it is not sensitive to the LED load; it just runs whatever you put there, pulling the right amount of current form the hub. Second, it has a switchable doubler, so the lights come on at low speeds, but then the doubler turns off at high speeds for more efficiency and less need to limit current. Third, you can do whatever the heck you want with timing and flashing patterns. Fourth, on the advice of Wiley, it uses screw-down terminals, which is a good thing (most first controller just died, from a corroded+broken wire) and allows easier repairs in the field. Fifth, it has “everything”; it can be reprogrammed in place, it can supply at least a half-amp of 5V current for phone charging, it has an optional input for solar panels if that’s what you want, it has a shunt for overvoltage protection, and it has a switched optional input for batteries (or capacitors) for a standlight.

The prototype (which proved most of this would work) has several flaws; among them, I was still suffering from the delusion that I could stick it in side a frame tube. That’s not such an awesome idea. Making it in one compact lump allows all the capacitors to be lashed down tight, allows the screw terminals, and reduces the need for extra wires. The whole thing is relative compact — 5cm by 10cm, with a bit of the BuckPuck sticking off the end, and the capacitors piled about 3cm high.


And there’s a wee bit of software….
Read the rest of this entry »

Lights for a beater bike

December 23, 2013

A first effort at writing this up, if you’re interested and it’s unclear, ask questions.

I’ve never been 100% happy with the packaging on home-made lights, but glueing power LEDs to aluminum angle iron with a mirror on top works pretty well and gives you some options for mounting (for example, using long bolts to bell brackets). On a bike with a front basket, however, the basket itself is a natural place to mount not only the light, but also most of the wiring, so inferior packaging is not such a big deal.

To start, here’s what the bike looks like with lights installed, showing the basic arrangement of the basket, hub, wires, and tail light.

Beater bike with hub-powered lights mostly mounted under Wald basket.

Note that there’s no off switch and no way to disconnect anything but the hub without wire clippers or a soldering iron. Why build it like this? #1, eliminating connectors and switches eliminates sources of failure. #2, daytime running lights turn out to be useful. From the OECD, Cycling, Health and Safety, p. 170 (pdf):

The safety effect of daytime running lights on bicycles was tested in a Danish study in 2005 (Madsen 2006). Nearly 2,000 cyclists in the town of Odense used the new induction lights (flashing type) for one year with, while 2,000 others continued with ordinary bike lights, which were only switched on during dark hours. The accident frequencies of the two groups (based on self-reported accidents) were then compared and analysed. … The main result was that use of daytime running lights was associated with a reduction of the number of crashes by more than 30%. The number of related crashes (crashes in daylight and with a counterpart) decreased by 50% approximately. Both results are statistically significant. There are indications that the study may have not controlled for all factors – for instance it is unclear to what extent the control group’s crashes included single vehicle crashes (this type of crash is hardly influenced use of induction lights). Also, the study makes no finding as to the safety effect of flashing versus steady lights.

The photo below shows the basket from the other side, and on Flickr it is annotated with notes on some of the parts, but the basic idea should be clear; there’s room under a basket, and plenty of stiff wires that can be used for mounting zipties. The little wooden stick is intended to adjust the level; ideally some of the light is visible to approaching traffic, but it is better if most of it is kept down low and out of people’s eyes. One problem with “beater bike” systems is that it’s not clear how much money to put unto them; for another $25, it’s possible to add a second set of LEDs on a switch that are aimed lower and with a color chosen not to be so deadly to night vision (e.g., amber, or perhaps warm white).

Side view of LED lights under Wald basket

The photo taken from below in the front shows the LEDs, lenses, mirror, wiring, and aluminum angle on which the LEDs are mounted. Note that one lens is a spot, and the other spreads its light out horizontally. The goal for the spread lens is to ensure visibility from the sides and to fill in the near part of the road.

Headlights and mirror

The “better taillight” is made from stuff I had lying around because “you never know, that might be useful”.
The clear tube is acrylic with one-inch inner diameter, and the round top is an acrylic hemisphere, held on with superglue. There’s a fancy holographic diffuser film in there from a sample sheet; not clear that is really necessary, some vertical sanding on the inside/outside of the tube might have been just as effective.

Better taillight.

Front LED: could be CREE XTE, XPG2 or XML2.

Rear LED: could be red or red-orange. Red-orange is a fudge to make the taillight be slightly brighter, but the modern red LEDs are probably adequately bright. It’s even possible to use deep red.

Lenses: Taillights don’t need lenses, but headlights do. I like to use a spot for one and an oval for the other.

Lense holders are necessary for the headlights and their lenses.

PCB for rectifier/doubler.

Diodes: SB540

Small capacitors: 1000 uF, 16V

Large capacitors: 6800 uF, 35V

Wire: I use marine-grade, 2-conductor, 18 gauge.

Mirror: 1/8″ Acrylic mirror from US Plastic

Acrylic tube

Acrylic hemisphere

Assembly hints/gotchas:

First cut mirror and aluminum angle. I sized the aluminum to fit to one side of the support under the basket — the middle seems symmetrical, but it will get dirtier there. A Next drill aluminum. Next glue mirror to aluminum, then drill through mirror. I always roughen surfaces before gluing and use 5-minute epoxy because I am impatient.

It’s good to clip the LED hexagons to a heat sink while you are soldering them, except for the tab being soldered. That protects the LED from being overheated (I ruined one that way once, though I didn’t ruin about a dozen others being careless).

Use nail polish on all the exposed electrical connections (but not on the LED lens itself) to help protect against the elements. It’s not required, but it helps.

Glue the hexagons and lenses in one operation, clamping the entire assembly. The lenses have a larger diameter than the LED pucks, this prevents you from gluing them on too close to the mirror. Be aware of the orientation of the oval beam lens — you want it wide from side to side, not from top to bottom.

Work some tape in around the headlights to help keep water splashes off the LED.

When wiring, always think about strain relief. Vibration on a bicycle is the enemy of all electronics, including wires.

The taillight is always ad hoc and depends on what your mounting options are. Gluing hemisphere to tube uses superglue in a pretty large quantity, and the superglue vapors tend to fuzz the acrylic surface (which is okay for a taillight). A bare LED works, but a little protection from bashing and the elements is better, and a larger-than-point light source is also better.


Get every new post delivered to your Inbox.

Join 169 other followers