Archives

Date
  • 01
  • 02
  • 03
  • 04
  • 05
  • 06
  • 07
  • 08
  • 09
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

Another pedal-powered monorail: Skyride

Last year I wrote about an interesting but simple pedal powered monorail/PRT system called Shweeb which had won a prize/investment from Google. Recent announcements show they are not alone in this concept. Scott Olson, the original developer of the Rollerblade, has founded a company called Skyride Technologies to build their own version of a pedal powered suspended monorail.

You will find much that is similar between the two concepts, though they were developed independently. I will have to give Skyride the nod of picking names, though. Skyride offers both pedaling and a rowing-machine style interface, the latter aimed both at the disabled and those seeking a different kind of workout.

At present, the Skyride car is also open to the air, which has both advantages and disadvantages when it comes to cooling, drag, and exposure to the elements. Skyride does not also seem to offer the “bumper” system in the wheel cartridge which Shweeb claims will allow vehicles to safely hit one another and then push one another in trains.

Both are confined to prototype tracks for now, though the Schweeb one is an amusement ride that is open to the public. Both have plans to solve the most important problem in turning this into a real transportation system for campuses or urban areas, namely a switch that lets the vehicle smoothly and safely change tracks. Switching has always been an issue in monorails — not that it can’t be solved, but it’s just a little harder than changing lanes in a car. Rail systems sometimes put the switching in the track (that’s what regular heavy rail does) but that’s not very practical if you are going to have very frequent small vehicles. You want in-vehicle switching but with no risk of derailing.

While this concept is interesting, and even more fun if they can prove it works and then add some automation, I am not sure it will ever become a really big space. Still, having 2 companies will not doubt spur a bit more innovation.

Working on Robocars at Google

As readers of this blog surely know, for several years I have been designing, writing and forecasting about the technology of self-driving “robocars” in the coming years. I’m pleased to announce that I have recently become a consultant to the robot car team working at Google.

Of course all that work will be done under NDA, and so until such time as Google makes more public announcements, I won’t be writing about what they or I are doing. I am very impressed by the team and their accomplishments, and to learn more I will point you to my blog post about their announcement and the article I added to my web site shortly after that announcement. It also means I probably won’t blog in any detail about certain areas of technology, in some cases not commenting on the work of other teams because of conflict of interest. However, as much as I enjoy writing and reporting on this technology, I would rather be building it.

My philosophical message about Robocars I have been saying for years, but it should be clear that I am simply consulting on the project, not setting its policies or acting as a spokesman.

My primary interest at Google is robocars, but many of you also know my long history in online civil rights and privacy, an area in which Google is often involved in both positive and negative ways. Indeed, while I was chairman of the EFF I felt there could be a conflict in working for a company which the EFF frequently has to either praise or criticise. I will be recusing myself from any EFF board decisions about Google, naturally.  read more »

My phone should know when I start a trip

Every day I get into my car and drive somewhere. My mobile phone has a lot of useful apps for travel, including maps with traffic and a lot more. And I am usually calling them up.

I believe that my phone should notice when I am driving off from somewhere, or about to, and automatically do some things for me. Of course, it could notice this if it ran the GPS all the time, but that’s expensive from a power standpoint, so there are other ways to identify this:

  • If the car has bluetooth, the phone usually associates with the car. That’s a dead giveaway, and can at least be a clue to start looking at the GPS.
  • Most of my haunts have wireless, and the phone associates with the wireless at my house and all the places I work. So it can notice when it disassociates and again start checking the GPS. To get smart, it might even notice the MAC addresses of wireless networks it can’t see inside the house, but which it does see outside or along my usual routes.
  • Of course moving out to the car involves jostling and walking in certain directions (it has a compass.)

Once it thinks it might be in the car, it should go to a mode where my “in the car” apps are easy to get to, in particular the live map of the location with the traffic displayed, or the screen for the nav system. Android has a “car mode” that tries to make it easy to access these apps, and it should enter that mode.

It should also now track me for a while to figure out which way I am going. Depending on which way I head and the time of day, it can probably guess which of my common routes I am going to take. For regular commuters, this should be a no-brainer. This is where I want it to be really smart: Instead of me having to call up the traffic, it should see that I am heading towards a given highway, and then check to see if there are traffic jams along my regular routes. If it sees one, Then it should beep to signal that, and if I turn it on, I should see that traffic jam. This way if I don’t hear it beep, I can feel comfortable that there is light traffic along the route I am taking. (Or that if there is traffic, it’s not traffic I can avoid with alternate routes.)

This is the way I want location based apps to work. I don’t want to have to transmit my location constantly to the cloud, and have the cloud figure out what to do at any given location. That’s privacy invading and uses up power and bandwidth. Instead the phone should have a daemon that detects location “events” that have been programmed into it, and then triggers programs when those events occur. Events include entering and leaving my house or places I work, driving certain roads and so on.

And yes, for tools like shopkick, they can even be entering stores I have registered. And as I blogged at the very beginning of this blog many years ago, we can even have an event for when we enter a store with a bad reputation. The phone can download a database of places and wireless and Bluetooth MACs that should trigger events, and as such the network doesn’t need to know my exact location to make things happen. But most importantly, I don’t want to have to know to ask if there is something important near me, I want the right important things to tell me when I get near them.

TVs should be universal, not remote controls

Like me, you probably have a dozen “universal” remote controls gathered over the years. With each new device and remote you go through a process to try to figure out special codes to enter into the remote to train it to operate your other devices. And it’s never very good, except perhaps in the expensive remotes with screens and macros.

The first universal remotes had to do this because they were made after the TVs and other devices, and had to control old ones. But the idea’s been around for decades, and I think we have it backwards. It’s not the remote that should work with any TV, it’s the TV that should work with any remote. I’m not even sure in most cases we need to have the remote come with the TV, though I know they like designing special magic buttons and layouts for each new remote.

It would be trivial for any TV or other device that displays video to figure out exactly what sort of remote you are pointing at it, and then figure out what to do with all its buttons. Since these devices now all have USB plugs and internet connections, they can even get their data updated. With the TV in a remote setting mode (which you must of course reach by the few keys on the TV) a few buttons from any remote should let the TV figure out what it’s seeing. If it can’t figure out the difference it can ask on the screen to push specific buttons until you you see a picture of your remote on the screen and confirm.

If it can’t figure it out, it can still program the codes from any device by remembering. This would let it prompt you “push the button you want to change the channel” and you would push it and it would know. You could also tweak any remotes. But most people would see the very simple interface of “press these keys and we’ll figure out which you have.” Also makes it easy to have more than one device of the same type. But in particular makes it easy to not have so many “modes” where you have to tell the remote you want to control the TV now, then the satellite box, then the stereo, then the dvd player. Instead just tell the TV “ignore the buttons I am about to press” (for example the volume buttons) and tell the stereo to obey them. Or program a button to do different things on different devices — not a macro where a smart remote sends all the codes needed to tell the TV and stereo to switch inputs while turning on the DVD player, but just each box responding in its own way.

For outlying cases, you could tell the user to program their universal remote for some well established old devices. Every universal remote there is can control a Sony TV for example. That makes it sure the TV will know a set of codes.

The TVs and other devices might as well recognize all the infrared keyboards out there while they are at it.

Of course, as TVs figure out how to do this, the remotes can change. They can become a bit more standardized, and instead of trying to figure everything out, they can be the dumb device and the AV equipment can be the smart device. It’s the AV equipment that has storage, a screen, audio and so much more.

You can also train devices to understand there are multiple remotes that belong to some people. For example, the adult remote can be different from the child’s remote, and only the adult remote can see the Playboy channel, and is kept private. The child’s remote can also be limited to a number of hours of TV as I first suggested six years ago at the birth of this blog.

You can even fix the annoying problem of most remote protocols — “on” and “off” are the same button. This makes it very hard to do things like macro control because you can’t be sure what that code can do. You can have a “turn everything off” button that really works (I presume some of the ones out there use hidden non-toggle codes when they can) or codes to do things like switch on the DVD if it’s not already on, switch video and audio inputs to it, and start playing — something many systems have tried to do but rarely done well.

There are a few things to tweak to make sure “IR blasters” work properly. (These are IR outputs found on DVRs which send commands to cable and satellite boxes to change their channel etc. They are a horrible kludge and the best way rid of them are the new protocols that connect the devices up to IP or the new IP over HDMI 1.4, or failing that the badly-done anynet.)

But the key point here is this: Remotes put the smarts in the wrong place.

Comparing electricity to a gallon of gasoline

The “burning” question for electric cars is how to compare them with gasoline. Last month I wrote about how wrong the EPA’s 99mpg number for the Nissan Leaf was, and I gave the 37mpg number you get from the Dept. of Energy’s methodology. More research shows the question is complex and messy.

So messy that the best solution is for electric cars to publish their efficiency in electric terms, which means a number like “watt-hours/mile.” The EPA measured the Leaf as about 330 watt-hours/mile (or .33 kwh/mile if you prefer.) For those who really prefer an mpg type number, so that higher is better, you would do miles/kwh.

Then you would get local power companies to publish local “kwh to gallon of gasoline” figures for the particular mix of power plants in that area. This also is not very easy, but it removes the local variation. The DoE or EPA could also come up with a national average kwh/gallon number, and car vendors could use that if they wanted, but frankly that national number is poor enough that most would not want to use it in the above-average states like California. In addition, the number in other countries is much better than in the USA.

The local mix varies a lot. Nationally it’s about 50% coal, 20% gas, 20% nuclear and 10% hydro with a smattering of other renewables. In some places, like Utah, New Mexico and many midwestern areas, it is 90% or more coal (which is bad.) In California, there is almost no coal — it’s mostly natural gas, with some nuclear, particularly in the south, and some hydro. In the Pacific Northwest, there is a dominance by hydro and electricity has far fewer emissions. (In TX, IL and NY, you can choose greener electricity providers which seems an obvious choice for the electric-car buyer.)

Understanding the local mix is a start, but there is more complexity. Let’s look at some of the different methods, staring with an executive summary for the 330 wh/mile Nissan Leaf and the national average grid:  read more »

  • Theoretical perfect conversion (EPA method): 99 mpg-e(perfect)
  • Heat energy formula (DoE national average): 37 mpg-e(heat)
  • Cost of electricity vs. gasoline (untaxed): 75 mpg-e($)
  • Pollution, notably PM2.5 particulates: Hard to calculate, could be very poor. Hydrocarbons and CO: very good.
  • Greenhouse Gas emissions, g CO2 equivalent: 60 mpg-e(CO2)

Designing a better, faster, secure, vastly cheaper airport with proto-robocars

Like just about everybody, I hate the way travel through airports has become. Airports get slower and bigger and more expensive, and for short-haul flights you can easily spend more time on the ground at airports than you do in the air. Security rules are a large part of the cause, but not all of it.

In this completely rewritten essay, I outline the design on a super-cheap airport with very few buildings, based on a fleet of proto-robocars. I call them proto models because these are cars we know how to build today, which navigate on prepared courses on pavement, in controlled situations and without civilian cars to worry about.

In this robocar airport, which I describe first in a narrative and then in detail, there are no terminal buildings or gates. Each plane just parks on the tarmac and robotic stairs and ramps move up and dock to all its doors. (Catering trucks, fuel trucks and luggage robots also arrive.) The passengers arrive in a perfect boarding order in robocars that dock at the ramps/steps to let them get on the plane through every entrance. Luggage is handled by different robots, and is checked and picked up not in carousels and check-in desks, but at curbs, parking lots, rental car centers and airport hotels.

The change is so dramatic that (even with security issues) people could arrive at airports for flights under 20 minutes before take-off, and get out even faster. Checked luggage would add time, but not much. I also believe you could build a high capacity airport for a tiny fraction of the cost of today’s modern multi-billion dollar edifices. I believe the overall experience would also be more pleasant and more productive for all.

This essay is a long one, but I am interested in feedback. What will work here, and what won’t? Would you love to fly through this airport or hate it? This is an airport designed not to give you a glorious building in which to wait but to get you through it without waiting most of the time.

The airport gets even better when real robocars, that can drive on the streets to the airport, come on the scene.

Give me your feedback on The Robocar Airport.

Key elements of the design include:  read more »