Comments on the Automated Vehicle Control Document by William Turnbull, located at


by Sergey Prokhorenko


It is a very sensible article. Therefore, I only write about things that I don’t agree with.

Mr. William Turnbull bravely offers solutions to some important and difficult vehicle control system problems, which others have avoided. Therefore, I offer my variant of solution too.

 Mr.Turnbull deals with a system concept that offers to carry private DM vehicles. My preference is for:

       rented electric carried DM vehicles (which belong to the transport company)

       and PRT as a primary mode –

But, for American sparsely populated areas, DM may be more suitable than PRT as a primary mode.


Each [car-ferry, or unit carrier, or simply carrier] is only somewhat larger than a full size sedan, or van - one carrier, one vehicle. 

Look at the picture below. The carrier is smaller than the carried vehicle:


The design provides that the carrier can not simultaneously fully grasp both [guidance] rails. 


 sergey1.jpg (53458 bytes)       clip_image004.jpg (16783 bytes)


It is not guaranteed. The servo-driver may get jammed.

It is not clear, how the author is going to solve the problem of crossing guide rails with wheel rails. In these places very wide gaps of wheel rail are formed. These gaps are intended for passage of the guide mechanism. At speed of 80 miles per hour and without pneumatic tires, the wheel will hit strongly the edge of this gap. The top view does not show these details.

In the unlikely event that this exit distance is not forthcoming, compliant couplers on each carrier can accommodate an exit notwithstanding.

The carriers in a packet have mechanical contact. This is complicated and unnecessary. The problem of close, but safe and comfortable (without jerks) consolidation of carriers at movement in a stream is solved algorithmically. (See “Going after leading vehicle” block in the diagram below:


diagram.jpg (67923 bytes)


Safe headway between bumpers (0.15 sec) is set on the basis of the reaction time of an on-board control system for normal or emergency braking of the forward vehicle.


Approach program and safety headway maintenance program (slope of curves is conditional)


[It is published on the 23 April 2003 and is not subject to patenting]


comments1.jpg (28139 bytes)


1 – acceleration, m/sec2

2 – headway, sec

3 – safety headway of 0.15 seconds

4 – safety headway plus the given surplus of headway

5 – comfortable acceleration of 2 m/sec2

6 – comfortable deceleration of 2 m/sec2

7 – deceleration at emergency braking, more than 5 m/sec2

8 – safety headway maintenance program

9 – approach program under normal conditions

10 – approach program at inadequacy of comfortable deceleration of 2 m/sec2


 At this juncture, the exiting carrier informs the packet of its intention to leave, effects an “exit distance” with respect to the contiguous carriers, engages the transfer rail and departs.

Passive switches make any "exit distances" absolutely unnecessary. The usual headway between vehicles is quite sufficient.

 It is quite likely that multi-directional switching will be required with multi-line operation.  

How do you imagine it? 3, 4, 5 guide rails? It’s impossible because of the problem of crossing of guide rails with wheel rails.

 It may in some instances be required to elevate the guideway.   We anticipate that this will be the exception; in most instances the freeway itself, augmented by barriers and other devices, should be sufficient. 

It is true only for DM, but not for PRT. PRT stations should be situated everywhere and not just along freeways. I think that the system will be mixed both in America and in Europe/Asia (DM+PRT), despite differences in the primary mode. DM in America (except densely populated or congested areas or separate objects with many clients or employees), but PRT + portable electric scooters in Europe/Asia (except remote suburbs). So the design of the system can be identical in America and Europe/Asia. It would be much cheaper and more successful to design, produce and sell the same elements for both American and Europe/Asia. Transport problems in Europe/Asia are more serious than transport problems in America. Therefore, PRT in Europe/Asia is a necessary step towards DM in America. I believe that the combined efforts of leaders in American and European/Asian capitals (especially Moscow) are necessary for the creation of DM + PRT.

 All operations on the main line must be at a constant system speed.

I do not see any reason to limit speed, if there are no objective reasons. Vehicles certainly should use special lanes of queue and acceleration (before mainline) and lanes of deceleration (before turn to another mainline or before station). But it does not mean that speed on mainline should be fixed. It is necessary to ensure only that nothing (like short acceleration lanes) slows down the stream of vehicles. The system with unstable speed is easier and has higher average speed, throughput and reliability, than the system with fixed speed.

Some have suggested that a vehicle wishing to transfer depart the line completely, come to a complete stop, and is re-launched onto the new line. 

In most cases vehicles transfer to another mainline without complete stop. At good conditions they even do not reduce speed at all, if the radius of turn is big enough. In case of a dense stream on mainline only, the queue may be formed and complete stop may be necessary.

As the vehicle approaches a need to transfer, the velocity is adjusted to coincide with a vacancy in the next line.  However, to first order, capacity is proportional to velocity; thus any appreciable reduction in velocity is reflected in a reduced capacity.

It is not so because 80% of vehicles go directly, and only 20% of vehicles join the queue for transfer to another mainline. Therefore the capacity of lanes of queue and acceleration is usually quite sufficient. Mr. Turnbull suggests a 50/50 split but I don't think it is the best idea in all circumstances.

It is not necessary to slow down the lanes of deceleration,queue and acceleration at all, if it's possible to build the turns with a big radius (900 m for 150 kph, the length of the 90 turn is 1414 m). In this case,100% of the stream from the mainline can be accommodated. Nevertheless, the lanes of deceleration (1736  m for 150 kph), queue and acceleration (1736 M for 150 kph) for the possible complete stop. Some part of these lanes can be situated at the turn. But usually in densely populated cities, there is not enough space; therefore turns with this large a radius are not possible, while its advantage is insignificant (some tens of seconds).

If we have one 150 kph lane of mainline in  each direction, then the turn with a radius of 100 m will allow 50 kph and a 50/50 split, but the turn with a radius of only 9 m will allow 15 kph and average a statistical 80/20 split.

If we have two 150 kph lines of mainline in each direction, then 50/50 split requires a radius of 900 m for one  switching lane, but an average statistical 80/20 split requires 30 kph and a radius of only 35 m.

However it is necessary to get rid of automobile stereotypes. There is no need to wait for vacancy in the mainline all day, if it is possible to slow down slightly the stream on this mainline (i.e. temporary large headway instead of permanent inter-packet headways) when the queue length or waiting time becomes too big. The system must allocate priorities to vehicles from both directions in advance (“Updating of priorities of vehicles” block at my block diagram “Algorithms of PRT/DM control system”). The necessary slot for entrance on mainline will be created by the assignment of higher priority to a vehicle from a lateral direction (“Updating of priorities of vehicles” block at my block diagram “Algorithms of PRT/DM control system”) and by preliminary creation of a safe distance between the vehicle with a low priority from mainline and this vehicle from a lateral direction (“Approaching to leading vehicle” block at my block diagram “Algorithms of PRT/DM control system”). As there is no direct visibility of the vehicle from lateral direction, the information on it is transmitted by system to the vehicle with a low priority from mainline.

We believe that adjusting velocity on the main line to accommodate the next transfer creates control problems of significant proportion.  This requires that a central control authority must know the exact location and velocity of each vehicle under its control, and issue instructions accordingly. Moreover, this approach does not really provide for uninterrupted journeys.

Yes, the system must know the exact location and velocity of each vehicle under its control. It is not a problem. The information about concrete vehicles, in most cases, circulates inside the corresponding controlled district. It goes from vehicles and from the guideway to the district server.  The district server transmits information to those vehicles, which need this information to prevent collisions. The size of controlled districts is set so as to manage this information flow.

By the way, Mr. Turnbull demands that periodic track-side sensors provide real-time position and velocity data [about packets] throughout the system. His system would have to keep track of each vehicle which is leaving or joining the packet, and also track the first and last vehicle in every packet. But the work of forming, merger, routing, division and disbandment of packets would also arise. The lack of information about every vehicle prevents the system from sending commands (about emergency braking, for example) to every vehicle in a packet.

As before, it we do not require a specific slot, considerable advantage obtains.  Let’s consider the next step and require only a non-specific vacancy in a specific packet.

There is no need to plan either specific slots between concrete vehicles, or non-specific vacancies in specific packets on all route. Besides, such a task is too burdensome for servers of the system.

It is enough to plan the number of vehicles going through segments of lines in future minute intervals (“Current distribution of transport network capacity” block at my block diagram “Algorithms of PRT/DM control system”). It allows planning a route for a concrete vehicle (“Routing algorithm” block at my block diagram “Algorithms of PRT/DM control system”)  to prevent congestion. Every new planned route of a concrete vehicle increases the planned loading on corresponding lines (“Current distribution of transport network capacity” block at my block diagram “Algorithms of PRT/DM control system”). Routes may not be planned on the overloaded lines (analogue of entrance quotas). All these calculations are made before the departure of vehicles from the station.

All one needs is an auxiliary (i.e., off the main line) transfer line which allows individual vehicles to slow and slide back the appropriate number of slots. 

That is, the same queue, about which I wrote above, is offered. It is the only opportunity to push an irregular stream of vehicles into a line of limited capacity.

The carrier makes many of its own decisions, including initiating the transfer to other lines…   While it lacks authority to launch on the system.

My approach is similar. The function of planning a route (“Routing algorithm” block at my block diagram “Algorithms of PRT/DM control system”) and the function of priorities allocation (“Updating of priorities of vehicles” block at my block diagram “Algorithms of PRT/DM control system”) should be carried out by district servers of the system, instead of the highly specialized onboard computer of the carrier.

The following functions should be carried out by the highly specialized onboard computer of carrier:

       Approaching to leading vehicle”,

       Going after leading vehicle”,

       Speed limitation and stop”,

       Emergency braking”,

       Interfaces and triple-modular redundancy” (including steering according to the planned route).

See these blocks at my block diagram “Algorithms of PRT/DM control system”.

The operations-model must be sufficiently flexible to accommodate differing traffic patterns, seasonal variations, and (predictable) emergencies. In fact there is no single model. A specific scenario is designed for each specific traffic pattern, or a specific event, or series of events. As each will have been previously downloaded to the entrance stations, it is only necessary for the central authority (computer or otherwise) to designate the specific scenario and time of execution to alter the system.

This is unnecessary. In any case it is desirable to be guided by standard criteria when planning a route. That is minimal duration of trip, comfortable longitudinal accelerations and decelerations, avoidance of congestion and observance of speed limits (taking lateral accelerations into account) on different segments of lines. There are effective enough and fast mathematical algorithms for this purpose (“Routing algorithm” block at my block diagram “Algorithms of PRT/DM control system”). All these calculations are made before the departure of vehicles from the station.

It would be impracticable to allocate destination quotas for the entire system at each station. Thus… quotas apply only to the initial transfer.

This approach does not take into account the fact, that the vehicles after initial transfer will go to different destinations, and the loading of the next segments of lines along the vehicles’ routes will not be controlled. Besides, the vehicles from different stations can go along the same route from the certain point. That is, quotas should not be attached to the initial transfers. Therefore, Turnbull had to search for palliative solutions like a quota for the first two transfers and like virtual lines via several transfers. It would considerably complicate the control system, as it is hard to consider all possible variants of quotas of the second level. Besides, there would be a problem of transfer of the unused quotas of second level. Not all cities have as convenient layout as the layout of Los Angeles, and in these cities the number of transfers along the route may be quite large. The competing algorithm of planning loading of segments of lines is almost as simple, but has no such disadvantages.

The packet will slow as a single entity. Moreover, by concentrating all excess space between the packets; aside from facilitating entry, we also provide room for following packets to execute emergency braking.

Unlike a train, a packet has no common pneumatic brake pipe. Therefore all vehicles in packet will brake independently from each other and will be hitting by couplers or bumpers. The situation is even worse, if the command to brake is transferred along the line from each vehicle to the next (as suggested by Mr.Turnbull). Add the time for processing the information in the onboard computers of all vehicles sequentially, for setting of connection, log on, transmitting, encryption and decryption and so on. In case of a crash all packets will be damaged, instead of a few vehicles which did not have enough time to execute emergency braking and to stop to the common command of the system.

The communication is basically only from one station to the next in line… This makes an easy case for scalability.

This means that both stations and vehicles know nothing about the loading of segments of lines along the route before departure. They have constant, rigid and arbitrary interline quotas only. They also know nothing about faulty segments of lines. These are powerful disadvantages. The average length of a route (20 km) is not too long to refuse the communication with all district servers along the route. It will take not more than a few seconds before the departure of the vehicle from the station. Mr.Turnbull's provision for emergency interruption of faulty lines requires that each station should posses the means to communicate with the longest trip that might be encountered. So I don't suggest using any additional instruments.

Thus an onboard computer is required for this task.  We anticipate the central processor of almost any present-day PC would be more than adequate.

Only the self-murderer will board the vehicle under control of PC's central processor! It is necessary to use a specialized onboard computer without a hard drive and without a GUI, but with triple-modular redundancy. It will be something like airborne computer of jet plane or ballistic missile. And onboard computer should be designed in Moscow, but not in Silicone Valley. In this case it will be much safer, especially in an emergency. I mean that some Moscow R&D institutes have (besides perfect instruments,excellent experience, knowledge, versatile education and creative ability among the staff) the more fundamental approach and special cultural standard, based on strict traditions and relations. The missile had to fly absolutely reliably at any price, despite any emergency conditions and irrespective of contract clauses. In a strict socialist/military structure nobody was interested in easy profit, misleading customers,  or producing obviously unreliable products for an undemanding public (like MS Windows) and so on. The best people were selected for these R&D institutes. Many of them did not leave during bad economic conditions and they still work there despite the brain drain.

The platform of the carrier… need only be rugged enough to carry that type of load.

I think that it is necessary to securely bind the vehicle automatically to the carrier, and also to connect to power supplies automatically. It is a rather difficult problem if you try to keep a support on wheels of carried vehicle.

To minimize contact with high voltage power, the power for operation within stations is supplied from an onboard battery.

Good idea!

In emergency application, the friction forces can be augmented by means of the guidance apparatus.  When pulled into contact with the guidance rail, considerable additional braking forces can be provided. 

The transfer guidance rails at switches cannot be used for emergency braking, because they are asymmetrical.

The center guidance rail cannot be used for braking when switching to the lateral direction. So the braking mechanism must be evacuated for the rail in such situations and, therefore, this mechanism will be rather complicated.

It's too expensive to have separate center guidance/braking rail along the whole mainline. So it's a hardly possible, while attractive suggestion.

Guidance arms extend downward from the carrier and have the means to “grasp” the rail.  We use the term grasp in quotation marks because, in normal operation, there is no physical contact with the rail. In practice, the lower part of the arm is maintained in proximity to the guidance rail with its position relative to the rail sensed electronically.  The position of the guidance arm does not directly control steering.  The arm is allowed to follow the normal variations in track position, while the high frequency movement is damped out by the steering system, providing a smooth ride to the passengers.

There is no need for an electronic steering system like ULTRA's steering system. All the vibrations from steering rollers can be damped by the horizontal shock-absorbers.

home2.gif (1492 bytes)

Last modified: February 10, 2005