1. Field of the Invention
The field of the invention generally relates to a transit type system and more particularly to a transit type system that will transport people in their car on a computer controlled, elevated guide way.
2. Description of the Related Art
The existing surface transportation (roadway) system has three major failures: it is not safe, it is not reliable and it is not sustainable. In 2009, there were 81,599 crashes and 600 fatalities in south Florida (Palm Beach, Broward, and Miami-Dade Counties) alone. A 2008 NHTSA Crash Causation Survey has concluded that more than 95 percent of crashes are due to human error, and with the increase of distracted driving due to smart phones, these statistics are likely to become much worse. Surface transportation is over capacity at peak hours on most roads. Current long range plans attempt to keep up with population growth, but will not make significant improvements. Fossil fuels are a finite resource. Pollution problems come from drilling for oil, refining oil, carbon emissions, and the damage from runoff into the water system, loss of habitat, erosion, and the like.
Currently there are solutions for some of these problems, but no solution that resolves all of the issues. For example, one solution is to build new roads and/or add additional lanes to ease traffic woes; however, this will only increase environmental issues. More people driving results in higher numbers of fatalities. In addition, most major transportation corridors are already built out to the edge of available right of way, and thus adding lanes or creating new roads is a much more expensive proposition because high dollar land would need to be purchased for future lane expansion. Another potential solution is the increased use of hybrid, high mileage, and/or electric cars to ease some of the environmental concerns; however, such actions do nothing to reduce fatalities and/or traffic congestion. Electric cars also create new issues due to limited driving range capabilities as well as the requirements for battery disposal and charging stations.
Another potential solution is the use of self-driving cars. Self-driving cars will help with fatalities but only if everyone owns a self-driving car; otherwise distracted drivers remain a concern. Finally, transit systems, including bus/light rail and metro lines are the best solutions thus far as these transit systems help to reduce traffic congestion, fatality rates, and the environmental concerns; however, the increase in travel time and the requirement for transfers make these options of limited benefit. Furthermore, transit is only beneficial for people departing from and going to places within a few blocks of the track or bus route, which severely limits the usefulness to a large percentage of the population. Moreover, current transit systems are even less desirable during poor weather, whether it is rainy, humid, cold, or extremely hot.
Embodiments of the present invention address deficiencies of the art in respect to surface transportation systems and provide a novel and non-obvious system and method for providing an autonomous moving highway transit system that will transport people in their vehicle on a computer controlled, elevated guideway. In one embodiment of the invention, the autonomous moving highway system includes an elevated guideway having a support pier having a top end and a bottom end opposite the top end, a pier cap having a first end, a second end opposite the first end, an upper portion and a lower portion opposite the upper portion, the lower portion of the pier cap attached to the top end of the support pier, a first girder located at the first end of the pier cap and a second girder located at the second end of the pier cap, a first magnetically levitated (maglev) transportation track mounted to a bottom of the first girder and a second maglev transportation track mounted to a bottom of the second girder, a plurality of individual transportation pods; wherein each transportation pod is configured to enclose a vehicle and at least one passenger of the vehicle, a computer control system, the computer control system configured to control power, propulsion, direction and motion of the plurality of transportation pods and to automatically guide one of the plurality of transportation pods to a destination selected by a user, and a system station having a docking bay that includes a docking platform having a first end configured to receive the one of the plurality of transportation pod and a second end configured to receive the vehicle.
In one aspect of this embodiment, the computer control system comprises a plurality of command modules within each transportation pod configured to control power, propulsion, direction and motion of the plurality of transportation pods in a region of the guideway and to automatically guide one of the plurality of transportation pods to a destination selected by a user. In an aspect of this system, the autonomous moving highway system includes a track continuity module configured to process track emergencies that are identified by a track continuity sensor. In yet another aspect of this system, the autonomous moving highway system further includes an empty pod module configured to control flow of empty incoming and outgoing pods in the station and between stations.
In another embodiment of the invention, an individual transportation pod for use in an autonomous moving highway system that includes a pod body configured to enclose a vehicle and at least one passenger of the vehicle, a nose cone attached to a first end of the pod body and a pair of doors attached to a second end of the pod body that is opposite the first end of the pod body, a maglev sled attached to a top of the pod body, where the maglev sled is configured to engage with a maglev transportation track of an autonomous moving highway system, and a fail safe speed detector-emitter attached to a front surface of the maglev sled.
Additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The aspects of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
The accompanying drawings, which are incorporated in and constitute part of this specification, illustrate embodiments of the invention and together with the description, serve to explain the principles of the invention. The embodiments illustrated herein are presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown, wherein:
The autonomous moving highway is a transit type system that will transport people inside their personal vehicle quickly, safely, and without gas on a computer controlled, elevated guideway. The highway portion of the daily commute changes from being stuck in traffic to a relaxing ride, sitting back in the user's own vehicle, while traveling at speeds greater than 200 mph. One advantageous feature of the autonomous moving highway is that users remain in their own vehicle the entire time and thus there are no transfers, no unusual people to address and no waiting. Any automobile (even a full size pick-up truck, SUV, or van) can fit in the transportation pod, which has a magnetic levitation (maglev) sled mounted above the roof. The maglev sled connects into an overhead track system consisting of an energized track that will propel, guide, and control the pods. The maglev system operates independently of the user's vehicle engine. The track will have entrances and exits at various stations, but unlike a traditional subway or train, there is no need for all transportation pods to stop when one user needs to exit the system. The transportation pods keep moving at full speed. Users will drive on regular streets to the moving highway entrance; then the system will transport them to another station where they exit onto the surface street as a normal automobile. By using the same vehicle on/off system, users will not be limited by the location of the track. Even users who do not live or work near the track can benefit for a portion of their trip and/or daily commute.
In embodiments, the autonomous moving highway system includes an elevated guideway having a support pier having a top end and a bottom end opposite the top end, a pier cap having a first end, a second end opposite the first end, an upper portion and a lower portion opposite the upper portion, the lower portion of the pier cap attached to the top end of the support pier, a first girder located at the first end of the pier cap and a second girder located at the second end of the pier cap, a first magnetically levitated (maglev) transportation track mounted to a bottom of the first girder and a second maglev transportation track mounted to a bottom of the second girder, a plurality of individual transportation pods; wherein each transportation pod is configured to enclose a vehicle and at least one passenger of the vehicle, a computer control system, the computer control system configured to control power, propulsion, direction and motion of the plurality of transportation pods and to automatically guide one of the plurality of transportation pods to a destination selected by a user, and a system station having a docking bay that includes a docking platform having a first end configured to receive the one of the plurality of transportation pod and a second end configured to receive the vehicle.
In illustration,
The pod 100 can include a maglev sled 108 mounted above the roof 103 of pod body 102. As illustrated in
As illustrated in
As illustrated in
As illustrated in
As illustrated in
Pod 100 further can include a fail safe override control 992, which can include a speed detector emitter/receiver 110 that is located at front of the maglev sled 108. Fail safe override control 992 looks ahead to verify emergency stopping distance and speed of forward pods. Each pod 100 also has a reflector 138 on the rear of maglev sled 108 (see
As illustrated in
As shown in
As shown in
As illustrated in
Pod lane 1008 configuration includes a track with a reverse turnout for each docking bay 1020, all to one side. The reverse turnouts allow the pod 100 to back into each bay 1020. For safety reasons, the maglev sleds 108 are not capable of going in reverse. As such, the pods 100 need external devices to back up into the docking bay 1020. Back up trolleys 322 are located at each docking bay 1020 and serve to retrieve a pod 100 that is stopped on station pod lane 1008 and bring the pod 100 backward to the docking bay 1020. The pod 100 remains attached to the maglev track, continuing to use maglev for levitation, and will use the maglev propulsion to depart from the docking bay 1020. The back up trolley 322 is a ground mounted track 324 on the same alignment as the overhead track. The back up trolley 322 generally fits below the pod, except for a thin vertical plate that can attach to the back of the pod 100 via the trolley magnet 142. When pod 100 departs, the back up trolley 322 stays in place at the bay docking platform 320 until the next pod 100 needs to be retrieved from the pod lane 1008. Back up trolley track 322 is single vertical guide-way track 324. The back up trolley 322 fits over vertical guide-way track 324 and has electric drive wheels that also contact guide-way track 324. Power for the motor is positive and negative drag line on either side of guide-way track 324. The station docking computer 956 controls the back up trolleys 322. Docking bay gates 326 are located at the end of each platform 320 and open in conjunction with the pod doors 112, 114 and serve to keep waiting vehicles 1050 at the appropriate distance to allow pod doors 112, 114 to open. Docking bay gates 326 also ensure that vehicles 1050 do not drive off the edge of the docking platform 320 when a pod 100 is not present. Gate posts 328 line up with pod opening to keep vehicles 1050 centered and generally protect pod 100 from vehicles 1050. Docking bay gates 326 are connected to perimeter fence around pod area 1004 Once the back up trolley 322 brings a pod 100 backward to the docking wall of bay 1020, docking bay gates 326 can open to allow the egress of a vehicle 1050 from the pod 100. Storage tracks 1018 for empty pods 100 ensure that a steady supply of pods 100 is available during peak usage periods. Empty pod relocation module 943 communicates with local server 964 and tells empty pods 100 when and where to relocate.
During normal operation of a station 1000, the standard procedure is for all docking bays 1020 to have an empty pod 100 waiting for a new vehicle 1050 to enter. Waiting pods will have doors closed until the empty pods 100 are ready to be loaded to prevent excess wind, rain and debris for entering into a pod 100. For each station 1000, in flow and out flow must be equal, regardless if pods 100 are occupied or empty. If all docking bays 1020 have pods 100 and an occupied pod 100 enters the station 1000, an empty pod 100 will depart. In peak flow times, when stations are heavily skewed toward all arrivals or all departures, empty pods 100 will travel from arrival stations 1000 to departure stations 1000. Each station 1000 will have a section of storage track 1018 to hold empty pods 100 to create a buffer, such that exact timing of empty pod arrivals does not create user delays. When an occupied pod 100 departs, a pod 100 needs to enter the station. If an occupied pod 100 is on its way, and will arrive soon, then no other action is needed. If the station 1000 has significantly more departures than arrivals, an empty pod 100 will arrive to fill the empty docking bay 1020. The empty pod relocation module 943 has perfect information such that incoming empty pods 100 can be on their way prior to actual need. Storage tracks 1018 create a surplus of available pods 100 such that users will not have to wait. Roadway traffic signals 1040 will communicate to vehicles 1050 and direct vehicles 1050 to the appropriate lane 1006 and platform 320 to create smooth flow of incoming vehicles 1050, thus reducing weaving of arriving and departing vehicles 1050 on the same lane 1006. Overhead lane signals 1040 can alert drivers to any lane closures, such as during non-peak times.
Prior to the channel lane 1024 fork to the pair of vehicle lanes 1006, there can be a six head traffic signal 1040 on a mast arm pole. The traffic signal 1040 will direct vehicles 1050 to either go straight or turn left. Vehicle detectors 950 will count vehicles and with one remaining open pod, the signal may turn yellow. After a vehicle 1050 enters the vehicle lane 1006 to fill the last open pod 100, that signal 1040 can turn red and direct vehicles 1050 to the other direction in the fork. Vehicle detectors 950 at the beginning and end of the pod lane 1008, together with knowledge of vehicles 1050 entering and exiting pods 100, will keep a running tally of the number of vehicles 1050 in the vehicle lane 1006. This running tally is the number of vehicles 1050 that the signal 1040 will count up to and allow into each vehicle lane 1006. If a vehicle 1050 runs the signal or a vehicle 1050 does not exit a pod 100, the system will self-correct and reduce the number of new vehicles 1050 entering that vehicle lane 1006.
Vehicles can have a RFID sticker (e.g., can be same as local toll system) to identify vehicle. A RFID reader 948 is located on platform 320. User database 966 identifies the vehicle 1050 and top five destinations based on entry time and location. Vehicle 1050 enters empty pod 100, sets vehicle gear to park and/or apply parking brake, and turns off the engine. Pod doors 112, 114 close upon engine shut off. As pod motion commences with the pod traveling towards the primary destination, user can choose other destination at any time, but primary destination is the default so that for regular users, no input is required. For example, when a vehicle 1050 enters the system on a weekday morning, the default will be the station 1000 near the user's office, similarly, in the evening; the system can default to take the vehicle 1050 to the station 1000 near the user's home. Pod interior 101 can include a headlight flash detector 932 that provides an interface to receive signals created by flashing hi-beam headlights of the vehicle 1050. When the top five destinations are shown, users can scroll through the list by flashing hi-beam headlights, which allows users to change initial destination without opening a window to access the side touchpad 144 or using a mobile phone application 970. Users also can edit default or pre-select destinations through a website or a mobile application 970.
Constant two way communication between pod computers 920 and local servers 964 includes an independent communication system, which is not part of the Internet. Computer control system 900 as a whole has perfect knowledge of all track continuity 974 and pods 100 and dictates position and speed of all pods 100 with no user input. When a new pod 100 enters the system all projected positions and speeds are adjusted to allow for merging and proper pod spacing. Computer control system 900 includes central modules 901 e.g., such as modules that only require one per state, user database 966, mobile application 970. The user database 966 can also connect to credit card payment system 968 and state tolling system 972. Regional modules 902 such as one or more per county or sub area can include, command local server 964, track continuity module 974, Command QA module 980, and empty pod relocation module 943. Station modules 904 include, station manager module 944, docking module 956, parking module 946. Pod modules 906 can include pod computer 920, pod acquaintances module 940, and failsafe override control 992. Pod computer 920 interfaces with all devices in pod 100, such as air system 922, carbon monoxide detector 924, front display 136, pod door control 928, fire suppression 202, headlight flash detector 932, pod infrared detectors 146, side touch pad 144 and engine detector 936. The pod acquaintance module 940 contains a list of all the other pods 100, which a pod 100 will either lead or follow during that pod's journey. Depending on system size and overall distance, there can be multiple regional computers 964, 978 to reduce latency in commands to each pod computer 920. General pod motion is dictated by each individual pod computer 920. Station manager module 944 tells pod computer 920 which lane and bay to go to within the station 1000, as well as vehicle signals 1040 back up trolley 322 and bay gates 326.
All programming modules will be events based. The registering components (servers 964 or pod computers 920) will have delegates set up to receive event notification. This will guarantee that the system is in harmony without overcrowding the network. The communication is between components that need to communicate and not a broadcast model which sends out packets of information on the network to all listeners. All servers 964 are aware of the location of all pods 100. Each pod computer 920 will interface with the local server (Command) 964. Each Local Server 964 will have a regional (geographic) zone. Pod computers 920 will know the credentials of the next local server 964 based on the direction and current location. When a pod computer 920 registers with a local server 964, that server, based on the direction and current location, will identify the next local server 978 for the pod 100 in the return message. When a pod computer 920 registers with a local server 964, the local server 964 will then propagate the information to all the servers 964, 978 in the system. These local servers 964 will act as backup servers for each other. The local server 964 can monitor the pods 100 for distance and speed by the Command QA module 980. Any necessary corrections to distance and speed will be communicated to the pod computers 920. Emergencies, such as pod failure or track blockage will be identified by the Track Continuity module 974 is monitored by the servers 964, 978, which provide notifications to the pods 100. Transit system includes a single direction track, merges 313, and forks 315. Merges 313 include a mainline track 302, 303 (on the left) and an on-ramp track 312 (from the right). Forks 315 include a mainline track 302, 303 (to the left) and an off-ramp track 314 (to the right).
Pod computers 920 have knowledge of the other pods 100 immediately preceding and succeeding it as well as those projected to be preceding or succeeding for the duration of the trip 940. This knowledge includes current position and speed and projected time and speed at merge points. As routes for all pods 100 are known, pod computers 920 can project when they will be at a merge point, thus the pods' computers 920 will also know any projected preceding and succeeding pods 100 from each merge point. These immediately preceding and succeeding pods along with any projected preceding and succeeding pods make up the group of acquaintances 940 for each pod. Each pod computer 920 will have its own group of acquaintances 940. When a pod first leaves the station 1000 (enters the system) or changes destination, the local server 964 will create that pods' initial group of acquaintances 940. The pod computer 920 will notify the other acquaintance 940 pods.
Standard operating procedure is for equal sharing of speed deflections for on-ramp pod 923 and mainline pod 921. Both the on-ramp pod 923 and the mainline pod 921 adjust speed as needed to create single mainline stream of pods 100. The minimum time spacing for following pods is 0.1 seconds and the minimum time spacing between mainline pods 921 for an on-ramp pod 923 to merge in is 0.5 seconds. As on-ramp pod 923 approaches the merge, on-ramp pod 923 is in communication with projected preceding and succeeding mainline pods 921. This preceding and succeeding mainline pair of pods 921 know that on-ramp pod 923 is coming and will create spacing by slightly accelerating or decelerating for on-ramp pod 923 to merge in. The default operation is for mainline pods 921 to accelerate and create space for the on-ramp pod 923. Because pods 100 communicate with pods 100 in front of them, multiple pods in close spacing can all accelerate in unison to make room, even if pod 100 is well past the merge. This operation applies to all merge points. If pods are in close spacing on both approaches, the pods 921, 923 will come together e.g., in a zipper-like manner. In these situations, with heavy flows from both sides, the pods 921, 923 on each approach can also double or triple up through the merge. Pods 921, 923 will plan to increase spacing just before the merge. Pods 100 in the group of acquaintances 940 will change based on changing projections and when pods 920 go through a merge or fork. In all cases, the same sequence of handshakes will occur, such as notify current preceding and succeeding pods that they are leaving the group of acquaintances 940. In the notification mechanism, the pod 920 will send credentials of the preceding pod to the succeeding pod; and send credentials of the succeeding pod to the preceding pod. This operation will allow the current preceding and succeeding pods to register each other as succeeding and preceding pod of the other pod 100. Since each pod performs its own actions, these operations can be recursive to handle multiple pods leaving. The transfer of credentials also applies to the projected pods. As the projected time to reach a merge point increases or decreases, the pod computer 920 will hand off the projected pod credentials to the preceding and/or succeeding pod 100. The pods 100 will monitor the speed and distance of the preceding and succeeding pods and adjust its speed accordingly. Any changes in speed will be notified to the preceding and succeeding pods. Since each pod performs its own actions, these operations can be recursive.
Pod computer 920 instructs each sled 108 when to hold left side of track and when to hold right side. For most sections of track, the held side does not make a difference, but as a pod approaches a turnout 402, it will hold one side to correctly navigate through the turnout, i.e. stay on mainline track 302 or exit track 314. Standard operating procedure is to hold the left side until the pod will exit at the following turnout, at which time the right side will be held. A location marker in the track following each turnout will give positive location reference to the location detection module 986.
Operation is based on minimum time pod spacing. Pod speeds are controlled by pod computer 920 and are altered slightly to create gaps for merging pods. Standard minimum clear spacing between pods 100 will be 0.1 seconds, but can be decreased to near zero to increase capacity. At merge locations 313, mainline pods 921 will create a 0.5 second gap for new on-ramp pod 923 to fit in. Similarly, if closely spaced pods 923 are approaching on on-ramp, they will all have minimum 0.1 second spacing and can widen to 0.5 seconds if needed to fit around mainline pod 921. Standard capacity is approximately 7200 pods per hour per direction with an estimated best case maximum capacity in open conditions of approximately 60,000 pods per hour. Theoretical minimum spacing is based on time for single pod to traverse its own length at max speed, which is approximately 0.06 seconds. Minimum time spacing can be increased to create safety factor for pod to achieve correct location. Pods 100 traveling on mainline track 302, 303 can reduce space between each pod 100 to a near zero distance and form a single line, or train to reduce aerodynamic drag on following pods. Because the pod computer 920 has perfect information and communication with surrounding pod computers 920, all pods 100 can decelerate in perfect unison with no delay from reaction time. Turnouts 402 are based on full speed exits such that within a line of pods, there is no need to reduce speed for exiting pods to depart safely. Multiple wireless technologies to ensure highest level of security in both information received and encryption of information.
Location sensors 986 on tracks to create positive location for all pods. Command QA system 980 monitors performance history of pod 100 and of track section 302, 303 to minimize differences between directed and actual positioning of pods 100. Two independent communication systems are embedded in track corridor 300; one for pod communication as described, and a second user accessible system for Wireless Fidelity (Wi-Fi) access.
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
Aspects of the present invention have been described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. In this regard, the flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. For instance, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The invention has been described with respect to certain preferred embodiments, but the invention is not limited only to the particular constructions disclosed and shown in the drawings as examples, and also comprises the subject matter and such reasonable modifications or equivalents as are encompassed within the scope of the appended claims.