Obstacle Detection in FLYWAY

Technology is always developed from the primitive, over the complex and awkward, and then on to the simple and sophisticated.

stated elsewhere on this site, the FLYWAY® system is run and controlled wholly automatically, which also means that the beamcars have to look out for themselves, and not bump into things. They have to be able to "see", and, to a certain extent, evaluate what they are seeing. Or, as a better alternative, obtain the visual information they need from an outside source. This page is rather technical, and is meant to satisfy the curiosity of those who want to know how the cars avoid unexpected obstacles when there are no drivers to handle the cars. At the time of this writing, everything regarding obstacle detection is not clearly worked out and tested yet. So, this page is going to be continually updated.	We will look at 2 general solutions to every situation: mobile detectors (on the beamcars) and stationary detectors. Then we will look more in detail at how a stationary obstacle detection system for FLYWAY® would function. General Safety at shunts Safety during travel Safety at stops Mobile or stationary scanners? Calculating safety distances Looking around corners The technical function of a stationary, Ladar-based system

1. General

t is important for an automatically driven vehicle to be able to detect any obstacle in its path of travel, or, as an alternative, to obtain timely and reliable information of that nature from a source outside the vehicle. Should this obstacle be a beamcar up ahead along the beam, having some kind of problem and cannot move, that car would normally report the situation to the regional computer in charge, which in turn would broadcast an announcement to other vehicles in the area. But that procedure cannot always be relied upon; the faulty vehicle might not be able to transmit any message about its predicament, for some reason or other. There could also be other kinds of obstacles along the beams. For that reason, the FLYWAY® system will have to be equipped with some kind of obstacle detection devices. As of this writing this detection system has not been decided upon.	Inside the beams, the propulsion cars and/or the beams themselves would have a similar system, which functions as electronic bumpers. These scanning devices are in both instances monitoring a certain distance ahead of the vehicle. Those devices that are mounted on the carriages are of the sweeping kind, covering a certain angle and a certain distance ahead. Note: It could be that the detection devices inside the beams are not needed. Considering figure 1:1, it is clear that the beamcar need to be able to scan at a certain vertical angle (V in the figure), as well as horizontally (H). How this will be accomplished is to be detailed further down.	Figure 1:1

Currently, there are no satisfying solutions to the obstacle detection problem. All systems have their drawbacks, and almost all methods are susceptible to problems caused by environmental conditions such as ambient lighting (laser), the lack thereof (digital cameras) or precipitation (laser). We have briefly detailed these problem on the previous page. Detected objects will generally be of 3 kinds: Objects that the scanner is "aware" of, and which poses no danger to the beam traffic (such as nearby buildings). Beamcars, stationary or moving. This information would then supplement the regular information about other, nearby, beamcars, that all beamcars receive through normal channels. In this case, the information would serve to regulate the speed of the beamcars, if necessary. Objects that might pose a threat.

Briefly stated, the best obstacle detection system for automatic transport systems, such as FLYWAY, will probably: be stationary mounted on or nearby the beams, rather than on the vehicles be primarily of "ladar" type be designed so that each scanner will compare its input with stored information what the terrain "should" look like, from its point of view be a combination of at least 2 different scanner systems, covering the same areas, in order to complement each other so as to combat the problems inherent in laser scanning, as detailed on the previous page consist of several scanners, covering the same beams from different angles (as shown in figure 5:5 further down) be wholly or partially combined with a regular surveillance system for the relevant geographical area.

2. Safety at Shunts

he FLYWAY obstacle detection devices have to fulfill certain specific tasks. One is to check the adjoining beam at convergence points. Consider figure 2:1, which illustrates a convergence node (or "weaving" node), where the cars from two beams converge onto one beam. Here, we conjure up a rather complex scenario. Let us imagine that vehicle B cannot proceed because of a malfunction or blockage along the track. This would be detected by both A:s and C:s radar, and they will both stop. A moment earlier, C would have discovered vehicle A, approaching on the other branch. A is so far into the shunt that the vehicle C could not enter the shunt without hitting A. So, from C:s point of view, A could just as well have been the stopping vehicle. Soon, D will arrive and will have to stop because of A, but it would probably, as well as vehicles E and F, have been warned of the stoppage by the regional computer or by the computer masterminding the next node. That is because the computer in charge of this node would already have released control over B, thereby making B the responsibility of the next node along the line. What is apparent here is that the horizontal scanning angle must be fairly wide to detect cars on adjoining beams. It is thus clear that this type of situation is not ideally suited for obstacle detection devices mounted on the beamcars. We would thus have rely on sensors inside the beams at regular intervals (about every 250 meters) and at certain points at terminals, stations, shunts and the like. They would detect any passing car and note its travel direction, speed and identity. To detect objects other than beamcars, stationary scanners would be a better solution here. Figure 2:2 illustrates how four such scanners could be set to scan sufficiently wide sectors in all relevant directions. Four scanners might seem like many, but it should be remembered that a ladar scanner can see very far; about 1 kilometer in each direction. They can indeed see still farther, but one has to optimize the scanning angle, too. Overlapping scanners, as illustrated in figure 2:2 and 2:3 serve 2 purposes: they help each other to reduce the scanning angle they provide better possibilities to identify an object, since 2 (or more) scanners will see the same object from different points. For example, while the central scanner in figure 2:2 might normally be set to scan sectors 1 and 2, it could also be set to scan area 3 (orange) from time to time. This could for instance be triggered by reports from one of the other scanners that they have detected something of interest in this area. Information about detected objects that should not be there would continually be reported to the regional computer in charge of the area. This applies to the sensors inside the beams as well. If such a sensor detects a passing car, and the next sensor does not detect this same car within a reasonable time interval, the node computer can draw the conclusion that the car has stopped somewhere in between. If this cannot be accounted for (i.e. the car was not supposed to stop there) the regional computer will transmit an alert to other traffic, and then try to contact the car.

Figure 2:1: mobile scanners Figure 2:2: stationary scanners Figure 2:3: operation of stationary scanner

3. Safety during Travel

Figure 3:1

LYWAY´s obstacle detectors could optionally be mobile, and "nose-mounted" (figure 3:2) or "bottom-mounted" (figure 3:1) on the beamcars, or they could be stationary (figures 2:x), and mounted on or near the beams. Let us look at how the obstacle detection would function during travel, for the two solutions under consideration; mobile and stationary. The tasks of the scanning unit would be as follows: Scan for objects sufficiently far ahead so that the vehicle can stop in time, if need be (the requirement for "brickwall stop" capability) Scan a sufficiently large angle, both vertically and horizontally Scan often enough, both vertically and horizontally, to catch fast-moving objects, relative to the beamcar Be able to tell different types of objects apart, so that the beamcar or system can differ between those objects that the car must stop for and those that it need not stop for. Mobile scanners, mounted on the beamcars A bottom-mounted scanner on a beamcar, as illustrated in figure 3:1, would function as follows: during normal travel, the unit is folded down-out, so that it can scan not only straight ahead, but also slightly upwards. This is necessary in order for the unit to detect objects that are level with the carriage. When the beamcar is traveling to the left in the drawing, the scanner unit will only scan vertically within the angle indicated by "A". When the beamcars travels in the opposite direction, the unit will (of course!) scan within the angle marked "B". So, what happens when the carriage is lowered to the ground? Well, the unit will of course have to be retracted into the carriage, as shown, so as not to get damaged when the carriage hits the ground. But it can still scan downwards, as shown by "C". A bottom-mounted beamcar-scanner (figure 3:1), using ladar, could be motivated thus: It is an economic saving to have only one scanning unit instead of two. In the arrangement depicted in figure 3:2 there would have to be a scanner at each end, since some models the FLYWAY cars are intended to be able to travel in any direction without distinction. This is of course a matter of flexibility, it is not strictly necessary. By mounting the scanner underneath the carriage, the scanner unit need not to be taken into account when designing carriages for dual-mode transportation of motorcars, for other kinds of cargo, or for rear-end mounting of doors on passenger cabins. The scanner unit that´s mounted underneath the carriage gets almost total freedom in scanning vertically in all directions. This last point is of no small importance if there is need to also scan the ground.

Figure 3:2; Nose-mounted scanner Stationary scanners, mounted on or near the beams The deployment of these are described in the foregoing chapter. the advantages as compared to mobile scanners can be listed as: Each scanner is optimally trimmed for the place where it is placed. This is hard to accomplish with mobile scanners. Information processing is quicker, since no consideration has to be taken to the possibility that the scanner is moving. The system will likely need fewer scanners if they are stationary, which makes for lower investments. Stationary scanners will have more time to detect and evaluate objects. Stationary scanners can overlap each other and help to evaluate objects. Notes regarding obstacle detection for moving beamcars: The "brickwall stop" capability requires the car to be able to stop if suddenly confronted with an unmoving object. It is here assumed that the beamcars move at different speeds on various beams, where only the trunk beams allow speeds above 80 km/hour. The safety distance between beamcars must then be such that they have time to react and stop safely, and without injury to goods or passengers, before hitting the object. The general mathematical calculations for this safety distance can be found on this page. Calculations that pertain specifically to FLYWAY are found in chapter 6 below. The required scanning angles have to be calculated from input data that are not presently available. They will be presented in chapter 5. What need to be considered is that too wide angles would: indicate housewalls and such, especially where the beam curves, that have to be sorted out by the vehicle computer. require longer intervalls between sweeps or faster sweeps require more data per unit time to be processed by the vehicle´s computer. Increasing scanning frequency would also require more data per unit time to be processed by the vehicle´s computer. With "fast-moving objects" we mean "relative to the vehicle". This means that the faster the vehicle goes, the higher must be the minimum scanning frequency. It requires more than one sweep to safely classify an object. 4-5 consecutive sweeps hitting the object has been recommended. Naturally, if the object disappear before all these 4-5 sweeps can hit it, then it can safely be discounted. Otherwise, the computer needs consecutive data on an object in order to make a decision regarding it. Is it sufficiently small to be ignored? (could be a seagull or sparrow) Is it moving towards the beamcar? That situation would shorten the distance required to stop. Is it an object that can be ignored (such as a housewall)?

4. Safety at Stops

s stated in the foregoing, FLYWAYs vehicles or the system itself can also scan the ground when it´s time to go down for passenger or cargo. Some FLYWAY installations (or some stations) for passengers might not use the safe FLYWAY cubicles. In such instances, there is a definite need to check the ground while lowering the carriage, as illustrated in figures 3:1, 4:1 and 4:2. The image that the scanner picks up would in this case be compared to a digital topological map of the location, stored in the vehicle´s computer memory. If all altitudes of all features agree with those of the topological map, the vehicle can (almost) safely land. An even better result might be achieved using digital cameras. As a complement, such stops should be fenced in or hedged off, and a station manager should be present. Figure 4:1 shows a beamcar that can travel in either direction. It has its scanner mounted underneath the floor. Not only would the unit have to be withdrawn into the vehicle before hitting the ground, but a sliding protective cover would also be needed, to protect the lenses from dirt and water. A nose-mounted variety, as shown in figure 4:2, would be easier to produce and maintain, and it has the added advantage of leaving the interior floor of the carriage or cabin smooth and free. But this car can only travel in one direction, unless it is fitted with a scanner in both ends. Figure 4:3 shows the stationary alternative. Apart from the obvious advantage of having the scanner or camera steadily mounted, instead of swinging to and fro during lowering of the cabin, one can note these advantages: A highly mounted, un-obstructed device over a station could monitor all or at least several of the berths, which would entail savings in scanner equipment. A stationary device could see an obstacle much earlier than the approaching beamcar, saving lots of time insofar as the obstacle could be manually removed before the beamcar arrives, or the beamcar could be re-routed to another berth. Pole-mounted scanners (or cameras) can scan sideways, both along the beam and across to the neighboring beams, covering several berths, as shown in figures 4:4 and 4:5. One also has to take into account that lowering beamcars might block the view for the scanners. While most of the scanning will have been done by the time the beamcar lands, it is still a matter of safety to be able to detect anyone entering the berth during this landing. The FLYWAY "cubicles" solves this problem, but these might not be erected everywhere; they might be in the way in crowded places, for instance. Figure 4:5: Scanning neighboring berths

Figure 4:1: Floor-mounted scanner Figure 4:2: Nose-mounted scanner Figure 4:3: Stationary scanner Figure 4:4: Scanning adjoining berths

5. Mobile or Stationary Scanners?

s stated above, a single, mobile "LADAR" unit achieves considerable freedom and usability if it is mounted underneath the beamcar, as illustrated in figure 5:2, insofar as it would enable the beamcar to travel equally well in both directions. During normal travel, the unit is folded down-out, so that it can scan not only straight ahead, but also slightly upwards. This ability can of course also be achieved with a nose-mounted LADAR. The most logical solution would seem to be mobile units, mounted on the vehicles. But consider the advantages of stationary scanners, mounted on the beams (and even inside the beams): Laser depends on scanning the object several times, to detect relative motion with an object, while either the object or the scanner moves. Succeessive images have to be compared with each other. A pitching or shaking beamcar, and a car that frequently changes directions makes this more difficult, insofar as the computer that evaluates the images has to devote extra processing time to determine which parts of an image that matches part of a foregoing image. This problem disappears with stationary scanners.

Figure 5:2 A moving car has to use wide-angle scanners to cover the sides adequately, to allow for when the cars changes travelling direction and to check adjoining beams. This makes for a huge amount of needless processing, since images are often larger, with these allowances, than they need to be. In contrast, each and every stationary scanner would be trimmed to cover the area it needs to cover, not more and not less. Here, again, one would save in processing time. Stationary scanners could be simpler than mobile scanners, since they don´t have to work so fast. The area each scanner covers is the same all the time, whereas mobile scanners have to contend with a slightly new environment for every new image. Stationary scanners can much more easily use databased "reference" images, to judge if the field in view has altered from what it should look like. The reason why stationary scanners are better for this is detailed here. Stationary scanners can usually alert vehicles in plenty of time if something happens. Vehicles with scanners cannot travel faster than that they have time to process scanned data.

Because stationary scanners are simpler, and because they require less work from the image processing computers, a stationary scanner would be considerably cheaper than a mobile. With a sensible allocation of stationary scanners, they would not have to be more in number than the number of mobile scanners, assuming one scanner on each vehicle. Thus, a considerable saving in money for the whole system, if stationary scanners are used. There are two drawbacks, as well: Stationary scanners are harder to maintain, as this has to be done on location. A faulty mobile scanner is brought to the workshop by the vehicle. Stationary scanners have to relay their information to all affected beamcars, and this requires extra addressing logic. It also causes some delay due to communications overhead, compared to vehicle-mounted scanners. This last objection is not necessarily a drawback, however. There are two alternative solutions: All travelling vehicles "know" by way of their positioning system when it is time to fetch new scan data, where to fetch it from, and what exact data to fetch. This data will at that time already be completely processed and evaluated and need no further evaluation by the vehicle requesting the information. Scanning data is only sent if there is danger of an imminent accident, and only sent to the vehicles affected.

Figure 5:4

Figure 5:5

6. Calculating Safety Distances

e will here make some rudimentary calculations and see where we end up. Using our formula and those conditions given on this page, we will, for trunk beams, allow two alternative top speeds of: 120 km/hour (= 33.3 m/sec.) and 140 km/hour (= 38.9 m/sec.), and for inner city and other beams top speeds of 60 km/h (= 16.7 m/sec.) and 80 km/h (= 22.2 m/sec.). We will allow a reaction time of 0.15 seconds, and 3 consecutive scans to ascertain the nature of an obstacle. This reaction time will thus include at least 3 consecutive scans of an object and the evaluation and consequent decision regarding these by the vehicle´s computer. As this time might considered tight, let us also consider a reaction time of 0.30 seconds. We will set the area covered at the end of the beam´s required scanning distance to 3 by 3 meters, which is indicated by h and w in figure 5:3. The scanning distance D would then have to be at least as long as the safety distance between the beamcars. Using the formula D = v * r + (v2)/(2 * a) + (v * a)/(2 * j) + L, and assigning the following values: v = speed (meters per second); we will use the four values mentioned above a = acceleration or retardation. We will set this to 2 * g which is 19.6 m/s3. r = reaction time = 0.15 and 0.30 seconds in these calculations L = the length of the car; let´s arbitrarily set this to 6 meters D = scanning distance in meters. Depending on where on the vehicle the scanning device is mounted, D is equal to the safety distance between the vehicles, minus the whole or a part of the length of the scanning vehicle.

j = "jerk" at retardation, i.e. how the rate of retardation changes over time. A free-falling object has for instance j = 0 (almost) during the fall. It is not exactly zero, because earth´s gravitational force increases somewhat the closer to earth´s center that the object gets. But for most practical purposes, one could set this value to zero. But at the moment we let go of the free-falling object, and again when it hits the ground, the jerk-factor would be considerably higher. We will set the jerk factor to 24 m/s3. in our calculations here, and include a column in the table where we set j = infinite and thus ignore this term in the equation. This gives us the following abbreviated equation for "orderly braking" (for j = 24): D = v * r + (v2)/39.2 + (v * 19.6)/48 + 6 m. And, for j = infinite, "emergency braking", we get an even shorter equation: D = v * r + (v2)/39.2 + 6 m. Calculating for the 4 speeds we used as examples above, we get, with r = 0.15 s D = 16.7 * 0.15 + 7.11 + 6.82 + 6 = 2.50 + 7.11 + 12.82 = 22.43 D = 22.2 * 0.15 + 12.57 + 9.06 + 6 = 3.33 + 12.57 + 15.06 = 30.96 D = 33.3 * 0.15 + 28.29 + 13.60 + 6 = 5.00 + 28.29 + 19.60 = 52.89 D = 38.9 * 0.15 + 38.60 + 15.88 + 6 = 5.84 + 38.60 + 21.88 = 66.32 And with r = 0.30 s, we get: D = 16.7 * 0.30 + 7.11 + 6.82 + 6 = 5.00 + 7.11 + 12.82 = 24.93 D = 22.2 * 0.30 + 12.57 + 9.06 + 6 = 6.67 + 12.57 + 15.06 = 34.30 D = 33.3 * 0.30 + 28.29 + 13.60 + 6 = 10.00 + 28.29 + 19.60 = 57.89 D = 38.9 * 0.30 + 38.60 + 15.88 + 6 = 11.67 + 38.60 + 21.88 = 72.15 Resulting in the table below. As one can see from the table, safety distances grow considerably with increasing speed. But what one can see from this table is that doubling the reaction time has a rather marginal effect on the required safety distance.

Figure 6:1	The reaction time This time can be divided into several components: scanning the required area (h * w in figure 5:4 above) 3 times in succession after each scan; process the data in a computer after each processing; make a computerized evaluation Figures 6:1 and 6:2 show the steps that have to be gone through before a decision about braking the vehicle can be taken. The number of scans before a decision should not be lower than 3, to avoid braking unnecessarily. Figure 6:1 shows the scenario for a beam vehicle that makes it own scanning and its own evaluations. Figure 6:2 shows how a stationary scanner would work. In this scenario, it has to make decisions as to whether the situation warrants an alert, and, if so, which vehicles to alert. The objects seen will of course include various beam vehicles, and the evaluation made by the stationary scanner has to include known movements of vehicles within the scanned area, and see whether these movements agree with what the scanner sees.	Figure 6:2

7. Looking Around Corners

Figure 7:1

here are two general rules to be adhered to when designing the FLYWAY® obstacle detction system. These are: It is always preferable for the beamcars to be able to stop in an orderly manner, if need be, rather than having to use the emergency braking The scanner should be kept informed of approaching beamcars, so as not to emit any alert unnecessarily whenever it detects an object. The best technical solution for mobile scanners for obstacle detection, when approaching sloping beams, curved beams and weaving nodes is, of course, to: re-align the scanning units on the beamcar, and have it look around a bigger perimeter, both vertically and horizontally, as the situation demands alternatively, have it look in different directions, vertically or horizontally as the situation requires, without necessarily extending or shrinking the perimeter. Figure 7:2

This would, however, make the whole scanner function more complicated and expensive and, consequently, would also make the beamcars more expensive. Since the cars would number in the thousands for a big network, it would probably be cheaper to use stationary scanners and such points, optimally aligned to cover the necessary windows, and have the scanner units contact the beamcars if the detect something that should be reported, using Bluetooth or similar communication. Sloping Beams Figure 7:1 illustrates how this would work for a sloping beam. That beamcar A needs to contact the stationary scanner is pretty obvious. But also beamcar B needs to maintain this contact. This is because the carriage is horizontal, and its scanner is consequently looking horizontally and not along the sloping beam. The corresponding arrangement is needed when a sloping beam becomes horizontal again. Long stretches of sloping beams might have to be scanned in a similar manner, with stationary scanners positioned at regular intervals, communicating with the beamcars. Weaving nodes Weaving nodes would also have to be scanned, each with a stationary scanner, positioned as shown in unit 1 in figure 7:2. It is clear that beamcars A, C and D need to keep contact with the stationary scanner. Cars E and F have to establish contact with the stationary scanner well before coming inside the scanning parameter, for the two reasons stated above. Curving beams The beamcar scanning angle is relatively narrow, and so there is a need for stationary units where the beams curve, as shown by unit 2 in figure 7:2. If something serious happens to car C, car F would not be able to detect this on its´ own.

8. The Technical Function of a Stationary, Ladar-based System

Figure 8:1

s stated, for a stationary detection system to function properly, the scanners have to be overlapping each other, with plenty of redundance. Look at bird-eye view in figure 8:1 above! What chance do the scanners have to detect the "Mysterious object"? Well, all of them, theoretically, if they have an uninterrupted view. But only scanners 4 and 5 could be relied upon to not be blocked by beamcars at the critical moment, assuming that scanners, beamcars and the "Mysterious object" are all in the same horizontal plane, directly underneath the beams. One would of course, in reality, mount the scanners on different heights above the ground, varying their angles in the 3-dimensional space as much as possible, in order for them to complement each others optimally. Each scanner will have reference data stored, showing what its field of view "should" look like. There would be different views to compare with, to use for varying weather conditions and light. Probably, there will be a reference view for; bright sunlight overcast daylight night and also a suitable set of views for rain, fog, and the like.

The scanner will "know" from time to time, by comparison of certain views with their stored "reference views" scanned under all visibility conditions, which of these stored views to use as a reference. The computer doing the evaluation will be intelligent enough to compare different scanning modes and evalute the scannings tor optimum result. Reporting detected Objects The scanner could conceivably send a report for every object it sees. Or, the scanner could be provided with data as to when and where beamcars will be passing through its field of vision. In this way, the scanner could identify the objects, and have no need to report them. A scanner could of course be thought to recognize a beamcar on its own, without needing input information about coming beamcars, but the point is that all beam vehicles appering in its field of vision should be identified, as a safety precaution. Thus, non-identified objects of every kind should always be reported. So, to whom should these reports go? The regional computer should always be informed. This computer could then alert all affected beamcars in its area. But, since time might be critical, reports should also go directly from the scanners to all affected beamcars!