Solar Car Strategy

One of my jobs over the past couple of days has been to program a weather data feed for the solar car. (The race is in twelve days! More on that soon.) After a lot of looking, we settled on NOAA's Global Forecast System as our source.

the world, simulated. thanks NOAA!

(That, by the way, is a really cool system. It gives you everything that's going on at any point on the globe, in three hour increments, from right now to more than a week in advance. By "everything", I mean everything from the chance of rain to "soil porosity" and "total cloud water (atmospheric column)." They run the simulation four times a day. That means that the NOAA guys crank out gigabytes of data every six hours, and anyone can just go there and download it.)

For the World Solar Challenge, we're interested in two things: the amount of power we're going to get (or as NOAA likes to call it, "downward shortwave radiation flux") and the amount of headwind or tailwind.

solar power, in W/m^2

The only problem is that the race is one one of the most remote highways in the world. We're bringing extra fuel canisters so that our vans make it from one outpost to the next. Those gigabytes of real-time data aren't going to get there. Instead, we're bringing a satellite phone, which gets us a couple kilobits per second--1991 style--and at exorbitant cost. Sasha calculated that loading Gmail would take more than an hour and cost $400.

To get around this, I wrote a script that runs at regular intervals on my server back in California. Each time, it downloads the latest weather data and parses out only the variables we care about, does a little bit of voodoo, and samples them roughly every kilometer along the race route.

Plan A was to compress the output into a hackish text file. I'd output one line for each waypoint along the route, and each line would have one character per forecast: the first character would be the amount of sun we're getting now, the second would be the amount of sun we expect in three hours, and so on for the entire six-day race.

~3000 waypoints * 60 forecast times * 1 character per value = 180000 bytes. 180 kB. Doable over a satellite phone! Still, I forgot the obvious part: the weather at one point in the middle of nowhere in the desert is very similar to the weather a kilometer away, or a kilometer after that... as a result, many of the lines in the script output were very similar to each other. Not optimal. So I tried something else...

scriptin'

Plan B was to round each value to the nearest integer, then write them as a regular text file. Number, comma, number, comma, on every line, one per waypoint.

Then I zipped the file and made it available for download. Much easier, and fewer moving parts since we can just open the zip file with software we already have. As Donald Knuth once famously said,

premature optimization is the root of all evil.

Simplicity rules.

Tomorrow at the crack of dawn (according to Sasha), we are leaving for Adelaide, then for Darwin. I'll post when I can, but internet will be spotty. In fact, internet access sucks in Australia, in general. More on that later. Peace!

I'm in Sydney

...on my way to Melbourne. Jesus, Australia is awesome. I think even the bag claim conveyor belts go counterclockwise here.

Over the next few weeks, we'll be putting as many miles onto the solar car as we possibly can, and then we're racing. It's the World Solar Challenge--from Darwin to Adelaide, across the outback, sun power only.

(The car, just before shipping, with about half the solar panels on. Taken a few weeks ago by Nathan.)

I'll be blogging from the road, of course, and on the trips to New Zealand and Thailand some friends of mine and I are doing afterward. Nathan has some great pictures of the solar car on his blog (which he started writing just for this trip, and which I'm sure will be excellent). If we have time, we'll throw some content on the Stanford Solar Car team blog, too. And Wired.com's Autopia did a post about us a few weeks ago.

Peace!

Drive-By Journalism

So I was cruising down the boulevard in the Stanford Solar Car last Thursday. I was the middle car in a three-car convoy. Cars would slow down as they passed by to do a double take on our carbon fiber contraption.

One guy pulled up next to me and started taking pictures. The "experimental prototype" he snarks about is the car we're taking to Australia, and "Solstice" is the old model, this one's Apogee. Cool pictures, nonetheless. And mad props to Mr. Zbrozek for digging this up.

And if you want more production value and more ridiculous commentary, Wired.com did a post about us, too.

More pictures forthcoming!

Finding the Next Dot-Com

Its seems like everyone and their mom has a domain name nowadays, and domain squatters have the rest.

The land grab is speeding up. VeriSign says that more than 2.4m new .coms are registered every month. Virtual real estate is just a name, but domain auctions sometimes make actual real estate look cheap--and even if you aren't paying $7.4m for "business.com", a lot of domain names are expensive. If it's pronounceable, paying a few thousand bucks is apparently normal.

All this squatting and grabbing makes life harder for people who actually want to build a web presence. Just look at the names of some of the newer companies around here: Ooyala, anyone? DealKat? SaaSure? That first one reads like a misspelling of a French exclamation. The second is a misspelling. The third is a pun on SaaS, which is usually pronounced "sass", so it sounds like a lisp ("sass-sure"?).

These guys seem to have gotten what lots of people want: an unregistered domain name. Those sell for about $10, renewed yearly; the details depend on the specific TLD you want. In any case, they're vastly cheaper than domains that are already registered, whether by previous legitimate users or by squatters.

After spending half an hour recently typing stuff into whois, looking for the coveted "not found" that would tell me a name was unregistered, I found nothing. I thought: there's got to be a better way...

So I wrote a few quick-and-dirty programs that generate domain names, then used a shell script to test them automatically and pick out the unregistered ones. I wanted domains that were reasonably short and looked and sounded like English words. Since all the tricks I tried to that end rely on a large English word list, and since I didn't feel like waiting very much, I wrote these mini-programs in C++.



Attempt #1 goes through a list of English words and builds a map of all each 'syllable' along with how often that syllable occurs. For syllables, I just used all the substrings in each word of 2-5 letters that had at least one vowel. The most common were es, in, er, ed, ing...

Then, I combined two syllables at a time, starting with the the most common and the second most common: esin.com, ines.com, eser.com, eres.com...

The names got a bit more complicated after that, but they weren't very wordlike. Worse, the first 1000 were all four or five letters long, so despite sounding like gibberish, almost all of them were taken.

Attempt #1 results
500 domains
53 of which happen to be in the original wordlist. None of those was available.
Of the remaining 447, 2 were available: 0.4%

I needed something better...



Attempt #2 is a Markov model of the words in the dictionary. After a bit of experimenting, I decided to use a Markov model. For every three-char sequence in the input word list, I kept track of all the characters that come next. I included the null character at the end of each word, to model the length of English words as well as the characters they're made of.

To generate names, I sampled the most common three-character sequences at the beginning of dictionary words. For each sequence, I randomly picked from the characters that could come next, and repeated that until I got to a null character.

This one worked a lot better:

dislew.com
comm.com
trati.com
fore.com
staying.com
impo.com
recre.com
stri.com
gravel.com
miss.com
...

I especially like comm.com. Maybe a communications or PR agency? It's a sweet domain.

These names were generally a bit longer, but pronounceable. A lot more of them were available--it seems like raw length is what the squatters really care about.

Attempt #2 results:
500 domains
122 of which happen to be in the original wordlist. None of those were available.
Of the remaining 378, 61 were available: 16.4%

Possibilities abound. I could..

• Artificially crank up the probability of the null character for every seed in the Markov model, to make it produce shorter domain names while still trying to keep them wordlike.
• Exclude long words from the wordlist and then build the Markov model, also in an effort to produce shorter domain names.
  
• Use the Markov model to generate two words at a time, and simply concatenate them, also to get more compound-word domain names.
  
• Repeat the experiment for languages other than English.
• Run a bunch of popular domains and less popular ones through the Markov model to see how they score. Are domains that look like words more popular than those that don't?
• Compare some sites with a lot of direct traffic (people typing the domain into their URL bars, instead of going through a link or a search engine) and see if those tend to be more wordlike than their less typeable counterparts.

I might try some of this stuff. If I do, I'll keep you posted. Peace...

I'll be BAWK

Last weekend, we went on an epic roadtrip through California.

It's an annual section leader tradition, and this was its fourth year. On Friday afternoon, we piled into cars with food, sleeping bags, laptops, and cameras, and started our trip. The goal? Solving puzzles and getting places as fast as possible. BAWK is framed as an adventure game. The theme? Always a B-movie. This year it was Cannibal Women of the Avocado Jungle of Death The route? TBD. We go nowhere fast, then hang out and have fun.



It turned out that we were driving from Stanford to within 90 miles of Mexico on that first afternoon. It was a beautiful drive through the Sacramento Valley and the Mohave Desert.

Stop 1: the Salton Sea.



A rainbow on the way to Dinosaur Point (San Luis Resovoir).

We camped on the Salton Sea our first night. In the morning, we went to an abandoned trailer park that had sunk into a wet marsh. Pictures coming soon.



Antelope Valley California Poppy Reserve.



Joshua Tree National Park.

On the way back, we made it to Big Sur before sunset. It was gorgeous.



Brandon, the B in BAWK and roadtrip planning genius.



The sun.




The sea.





The beach. We swam here.

I love the desert. I love the backroads, the cogs under the surface of society, the small towns that grow our food, transport our goods, generate our electricity. I love the freedom of driving with friends through the middle of nowhere, going wherever we want to go.



California is beautiful.

Winning science fairs

... I've never done it, but I did get a "third award" at Intel ISEF '07. That's International Science + Engineering Fair, and it was one of the most fun things I've ever done. My friend Tom and I built the project, took it to regional fairs, improved it between each fair, and of course partied the nerdy way for a week at the main event. Our project was on Stirling Engines, building four from scratch. The last two worked.

We built the engines using parts from my garage and from Home Depot. The last engine also included two borosilicate glass-graphite piston cylinders generously donated by Airpot. The Riverton Science Department hooked us up with real-time pressure and rotation sensors. The end result was an engine that could run on a candle and a faster one that ran off of a propane stove; we measured the thermodynamic cycle of the second engine, creating and experimental PV diagram.



My partner-in-crime Sawyer just facebooked:

Hey! You went to ISEF a while ago, didn't you? Any advice on choosing a project?

Sure! In my unhumble opinion, engineering is the way to go.
Pick something fun or cool, because then you'll spend time on it and make it great. Also, pick something that you can build. I have way better experience with that than doing pure science or math, at least in the context of a science fair. (Science fairs are really science/math/engineering fairs; I like the engineering part best.) If you do pure math or science, then you'll need a mentor. Many entrants in those categories, even at Utah-level fairs, partner with university professors; needless to say, it's very hard to compete if you're going it alone. Building stuff is different; you need a lot less arcane knowledge. I wrote some of the programs I'm most proud of before I had any formal CS training; my friend Nathan built a car -- from scratch -- that does 0-60 in under four seconds -- before he went to Stanford and took introductory mechanical engineering. If you're excited about it, if you persevere, and if you're willing to use Wikipedia a lot, you can learn as you go and build really cool stuff.

I also recommend building something physical. You can enter a computer science project, but you'll have plenty of chances to code. In my experience, the clubs, groups, and other orgs you'll be part of in college never have enough programmers. Web developers are especially in demand -- you'll spend lots of time sitting in front of a screen hacking apps into existence. Science fairs are your chance to design, machine, tinker with, and generally build stuff, and get recognition for it. Companies sponsor you. Teachers love it and are often very helpful. It's a very good deal, and one you really don't get once you're out of school. I can't overstate how great an experience my project was. Find something interesting and build it. You'll rock the science fairs and get more out of it than you can imagine.


(Tom and I at Sandia National Labs. One of our judges invited us to come see his project there: harvesting solar energy with Stirling engines. The dish focuses sunlight onto the hot end of a 25KW engine. The other side is cooled with a radiator.)