What Transportation Needs:

What is needed is a transit system that has the benefits of both car and trains, without the problems.  If we were going to design a system to replace or dramatically augment to 100-year dominance of cars, such a system must be:

• Fast: Reduce my travel time by 2-5x, eliminate traffic, and free up an hour of my day.  What if you could get from San Jose to San Francisco in 20 minutes, New York to Philadelphia in 30, and San Diego to LA in 35 minutes, it changes everything – both where people live and where they work.
• Convenient & Ubiquitous: There is no travel time to get to your car: it’s right outside your house, or in the garage in your building.  Stations must with within a 2-3 minute walk, particularly considering weather (snow, rain, or sweating heat), packages (hauling groceries), and children.  Stations must be everywhere in an urban (or suburban) area that you need to go, not just the city center.  As a corollary, the system must be far less expensive to deploy and operate than today’s mass transit systems.
• Self Routing:  Free up travel time for work or reading by having the vehicle “drive” itself, with no need for transfers, directions, knowing which streets only go one way, or which transit routes are most congested.  Type a destination, and the system finds the optimal path to your destination.
• On-Demand: A vehicle is ready and waiting for you when you need it with little to no wait time.
• Private or semi-private: Have your own space to work and converse, without being too bothered by other riders.
• Safe: Eliminate traffic deaths.
• Quiet & Nearly Invisible: So that people are happy to have the systems by their homes, with little to no auditory or visual disruption.

This is a tall order, and exactly what “Swift PRT Inc.” set out to accomplish.  As sailing vessels and steamships opened the world for exploration, and railroads opened up continents, a new form of transportation has the potential to fundamentally alter the world.  It’s also damn hard, but we’ll get to that in good time.

Swift Concept:

A magnetically levitated (maglev) personal rapid transit system seems the logical choice for the criteria above.  Maglev is fast and can have the quick acceleration and deceleration needed to reduce travel time over the short distances of urban and suburban areas.  It’s quiet.  In fact, there are no moving parts in the mechanical sense:  the vehicle is magnetically “floated” and then a series of magnets attract and repel the vehicle to give it momentum (a linear synchronous motor).  This theoretically should reduce operational costs:  there are no bearings to wear out, nothing to lubricate with oil; the suspension is in some sense much simpler than a car or train.

User Experience:

Users walk to small stations placed roughly 500 – 1000m apart where vehicle is waiting for them.  On a touch screen map, a destination is picked, and the vehicle automatically finds the fastest route given traffic, distances, and speed constraints.  Vehicles move at up to 200 km/hr, with rapid acceleration.  Combined with advanced traffic engineering algorithms, this can provide trip times 4-5x better than automobiles, before walk time to stations is included.

Vehicle:

Vehicles are small, streamlined “pods” roughly 1.7m tall, 1.2m across, and 2.5 – 3.0m long.  The hold two people facing one another, plus plenty of storage behind the seat for groceries, bags, briefcases, etc.  Vehicles are light, weighing under 200kg, owing to the fact that they have no motor themselves, just seats, magnets, a touch screen computer, and two car-battery sized batteries.  Combined with passengers, this bounds the maximum vehicle + passenger to 500kg which is a crucial design decision.  Vehicles are connected to the track by two joints.  These joints bend, allowing the vehicle to bank with centripetal force around curves.

Track:

In order to fit into an urban area with no major changes to existing roads, buildings, or structures, the track is an elevated T-shaped guideway.  Each side of the “T” holds a different direction of traffic.

Magnetics:

The system uses a permanent magnet to lift the weight of the vehicle, and continuous alteration of the magnetic field to stay a stable distance away from the track.  If the vehicle is attracted too close to the guideway, an electromagnet decreases the “power” of the permanent magnet, and the vehicle drops.  If the vehicle drops too far, the electromagnet adds power to the permanent magnet to pull the vehicle closer to the track[6].  Because the electromagnet is simply keeping the permanent magnet at a stable operating point, in the ideal case (no resistive loss, conserving charge with a switched capacitor design or perfect battery recharding) the electromagnet does no net work.

The system is propelled by a linear synchronous motor (LSM) attached under the track.  If the magnetic suspension fails, the system falls onto auxiliary wheels.  The diagram below shows the track as an I-beam to carry load, with the copper coils of the LSM attached below.  The magnets of the vehicle sit directly under the coils (not shown) and connect to the vehicle through the slot.  The auxiliary wheels ride on either side of the slot.

Stations:

Vehicles exit the main track and descend to a ground level station.  The station itself is comprised of multiple vehicle bays.  Passenger enter the vehicle, close the door, hit their destination on a touch screen map, and the vehicle backs out a few meters, then ascends back up to the main track or does an ascending U-turn if traveling in the opposite direction.

The entire station is meant to fit within width of 4 meters, and have variable length.  In most places, this means the station is carved out of 2-3 existing on street parking spots, with a glass roof for weather protection, and a wall behind to protect the station from the road behind.  In other words, there is not much to each “station”; stations are just slightly larger than a typical covered sidewalk bus stop.

Key Decisions:

Having been exposed to the Swift concept, it’s important to understand why each key design decision was made to understand the tradeoffs.

Suspension:  Maglev vs. Wheels

Maglev was chosen for the suspension system as it is quiet – there are no motors, no wheels on pavement or wheels on track.  The only sound is the sound of pushing air.  This is very desirable in an urban area where you want ubiquity.  Maglev is quieter than cars, and far quieter than trains.

The system is also designed to be entirely computer operated, and have very little maintenance.  Wheels have bearings, treads, and lubrication that need periodic replacement.  Swift has wheels used only in power outage emergencies.

Finally, wheels impose an additional drag force that (at least in the case of steel wheels on steel track) scales linearly with velocity.

Guideway:  Elevated or Not

Ground-based transportation systems must compete for space with existing infrastructure: roads, trains, and pedestrian sidewalks.  Further, they suffer from the 2-dimensional intersection and queuing problem: whenever two roads cross, you need traffic lights, stop signs, or a round-about to prevent collisions on this shared resource.  This slows down transit time tremendously.

Restricted access highways solve this problem with under-passes and over-passes.  However, for a ground-based transportation system, such under-and-over passes are expensive to build, as they require moving many tons of earth to create ramps and artificial hills.

An elevated guideway solves the 2-dimension queuing problem, and if done in a lightweight way, makes under and overpasses much easier that in heavy ground transit.

Perhaps the most important reason to use an elevated guideway, however, is solving the “right-of-way” issue.  An elevated guideway with support columns only as thick as telephone poles and similar spacing does not need to buy large swaths of land; just tiny 50x50cm posts every so often.  This leaves the ground area free for roads, pedestrians, and existing infrastructure, with the future hope that as the need for roads is lessened, more of that land can be transformed into parks and outdoor space.

One deployment strategy is simply to replace existing telephone/power poles with the Swift structure, extending the support columns up further than the track to string power-line.  This gives Swift the rights of way needed for a municipality, and allows the municipality to modernize and improve a messy power-line / communications wiring infrastructure at the same time.

Vehicle Position:  Under or Over the Track

Most of us are used to vehicles sitting on top of a track.  After all, that’s the way cars and trains work.  This notion is likely so common it may not occur to most that there is another place to put the vehicle: under the track.

Swift’s maglev system works through attraction rather than repulsion, so the vehicle is actually pulled up towards the track.  While one could use a wrap-around design and keep the vehicle above the track, there are a number of reasons why, once we have decided to use an elevated guideway, vehicle below the track makes more sense.

First, it reduces the amount of track needed.  A vehicle above track or on a road must have a wide base, such that the center of mass does not tip the vehicle over laterally, particularly when cornering.  This means either a wide track, or two tracks in parallel for stability (like a train).  By placing the center of mass under the track, it can be supported stably from a single track.  This reduces expense and visual impact.

Second, vehicles can corner faster.  If we provide a hinge between the magnets and the vehicle, the vehicle with automatically bank on a turn with centripetal force at exactly the angle needed to keep the force of the turn down through the riders spine.  This avoids lateral jerk (and shoulder into the door) one gets when cornering too quickly in a car.

Third, by hanging underneath a track, the vehicle can approach the perfect streamlined body “teardrop” shape to reduce aerodynamic drag, something that is not possible when moving on top of the track where the bottom of the vehicle is roughly flat.

Lastly, it makes switching much easier, and faster.  In fact, no mechanical switching is needed at all – magnetic force pushes the vehicle over to the new track to complete the switch.

Weight & Riders Per Vehicle:

Weight is perhaps the biggest parameter we have to modify.  Most research and development for the past 150 years has been on trains or bus-like structures carrying 50 – 1500 people at once.  Such systems are heavy: the average locomotive weighs 100 – 250 tons, train car 67 tonnes[7], and even “light” rail cars weigh 45 tonnes[8].  Large systems require massive guideway structure, large columns, and are visually heavy.

By restricting the number of riders to a maximum of two people, we handle 90%+ of all travel (remember that the average car ride carries 1.2 people) and reduce weight to a minimum.  For groups of more than two people, vehicles can be routed together to arrive at the same time.  One could even use close circuit cameras to allow communication and conversation between vehicles.  This would be done with a combination of fiber optics along the track that are needed for control signals anyways, and periodic wireless installations.

Lower weight means smaller motors and cheaper power electronics.  To accelerate 500kg at a quick 3.0 m/s² up to 200 km/hr requires a maximum 100kW (134hp) electric motor for each electrical block in the system ($2 – 3k in cost).  Smaller motors are inexpensive and can be mass-produced.

Lower weight means a flyweight guideway.  Carrying 500kg is trivial: concrete and steel have strengths above 100 kg/cm², so support columns can be quite small.  Even small I-beams 10 cm in height have no trouble supporting 500kg.  The real issue is one of stiffness, as beams bend in the middle, and bending increases with the cube of the distance spanned between support columns.  Stiffness dictates that we will likely need to use a 30cm tall I-beam for spans less than 20m, and use a truss or cable-stayed structure for any spans over 20m.

What’s Different Now?

One of the questions I like to ask about any supposed innovation, or major improvement to an industry is: Why is this solvable now?  Why was it not solved in the past?  What has changed recently to make a new solution dramatically better than what existed in the past?

First is a materials innovation.  Neodymium magnets have the highest permanent magnetic field strength of any known material at up to 1.4 Teslas.  They were invented only in 1982 (by General Motors and Sumitomo Special Materials).  In contrast to permanent magnets, most existing maglev research in German and Japan is ultimately incremental improvements on 1960’s electro-dynamic technology.  Previously, it was assumed only electromagnets, generated on the track and on the train to repel one another, would be strong enough to produce a wide magnet gap for levitation.  If the magnetic gap is too small, deflections, oscillations, and installation imprecision could cause the vehicle to hit the track.  With strong permanent magnets doing essentially all the heavy lifting, the power consumption to do the actual levitation becomes nominal.

Second is fast embedded control system with precision electronics.  Earnshaw’s theorem says that two magnets attracting or repelling one another is inherently an instable system – you cannot put one magnet above another and expect it to float there indefinitely; the slightest perturbation and it falls off to the side.  One way to combat this instability is through an active control system.  For attractive maglev, this means the permanent magnets are wrapped in copper coil (an electromagnet).  If the permanent magnet gets too close to the track, current flows one way to decrease the net magnet field causing the magnet to drop.  If the magnet drops too far, the electro magnet switches current in the other direction so that the magnetic attraction is enhanced and is pulled closer to the track.  This process is done 100s or 1000s of times each second, a feat possible only with embedded computer systems.

Third is modern routing algorithms plus GPS.  It is now possible to keep track of tens of thousands of vehicles, positions, and velocities, ensure no collisions occur, and shape routes such that minimal traffic occurs and total travel time is minimized.  The later is one of Swift’s main areas of focus.

Energy Efficiency:

The two-person, under the track, lightweight, streamlined body vehicles of Swift provide a radical improvement over the energy efficiency of cars.  Whereas cars have a 15:1 vehicle weight to passenger weight, Swift is closer to 2:1 or less.  Further, aerodynamic drag force is ½rv²C_dA, where r is the density of air, v is velocity, C_d is the drag coefficient determined by shape, and A is the cross sectional area.  Using a configuration where vehicles are 1.2m (one person wide) with passengers seating one another reduces the cross sectional area by a factor of 2x.  A drag coefficient of 0.10 is achievable, providing another 3x advantage over cars.  The net result would seem to be a 7.5 x 2 x 3 = 45x theoretical advantage.

At 100km/hr, a 3.0 m/s² acceleration and deceleration, and accounting for things like on board power consumption, and electric motor efficiency, and regeneration of power during breaking, we can get efficiencies above 300 km/liter (800 mpg) on the 5km trip below.

Route:
Total distance (m)	5000
Max speed (m / s)	27.8	100	km / hr
Acceleration / Decel (m/s^2)	3.0
LSM resistance (Ohm)	16.4E-3
Electronic power efficiency	96%
Pod:
Pod + passenger weight (kg)	500
Drag coefficient	0.10
Fluid density	1.2
Pod height (m)	1.7
Pod width (m)	1.2	Area (m^2)	1.602
Onboard power (W)	300.0
	Acceleration	Cruise	Deceleration	Trip
Time (s)	9.3	170.7	9.3	189.26
Distance (m)	129	4743	129	5000
Kinetic energy (J)	192.9E+3	0.00	-192.9E+3	0	0.0%
Aerodynamic drag loss (J)	2.4E+3	351.8E+3	2.4E+3	356.6E+3	78.3%
Onboard energy (J)	2.8E+3	51.2E+3	2.8E+3	56.8E+3	12.5%
Mechanical energy (J)	195.3E+3	351.8E+3	190.5E+3	737.6E+3
Average Force (N)	1518.54	74.18	1481.46	3.1E+3
Average current	145.2	45.4	143.4
LSM I2R loss, (W)	3.2E+3	5.8E+3	3.1E+3	12.1E+3	2.7%
Electronic transfer loss	7.9E+3	14.3E+3	7.7E+3	30.0E+3	6.6%
Total energy input (J)	209.2E+3	423.1E+3	-176.9E+3	455.4E+3	0.13	kWh
Average power (kW)	22.6	2.5	-19.1	2.4	0.014	Liters of gasoline
Average power (hp)	30.3	3.3	-25.6	3.2	349	km / liter
EI (Wh / passenger-km)	451.9	24.8	-382.0	25.3	820	mpg

 

Table 1: Energy efficiency calculations.

Simulator:

In order to understand system dynamics, a simulator was created for network construction and test under a variety of traffic scenarios.

Network Construction Tool:

Built off of Google Maps, this system allows you to lay track out with reference to existing roads and buildings, then get immediate feedback on the velocity constraints imposed by network geometry.

An example network for the Stanford University and Palo Alto downtown area is shown below, as designed by a Google Maps based network-planning tool that has been created.  Color-coding shows the maximum velocity of the network based on centripetal force limitations imposed by cornering at intersections or curved/angled segments of track.

Routing Algorithm:

After using the map tool to layout an arbitrary network, the network is transformed into a formal directed graph structure, with edges being directional track, and vertices being stations or intersection points.

As many intersections occur at right angles, a critical parameter in the network simulation is the minimum radius of curvature at a right angle.  This was generally chosen to be around 5m, roughly the same as a car performing the same right angle turn on a street.  A larger radius would only be possible in areas without nearby buildings, and one of our guiding principles is that little to no existing infrastructure should be altered to put this new transportation system in.

The radius of curvature between three clockwise or counter-clockwise line segments can be calculated using the middle segment as a tangent curve.  All other curvatures can be found through an atan2 scaling of the right angle radius as the “smoothing” algorithm.

The system then calculates the all-pairs shortest path (in time) using these geometric restrictions.  This is the best possible no-traffic time from source to destination, using maximum acceleration until either maximum system velocity is reached, or maximum deceleration is needed.

Handling traffic is a very difficult problem.  It is tempting to cast this as a multi-commodity flow problem.  Unfortunately, that’s difficult for two reasons.  First, the multi-commodity flow problem with integer values (if we consider each vehicle as a separate commodity being sourced from the origin, and demanded by the destination, then all flows are the integer 1) is NP-hard.  There is no known algorithm that will always produce an optimal solution in bounded time.  Second, flow, such as in a data network like routing internet packets or time-division mobile data, is continuous, whereas vehicles are discrete: we are routing only “1 bit” one time.

While it is tempting to use purely congestion metrics (e.g. this track is 90% full, so avoid going there), this approach is also incorrect.  Even if a link is mostly full, if my vehicle arrives at exactly the right empty time slot, the link “appears” empty to me, and I can move at maximum speed.

What is needed is a time-slot finding algorithm, where a “time-slot” is that empty space (or equivalently span of time) between two other vehicles that this vehicle slides into.  Put another way, it’s finding the “gaps” to merge into on each road being traversed.

The time-slot finding algorithm developed starts at the source, carrying with it some time “slack”.  Time slack provides a window that says: “If needed, I can leave anytime between now and say 1500 milliseconds from now”, for example.  The vehicle attempts first to follow the optimal no-traffic route in time, along with the velocity profile of maximum acceleration and deceleration needed to minimize time.

At the input to each edge, slack is used to look at which open time slots could be made between [arrival time, arrival time + accumulated slack).  That is, slack can be used to slow down from the optimal speed in order to slide into an available time slot if needed.  At each link, additional slack is accumulated, such that the total slack is bounded to a threshold value, say 10%.  A 10% threshold means that vehicle routing can be up to 10% slower than the optimal no-traffic time, if needed to weave through open time-slots and find a viable source to destination timing.

The process continues recursively on the tree defined by empty time slots.  If a time slot can be found on every link from source to destination, it is claimed for the vehicle in a central database with a lazy locking mechanism.

If no successful timing can be found, the most congested links are removed from the network search, and a shortest path algorithm (the A* algorithm) is run on the remaining graph structure to find an alternative route.  In this way, we route around congested links, even if they happen to be on our ideal shortest time route; traffic has made them too costly.

The time-slot finding algorithm is similar to a greedy, bin-packing algorithm (packing time-slots together is the equivalent of packing bins) where each vehicle takes it’s own shortest possible timing.

Many heuristics can be created for when and where to take slack timing.  One strategy, for example, is to take slack (which always occurs by slowing down) on those links that are least congested, or furthest away from a known, frequently congested route.  This prevents the congestion from “spreading”; if we slowed down on the congested link, or those links leading to the choke point, then subsequently routed fast moving vehicles would have to place a large time buffer between themselves and our slow vehicle to avoid collision.  By taking slack elsewhere, velocities mismatches are minimized on busy links, leading to smaller time buffer requirements, leading to denser vehicle packing, leading to higher throughput on the congested link.  Another way to look at this is as an evening out algorithm: vehicles entering a congested area are let in at a measured pace and near perfect velocity.

Traffic:

Traffic can be generated at each station either randomly, or from the population served by that station (inferred from the population density of the zipcode, and then an n-minute walking radius out from the station).  Traffic density can either be varied by time of day (rush-hour), or spiked until the entire network saturates.

Results:

Using the simulator, plus an 18-station 25km mesh test-network covering the Stanford University / Palo Alto downtown area, sensitivity analysis can be done on a number of parameters.  For all scenarios, a large number of vehicle requests were made within a short time period to fully saturate the network and test it’s limits (precisely, 1000 requests from each station randomly but even distributed over a 200 second window).

Parameter	Default Value
Max acceleration / deceleration	3.0 m/s2
Max system velocity	60 m/s (216 km/hr, 134 mph)
Centripetal force limit	0.25 Gees
Maximum slack	10% of trip time
Right turn radius	5 m
Minimum vehicle spacing	10 m

Table 2: Default simulation parameters.

Max acceleration and deceleration were chosen such that with a 500kg vehicle plus passenger payload, total power would never exceed 100kW.

Government standards for people movers in a seated configuration specify a maximum lateral force of 0.25 g.  This is conservative, in my opinion, particularly for a system that banks optimally (since the hinged vehicle swings out while going around corners) and therefore puts the force straight through the spine/seat of the rider.

The base result is:

Network capacity	39,762 / hr
Avg. velocity over all routes	21.44 m/s
Max single route velocity	35.45 m/s
Average vehicle spacing	3.7 s
Min. single link vehicle spacing	1.9 s

 

Google Maps indicates drive time between the two furthest stations as 12 minutes.  Simulated time between those two stations never exceeds 200 seconds, indicating a 3.6x speed advantage over driving.

While the system allows a velocity up to 60 m/s (and vehicles hit this maximum for short stretches on long straight-aways), the average velocity accounting for acceleration, deceleration, cornering and centripetal force limits around curves is much less.

Average vehicle spacing is 3.7 seconds.  This number is higher than expected for two reasons: vehicles going around right-angle corners must slow down to a centripetal limit of v²/r = 0.25g, or 3.5 m/s (12.6 km/hr, 7.7 mph).  This forces fast moving vehicles behind them not to slow down, but to create an up to 10-second time buffer to prevent overrunning the slower vehicle.  The second reason is vehicle requests come in randomly (i.e. riders start their journey at an arbitrary time).  This means the time slots claimed by their vehicles are randomly dispersed.  Instead of time slots being perfectly packed, small fragmented time-slots too small to fit another vehicle appear.  This could be somewhat alleviated on busy links through an alignment procedure (like the timing stop-lights used for entry onto a freeway), however, this option can simply push the congestion to another location in the network.

Network capacity tops out at around 2200 vehicles per hour per station (there are 18 stations in the test network).

Upping the centripetal limit to 0.50 g, and allowing for more gradual curves by pushing the right-angle radius to 50m gives:

Network capacity	45,003 / hr
Avg. velocity over all routes	28.95 m/s
Max single route velocity	42.37 m/s
Average vehicle spacing	2.8 s
Min. single link vehicle spacing	1.7 s

 

We see a 14% increase in network capacity, a 24% improvement in vehicle spacing, and a 35% greater average velocity.  Of course, a 50m radius of curvature is likely impossible in urban and suburban areas where buildings near street corners likely prevent such lazy turns.

This shows the power of the simulator in optimizing and trading off any parameters from power consumption to trip time to velocity to rider comfort (based on G-forces experienced).

Fundamental Limitations:

Turns at an intersection:

Radius of curvature actually turns out to be one of the fundamental limitations in a high-speed terrestrial network (regardless of maglev or not).  Centripetal acceleration is v²/r, where v is velocity and r is the radius of curvature.  With r = 5m, we are limited to 18 km/hr at 0.5g.  Even at a radius of 50m, such as the long on and off ramps of interstate highways, our maximum speed is 56 km/hr (34 mph).  Thus, curves dramatically affect our top speed and trip time.

Single-lane road problem:

Turning at an intersection, or slowing to descend to a station, has a major impact on system capacity.  A buffer of up to 10-seconds (depending on max deceleration and max system velocity) must be put in between a very fast vehicle, and one slowing down to corner.

Instead of the naïve capacity calculation of 10m spacing, 60 m/s max velocity = 21,600 vehicles / hour, we have 1/10^th that value in actuality.  And because mass transit systems (subways & heavy rail) can carry 10-20k people per link per hour, a personal rapid transit system like Swift can never compete on single-link capacity.  In fact, the capacity of a highway is roughly 2000 vehicles per lane per hour, meaning PRT is as good as a lane of interstate highway, but likely no better.

I call this problem the “single-lane-road” problem.  For any track-based system, you effectively have a single-lane highway; no passing is allowed, and if the vehicle in front slows down, you have to slow down (or put a large enough time buffer that slowing down is not needed).  The way around this is to do what highways do: have long on (off)-ramps that can be exited (entered) at near maximum system speed, so there is no velocity mismatch with the vehicles in the “fast lane”.  The problem with that scenario is at 3.0 m/s² acceleration, and 60 m/s maximum velocity, it takes 600m to get up to maximum speed (and another 600m to decelerate to zero).  If your intersection or station spacing is meant to be <1km apart, you effectively have need two lane in each direction: fast lane, and an acceleration/deceleration lane.  The net result is you have at least doubled your track costs, and the width of your system.

Acceleration Limits:

The logical way to prevent needing two-lanes at all times might be to allow better than 3.0 m/s² acceleration and deceleration, so that the time needed to get to a maximum speed is lessened.  At 1 Gee, four times the suggested regulatory limits, acceleration to 60m/s still takes nearly 200m.

Regardless of implementation (maglev or wheel based, elevated guideway or ground level), the grid-like structure of urban and suburban areas fundamentally limits travel times for terrestrial transportation.  With centripetal and acceleration safety limits of about 0.5g, and many right-angle turns required (unless buildings are removed or track literally cuts through the buildings), we are forever physics constrained to a system average below 100 km/hr (60mph) for short trips of <5km.

Construction Economics:

Now that the simulator has given us a good feel for systems level behavior (capacity, traffic, average velocities), it’s important to look at the economics of building such a system.

Elevated Guideway:

After consulting with a couple of structural engineers who in turn talked to a number of builders, it is believed that a simple T-shaped elevated track structure for carrying both directions of track with vehicle + passenger limited to 500kg, could be built for $4m per kilometer, with 25% cost in support columns, and 75% in the track beams and trusses.  Of the $4m cost, roughly $2m is in material and $2m is in labor.  This is similar in cost to ski-lift systems, where cost runs around $2 – 3m per kilometer[9].

Track:

Underneath the I-beam support structure are the copper coils, iron laminations, and wiring needed for the linear synchronous motor.  While the initial assumption was the linear synchronous motor (LSM) would scale down with weight, the key parameter is force per unit length, as this sets the maximum currents through the LSM, and therefore the size of electro-magnet needed.  On large systems, this force is often distributed over the length of the entire train car, whereas in Swift, it is contained within just 2 meters.  In either case, the force per unit length, and the work done by an individual coil is about the same.  This results in an LSM where the

cost of raw metals alone is around $400/m (half copper coils & cabling, half steel, bolts, and attachment systems), with the installed cost likely being $1000/m.  Since we are looking at a system with two tracks (one going in each direction), this adds $2m / km.

Electronics:

By reducing the weight and keeping acceleration at 3.0 m/s², vehicles need a peak power of 100kW, and this sets the size of the variable voltage, variable frequency electric motors needed to propel the vehicle.  Electrical block spacing is assumed to be 10m, which also defines how close two vehicles can be (only one vehicle per active electrical block).

At $2000 per electrical motor, we have 2 directions * 1000 m / 10 m spacing = $400,000 in electrical motors for the bidirectional track per kilometer.  Add $100k for wiring and power conditioning, and we have $0.5m per kilometer.

It total the cost per kilometer before stations and vehicles could be as low as $7m per kilometer.  Adding a simple station, 20 vehicles per kilometer at $20k each, and amortizing the cost of a maintenance building every 10-20 stations, we take the total cost per kilometer optimistically to be around $8m.

Cost per Population:

In addition to the “empirical” studies done using a simulator, it’s important to calculate the cost to serve a particular population.

Dense Suburbia:

Let’s take downtown Palo Alto, California as an example.  Downtown Palo Alto has a population of around 15,000 people, living in about three square miles (5000 people/mi², or 2000 people/km²).  I consider this to be “dense suburbia” with plenty of apartment complexes and townhouses and single-family homes typically on less than 0.25 acres.

To put a station within 3 minutes walk, we need about 10 stations serving the area.  Capacity is not an issue: even if the entire population traveled on any given day, a single station would be sufficient.  In fact, it is likely that no single station would peak at more than 200-300 riders per hour (one leaving every 12 seconds) even in the worst case.

To cover the area with this number of stations takes at least 15km of track.  Track can be reduced to 8km using a minimum spanning tree instead of a mesh network, but then travel between two seemingly close stations must travel up the “tree” for a while, before coming back to the other station.  At $8m / km, 15km of track would cost about $120m, or $8000 per person in the population served.

To make a point of comparison, the State of California spends about $320 per person on transportation infrastructure (with potentially more federal funding coming in for major highways)[10].  That means blanketing the area with Swift track in a way that is ubiquitous enough to actually replace or greatly augment the use of cars would take 25 years worth of transportation spending.  Cost should be <$1,000 per person to have a chance at economic success.

Dense Urban Area:

If dense suburbia does not work, let’s try the densest urban area in the United States:  New York City.  Assume we are trying to replace the subway system with Swift.  The subway provides 5.2m rides each weekday, peaking just below an estimated 1.0m rides / hour during morning rush hour.  Assume that the average journey takes only 10 minutes (2-4x faster than even the express subways).  It takes another 10 minutes to route the empty vehicle back out to where it’s demanded, for a total vehicle time per person (assuming single rider per vehicle) of 20 minutes.  To handle peak rush hour then, we need 333k vehicles.

If it takes 30 seconds to enter a vehicle and type a destination, and each station can handle 2000 vehicles per hour, then we need 18 vehicle bays to keep the throughput maximized, and 1.0m peak people / hour divided by 2000 people per station per hour = 500 stations to accommodate them.  The subway has 468 stations in New York, so 500 stations (even if our rough estimate is off by a factor of two) is not prohibitive.  Nor is the number of vehicle bays per station.  Vehicles are small, and parked diagonally, can be spaced 2-3m apart.  Subway trains can be up to 180m long, enough space for 60+ Swift vehicles.  Things are looking good.

The real problem with PRT in dense urban areas is parking.  During non-rush hour periods, what do you do with 333k vehicles?  While one vehicle for every 8 commuters is far better than can be done with cars, 500 stations by 18 bays means parking only for ~10k vehicles.  The remaining 323k vehicles at 3m long would require at least 1000 km of extra track (perhaps an $8b cost for parking alone).  This compares to a rolling stock of only 6600 subway cars to handle the same traffic, a 50:1 ratio.  Parking is a major problem for PRT.

Density Requirements for PRT:

Leaving aside the parking problem, at what population density would PRT make sense?  If we have restrict cost to $1000 per person in the population being served, have a cost of $8m per kilometer, and assume that we use a total track of twice that station spacing length for each station (i.e. halfway between a minimum spanning tree and a full Manhattan grid mesh), we can calculate station spacing and average walk-times for the population being served:

City	Density (pp/km^2)	Station Spacing (km)	Avg. Walk Time (minutes)
Tokyo	15000	0.34	1.1
New York	10000	0.51	1.7
San Francisco	6600	0.77	2.6
London	5000	1.02	3.4
Dense Suburban	2000	2.55	8.5
Suburban	1000	5.09	17.0

Table 3: Station spacing & average walking time to stations by population density.

Future of Transportation:  Not PRT or Light-Rail

To replace the convenience and door-to-door speed of cars with a new form of transportation, we need a combination of speed, ubiquitous access, on-demand departure, quiet, privacy, and safety.

At perhaps $8m per kilometer (or even potentially as low as $5m per kilometer), the ultra lightweight, elevated maglev guideway of Swift can compete with the cost of interstate highways ($4 – 10m per lane per mile).  However, it cannot compete with the ubiquity of smaller streets and highways who’s cost per kilometer can be $100 – 300k.  It’s hard to beat asphaltic concrete at $17 / tonne versus $900 for steel (53x) and $10k for copper (590x).

Personal Rapid Transit and Light Rail systems simply cannot put enough stations in even dense suburban areas to beat the automobiles.  While travel time once at a station and going to another station can be up to 2x faster than cars in light-rail, or 4x faster for Swift, this improvement is killed by walk time to and from stations.

If stations are spaced 2.6 km apart, this adds an average of 8.5 min of walk time to a station.  If the walk time is the same from a station, that’s 17 extra minutes per journey.  Let’s assume that your average driving speed is 72 km/hr (45 mph), and Swift provides a 3x speed advantage (216 km/hr or 135 mph).  For any distance less than 27km (17 miles, or 23 minutes of drive time) in one direction, it’s still faster to drive.  Even halving trip times is possible only in a handful of terrible traffic locations (Los Angeles, Washington DC and New York), where commutes average 45+ minutes each way.

The real cost of transportation is mathematical:
Real Cost Public Transit = Fare + Salary(Time to station + Time from station to destination + Transit time + Wait time for train)
Real Cost Auto = Distance * Cost Per Km + Parking Cost + Salary(Time to park + Transit time)
These equations cross in favor of public transit only when stations are ubiquitous (<5 minute walk away) and the wait time for a vehicle/train is nominal, or the cost of auto transit goes up 3-4x it’s current $0.21 / km.  Otherwise, it’s cheaper to drive.

Station ubiquity in turn is only economical for regions that have population density above about 5,000 people per square kilometer.  This may be why taxpayers, rather than riders pay 90% of the costs for light-rail systems, which are typically deployed in low-density urban areas.  Across all light-rail systems, cost per passenger mile runs about $1.20 versus $0.34 for a car[11].  Add in the time factor to get to a station, and the real cost of public transit outside dense urban areas is much worse.

Future of Transportation:  Self-Driving Cars

We live in a world designed around cars.  Because world population has grown five-fold during the age of cars, we will be stuck with their legacy in roads and low-density metro configurations for at least the next century.  This realization is a difficult one – I set out to start a company that could radically transform transportation.  But neither the physics nor economics work out, and in fact will not work out until population density is much higher[12].

It is the ubiquity of roads, more than the greatness of cars that is difficult to defeat.  And so, the future of transportation is, perhaps disappointingly, simply better cars.  Our abstract criterion for the perfect transportation system is one that is fast, ubiquitous, has on-demand departure, and is quiet, private, and safe.  The solution to all of these is a self-driving car.

In a test done back in 1997 with normal vehicles (Buick LeSabres) whose throttle and breaking was put under computer control, a group of vehicles was “platooned” together in groups of 10 with car-to-car radio controls.  Spacing of just a few meters could safely be established, with automated merger to the back of the platoon, and exiting the platoon for departure[13].

Such systems would allow highways to go from 2000 vehicles per lane per hour to 4000 or more, effectively doubling the capacity of highways.  In a platoon configuration, air resistance is cut by up to 35% (with corresponding improvements in fuel efficiency).  If the cars were electric, quieter operation could be realized.

The future is a self-driving, tight-following vehicle that routes itself according to traffic patterns to minimize total drive time across all travelers, that parks itself, or returns like a taxi to pick up its next passenger.  The last point is particularly salient: self-driving cars can be like taxis – you don’t need to own the vehicle, there simply needs to be one that can pick you up at a moment’s notice.

Next Steps for Swift:

It is clear that a maglev based personal rapid transit elevated track system should not be pursued as a business.  The routing and traffic contention algorithms, however, are likely the same system-level optimization algorithms needed for self-driving cars.

If anyone has plans to create a device that can plug into the cruise control or computer system of any late model vehicle to provide driverless operation (perhaps Google’s Self-Driving Car will license or open-source their vision system), do traffic routing from a central traffic database, and do car-to-car wireless signaling, let me know (apatzer (at) swiftprt.com).  This is something I’d like to fund, participate in, or engineer.

Until then, it’s back to the drawing board with a next venture.  At three months of research, and three months of non-stopping coding, this was a fast failure, and worthwhile fun.

---