text:
|Publication number
|Publication type
|Application number
|Publication date
|Oct 13, 1998
|Filing date
|Aug 5, 1996
|Priority date
|Aug 5, 1996
|Fee status
|Also published as
|Publication number
|Till W. Liepmann
|Original Assignee
|Pacific Sierra Research Corp.
|Export Citation
|BiBTeX, EndNote, RefMan
|Patent Citations (3), Non-Patent Citations (7), Referenced by (47), Classifications (10), Legal Events (11)
|External Links: USPTO, USPTO Assignment, Espacenet
This application claims the benefit of U.S. Provisional Application(s) No. 60/002,217 filed Aug. 11, 1995.
Traffic control and roadway maintenance management require that traffic loading of roadways be determined. One accurate and inexpensive method of determining traffic load is by counting axles through tapeswitch sensors and air switches. These sensors provide detection of wheels for each lane of the roadway without the permanent installation required by video, microwave, radar and inductive-loop sensors.
Tapeswitch and air switch axle counters suffer from three serious problems: short lifetime, installation safety issues, and the traffic interruption required for installation. However, the alternative methods also have problems that prevent their replacing tapeswitch vehicle counters. Automatic video camera vehicle counters require complex software, permanent overhead installation, have difficulty making velocity measurement, and require massive data processing. Overhead infrared vehicle counters can only measure one lane at a time, and require permanent installation. Commonly used axle detector systems using video cameras (or machine vision) do not count axles directly but use images of vehicles to deduce the axle count. Furthermore, video systems are not as rugged, simple and compact as simple non-contact LED light sources and photodetectors. Also, video systems are mounted on a pole, whereas this type of sensor can be located at the level of the roadway, and does not distract the drivers.
This need provides an opportunity to develop a Line of sight Axle Detector (LAD) that counts axles using interrupted light beams arranged in a proprietary array. A special computer algorithm is used to optimize traffic detection, thereby reducing the error rate. Detection is via the vehicle tires and wheels, which are opaque to light and infrared radiation.
I have conceived a tapeswitch compatible axle detection sensor Line of Sight axle detector (LAD) that overcomes the above mentioned problems. Based on a unique counting technique conceived for this purpose, I use non-contact line-of-sight (LOS) sensor (optical, infrared or ultrasonic sensors) that can detect the wheels of vehicles without any roadway modification. Further, the system employing such sensors is able to measure vehicle counts, lane displacement, lane changes, velocity, headway, gap (distance between vehicles), axle counts, and wheelbase. The key to using these sensors is in the method used to detect the passage of several vehicles simultaneously. By angling these sensors and using a source on the opposite side of the roadway, the computer of the system can determine the presence of a vehicle axle and the lane in which the axle is located. FIG. 1, described below, shows this schematically. Multiple sensors allow the LAD computer to detect several vehicles in different lanes simultaneously and uniquely. For example (referring to FIG. 1), a vehicle traveling in lane (1) will block sensor a, then b, then c and so on. However, if that same vehicle is traveling in lane (2), it will block sensor a, then b, then d, then c and so on. The computer can use the sensor blocking logic and the time between LOS sensor signals to determine the lane, speed, headway, gap, axle counts, and wheel base. The output can be made tape-switch compatible or, as part of a traffic management system, operating in real time via a telephone date link. Since the technique is non-contact, there is no wear, and dangerous installation is not required. This technique will be low cost, easily to deploy, reliable, unobtrusive and provide lane definition over four lanes. The unit can be moved from place to place, since no permanent installation is required. The redundance in LOS sensors and internal computer software will protect the performance from road debris, snow, rain and other obstacles. The photo detectors and LED sources are safe and have lifetimes of thousands of hours, making the operating cost of the LAD less than all other technologies.
This invention may be more clearly understood with the following detailed description and by reference to the drawings in which:
FIG. 1 is a top plan view of a traffic sensor array in a multi laned roadway in accordance with this invention;
FIG. 2 is a time line display illustrating lane discrimination employing this invention;
FIG. 3 is a time line display similar to FIG. 2 with one blocked sensor;
FIG. 4 is a display of sensed signal signatures associated with different types of sizes of vehicles;
FIG. 5 is a simplified system flow chart;
FIG. 5A is a more comprehensive data processing flow chart;
FIG. 6 is a graphical representation of VBM geometry;
FIG. 7 constitutes three different graphical representation of window opening logic;
FIG. 8 is a time vs. speed graphical representation of asymptotic approach to equilibrium for a four lane highway simulation with 1000 cars per lane;
FIG. 9 comprises a pair of graphical representations of (a) headway vs probability (simulated) and (b) headway vs probability (observed);
FIG. 10 is a graphical representation of simulated lateral vehicle displacement within lanes for N=1000 simulation;
FIG. 11 comprises a pair of graphical representations of (a) mean traffic density vs mean traffic speed and (b) traffic flow rate vs mean traffic speed for nine different scenarios;
FIG. 12 is a layout of a four lane prototype sensor array;
FIG. 13 is a simulated wave form display of 10 second beam responses for the prototype array of FIG. 12;
FIG. 14 is a graphical display of failure probability vs mean traffic density;
FIG. 15 comprises a pair of graphical representations of failure as a function of beam angle at two different beam separations;
FIG. 16 is a simplified block diagram of an axle counter demonstrated layout;
FIG. 17 is a photograph of the prototype demonstrated in FIG. 16;
FIG. 18 is a block diagram of one emitter/detector channel of the prototype of FIGS. 16 and 17;
FIG. 19 is an electronic schematic diagram and cable identification for the interface electronics of FIG. 18; and
FIG. 20 is a layout diagram of the circuit board of the prototype of FIGS. 16 and 17.
Now referring to FIG. 1 in connecting with FIGS. 2-5, a typical installation of this invention may be seen. In FIG. 1, a roadway RW with four lanes 1-4 in one direction is shown with a light source array 10 on one side of the roadway RW and a sensor array 11 on the opposite side of the roadway. The light sources preferably are light emitting diodes (LED) and the sensors are preferably Schmitt trigger silicon photodetectors. Five light paths a-e are shown. The light source array 10 is powered by a power supply unshown and the sensors are coupled to the signal processing system of FIG. 5A. Each path a-e may be either a single beam or dual beams spaced by a predetermined fixed spacing apart as discussed below.
The line of sight axle detector LAD crossed LOS sensor geometry of FIG. 1 makes the detection and tracking of individual axles possible. Axles in the different lanes can then be discriminated by the order in which the LOS sensors are blocked. A vehicle axle traveling in lane 1 alternately blocks the LOS of each individual sensor in order; that is, a,b,c,d,e,f. FIG. 2 shows this graphically. An axle in lane 2, on the other hand, blocks the sensors in a different order: a,b,d,c,e,f. Similarly, the detection of vehicles in all four lanes are uniquely determined by the order of detector signals.
The LAD geometry and detection technique compensate for simultaneous blocking of the detectors by different axles in different lanes. FIG. 2 illustrates the detection time line for three cases: an axle traveling in lane 1, an axle traveling in lane 2, and two axles simultaneously traveling in lanes 1 and 2. A valid track (or count) of an axle in a lane requires that there be a full sequence of hits for a unique sequence (i.e., a,b,c,d,e,f for lane 1) of sensors in time. This is somewhat analogous to a winning sequence in the game of tic-tac-toe. Further, it is clear that this approach will discriminate between any number of axles in any combination, including four axles (one in each lane) simultaneously. This approach will even work with two-way traffic. Finally, the velocity of each axle is measured by the slope of the track line.
The LAD is designed to be fault tolerant, since roadway debris and weather will occasionally block the LOS of one or more sensors. FIG. 3 shows the same detection example of FIG. 2, only with a blocked sensor "C". Note that the redundant detectors prevent that failure from causing a missed or superfluous axle count(s). Adding sensors will increase the robustness of the approach.
Vehicles are identified by sets of axles traveling at the same velocity and with the same wheel diameter. The vehicle is bounded by limits on the wheelbase. The wheel diameter is measured by the width of the LOS sensor "off" time multiplied by the velocity. Wheelbase is measured by the distance between the axles of the vehicle, measured by the time between the axles of the same vehicle multiplied by the velocity. FIG. 4 shows the LAD and the vehicle classification concept. Spatial headway is measured as the time between the front axles of different vehicles, with a correction factor to account for the vehicle overhang (the distance from the wheel to the vehicle bumper).
The analysis of the LAD data also determines the lane displacement of the axle in the lane. This is determined by the signal timing between adjacent detectors in the lane. Because of the angling of the LOS detectors, the time between signals is proportional to the position of the axle in the lane.
The LAD multi-lane vehicle axle counting technique of this invention uses a method of opening tracking gates at predicted time intervals beyond initial wheel detection. This method permits simultaneous tracking of closely spaced vehicles in the same lane, or in multiple lanes. The performance of such techniques depends on the precision of velocity estimates derived from initial beam interruptions. This section summarizes an analysis of two methods for estimating vehicle velocity from the interruptions of a pulsed beam caused by wheel interference.
The single beam (1B) method estimates velocity from the number of interruptions caused by a wheel of an assumed diameter interrupting the beam. In addition to granularity errors, this method also suffers from errors induced by assuming some average wheel diameter when, in fact, wheel sizes vary considerably. One problem discovered with the method is errors during multiple, near simultaneous axles cause exaggerated velocity errors.
Subsequent to this analysis, it was decided to employ a CW or quasi-CM (high pulse rate) beam. In this case, velocity estimates will be very precise, obviating the need to calculate the variance of such estimates. This section is intended to provide guidance should pulse-beam velocity estimates be reconsidered in the future.
The dual beam (2B) method uses the time between the onset of interruptions at two beams separated by a known distance. Granularity due to the finite time between light source pulses is the source of error in this estimate. However, light pulses with a frequency of 2 kHz (or more) will reduce the error to insignificance.
The dual beam velocity estimate is ##EQU1## where D0 is the known distance between the beams, n is the random number of pulses between the time the first and second beam crossing, and Δt is the time between pulses (i.e., R=(Δt)-1 is the pulse rate). Note that the only random element in v2B is n since the time between beam LOS crossing and beam interruption is random.
Assuming a wheel diameter D equal to the average for a typical vehicle distribution, the single beam estimate is ##EQU2## where m is the number of pulses interrupted by the wheel moving through the beam LOS, and Δt=R-1 as above. In addition to the uncertainty introduced by the random interval between crossing the beam LOS and interrupting the first pulse, there is also a random error caused by assuming D is fixed when it should be regarded as random. We assume actual wheel diameters are distributed over the interval D1, D2 !.
The following parameter values were chosen for the tabulated results below: D0 =30 cm, D1 =40 cm, and D2 =80 cm. The true, but unknown, vehicle velocity is fixed at v=60 mph. The pulse rate (in pulses per sec.) is varied as shown in Table 1 below, and the mean and standards deviation (s.d.) are calculated for each velocity estimate in mph.
TABLE 1______________________________________ MEAN (mph) S.D. (mph)Pulse Rate 1B 2B 1B 2B______________________________________300 64.0 61.1 15.6 8.0500 63.6 60.5 14.5 5.51000 63.4 60.1 14.0 2.0______________________________________
1. The Single Beam Method 1B appears to be biased regardless of pulse rate (i.e., E(ν1B |ν)→κ1 ≠νasR→∞), while the Dual Beam Method 2B is unbiased in the limit R→∞.
2. The Single Beam Method 1B appears to be inconsistent with respect to R (i.e., VAR(ν1B |ν)→κ2 ≠0 as R→∞), while the Dual Beam Method 2B is consistent with respect to R.
3. The performance of the Single Beam Method 1B is actually worse than portrayed here since we assume that the distribution of wheel diameters was known while, in fact, this will probably not be the case.
4. The calculations for the Dual Beam Method 2B assumes that the pulses for both beams are in phase. Since VAR (ν2B |ν) is a function of the lag λ between the beam pulse trains, it would be possible minimize VAR (ν2B |ν) by adaptively varying λ as a function of past velocity estimates.
The conclusion of this analysis is that the performance of a dual beam velocity gate greatly improves the LAD system performance, both in accuracy and reliability.
The logic described in this section specifically exploits two key features of the LAD system as developed: lane discrimination inferred from the sequence of beam interruptions, and the virtual impossibility of failure to detect axles i.e., PD =1 in a single traffic lane. The later is a consequence of the fact that sensor failures due to power outage, component breakdown, non-vehicle related beam interruptions, etc. result in beam interruptions that are equivalent to a "detection". Hence, viable logic designs must focus on false detections rather than failures to detect.
The situation becomes more complex when multiple-lanes are considered because of the "shadowing" of one axle by another. Note that both axles can be considered detected in a shadowing episode since the beam is interrupted in their presence. Identifying vehicle tracks through the array when shadowing and non-vehicle beam interruptions are occurring is the challenge.
The approach suggested here uses time windows or gates within the time-line of each sensor to associate detections and thereby identify vehicle tracks. Coupled with the beam ordering concept, this approach not only counts axles, but also identifies lanes and estimates vehicle velocity. Gates are "opened" by means of a velocity-beam module (VBM) which precedes the lane-discrimination array (LDA) as shown in FIG. 5.
The interaction of the velocity-beam module VBM and the lane discrimination array LDA is shown in FIG. 5.
Traffic enters the VBM and upon exit the following parameters are estimated for each axle:
v=axle velocity estimate
a=axle accelerating estimate
x=axle position estimate
For each of exposition we assume that multiple velocity estimates within the VBM are linear in the time (or fitted with a linear regression) providing a constant acceleration estimate a. Generalization to a non-linear (e.g., polynomial) fit for multiple velocity estimates is straightforward. If only a single velocity estimate is available from the VBM, then we set a=0.
The triple (v,a,x) for each axle detection in the velocity beam module VBM is used to open gates within the LDS. Since no lane indications are obtained in the VBM, the LDS must assume that the detected axle could be in any lane. The function of the LDA is to assign a lane to each detected axle from the VBM. Axle counts and velocity statistics may then be recorded on a lane-by-lane basis.
The VBM of FIG. 5 employs at least two velocity beams as shown in FIG. 6. Free parameters include velocity beam-component separation (s), distance between the velocity beams (d) and the slant angle (θ). Optimal values of (s, d, θ) can be found through Monte Carlo simulation. The objective of the optimization should be to maximize to the probability of detecting an axle by at least one velocity beam.
Since shadowing (two wheels from two vehicles blocking the same beam) and overtaking are the dominant sources of error and can lead to inaccurate velocity estimates, one further rejects velocity estimates (and corresponding axle counts) that lie outside some acceptance interval. In practice that interval should be adaptively determined by an error bound about the average of recent velocity estimates. For purpose here, a simple �10% of the true velocity should suffice.
Considering that failure to obtain acceptable velocity estimates from beam interruptions is most likely due to shadowing for small s, as discussed, the axle counts out of the VBM will be biased low. However, shadowing implies the presence of at least two vehicles in the VBM, so a reasonable way to reduce this bias is to count two axles for every inadmissible velocity estimate. Of course, lane assignment for such vehicles will not be possible since the LDA requires accurate velocity estimates.
The component spacing s should effect PD independently of d and θ. Overtaking and shadowing effects suggest PD should vary inversely with s until s is so small that the sample rate of beam interrogation limits further improvements in PD and the variance of the velocity estimate. At this point, a high sample rate would be required to increase PD. Also note that setting θ=0 is highly desirable so that the positional estimate x is independent of lane displacement. If PD for θ=0 is reasonably close to its maximum over the range ##EQU3## then θ=0 should be used. LANE DISCRIMINATION ARRAY (LDA)
Lane discrimination follows the basic concept, where four beams, e.g., b,c,d, & e of FIG. 1 are employed in a crossing pattern. Clearly, more beams can be used to improve reliability and accuracy. Since lane geometry restricts the length of this array measured along the direction of traffic, a single array is highly susceptible to shadowing induced errors (i.e., clearing a shadowing episodes requires a distance in excess of the array dimension). Accordingly, placing a second array, namely a duplication of source 10 and sensors 11 a distance d' from the first will increase the probability that at least one array will avoid shadowing of a given axle. Simulation should be used to optimize d'.
The (v,a,x) output of the VBM is used to open intervals or windows along the time lines for each sensor beam response. Independent algorithms operate for each of the four lanes. Take Lane 1 as an example. A window is opened for the first beam encountered in Lane 1. The length of this window can be determined from the error induced by the uncertainty in expected time of arrival (ETA) due to the statistics of (v,a,x), or it can be optimized in simulation. In any case, since the axle detected in the VBM will almost certainly break the beam within the window, if the beam is never interrupted (i.e., "off") within this interval, then this vehicle can be assumed to be in a lane other than Lane 1.
If there is non-empty set of "off" times within the window, then a window is opened on the timeline for the next beam in the sequence unique to Lane 1 as shown in several examples in FIG. 3. In situation (3a) a single off interval t1,t2 ! occurs at sensor 1 within window w1, resulting in window w2 opening at beam 2. The start time t5 of w2 is given by t5 =t3 -δ, where δ is to be optimized in simulation, ##EQU4## is the beam separation in Lane 1 and v1 is the velocity estimate update of (v,a,x) using the leading wheel edge crossing of the first beam at time t1. Note that we assume a=a=0 for this simple example. Likewise the closure of w2 occurs at t6 =t4 +δ, where t4 = ##EQU5## and v2 is derived from the trailing edge position in Lane 1 at time t4.
FIGS. 7b and 7c generalize the procedure discussed above for FIG. 7a to the cases where a sensor fails (always "off"), and where there are more than one "off" interval, respectively. The opening of windows continues in this manner until either: (1) the chain is interrupted by the beam being "on" throughout the window, or (2) all beams yield a detection within their respective windows. In the former case, no lane assignment can be made (perhaps due to a lane change), and in the latter case the axle may be assigned to the lane in question. In high traffic density more than one lane may be aligned to a given axle detection out of the VBM. This axle should be counted once, but it should not contribute to the update of lane velocity statistics.
The window size parameter δ is expected to have dramatic effect on LDA performance. If δ is too small, some legitimate chains will be broken and missed lane assignments will result. On the other hand, if δ is too large, multiple lane assignments for a single axle will result. Hence it is important to optimize the choice of δ as discussed below.
The VBM and LDA may be tested separately. After noting the traffic density regime for which algorithm performance rapidly deteriorates, the parameters controlling the logic for the VBM and LDA should be optimized to improve performance within this regime. Clearly, more attention should be given to the module that breaks down under the most benign traffic conditions. Note that for the VBM, breakdown consists of excessive failures to detect an axle, while for the LDA breakdown occurs when no lane assignments can be made due to too many window detections.
The LAD system offers the ability to collect highly time-resolved traffic statistics for multilane highways without the usual deployment difficulties and high maintenance costs associated with convention roadbed installations. Its principal of operation relies on the fact that, even under the heaviest free-flowing traffic conditions (i.e., at capacity), the probability of a temporal overlap between any two wheel silhouettes produced by vehicles in different lanes is quite small--certainly much less than five percent for traffic consisting primarily of two-axle passenger cars. Therefore, under most conditions of interest, it is possible to detect unambiguously the number and time-of-arrival (and therefore velocities) of nearly all axles crossing any point along the highway.
Capacity as used above is defined as the maximum sustained rate of traffic flow that can be expected to pass a uniform section of freeway under prevailing roadway, traffic, and control conditions Appendix A, Reference 3!. For ideal conditions (e.g., 12-foot minimum lane widths, 6-foot minimum shoulder and median clearance, good weather, and passenger cars only in the traffic stream), capacity averages about 2000 pcphpl (passenger cars per hour per lane) and corresponds to an average travel speed and vehicle density of 30 mph and 67 pcpmpl (passenger cars per mile per lane), respectively.
But as vehicle densities increase and freeway speeds slow, traffic typically passes from a state of uninterrupted, free-flowing motion to an unstable "stop-and-go" condition. In this state, the duration of all beam blockage events increase substantially, leading to a much greater probability of mutual blockage between wheel silhouettes. Detection error increase commensurately and eventually, will exceed some tolerable limit. At this point the system can be said to have reached its breakdown point. For any prototype design, it is essential to discover exactly at what combination of traffic conditions (e.g., flow rates, speeds, densities) breakdown occurs. Once the breakdown point has been identified, attempts should be made to reduce the detection error by testing various combinations of beam angles and separations. In this way a system design can emerge which is optimized to perform over the widest range of traffic conditions.
In this section I discuss the progress made toward an optimized system design during the LAD development. This work was performed exclusively by means of computer simulations of both the traffic flow and the detection algorithm. In the next section, I describe the model used to simulate the microscopic (resolved car-by-car) characteristics of a multilane stream of cars moving past a point along a freeway. The "traffic scripts" generated by this model are used as an input to a second model, which simulates the response of the LAD system to the passage of axles through the beam array and tests the detection algorithm. Use of this model for identifying the system breakdown point and optimization of the array geometry is discussed below.
Complete testing of the LAD system requires several realistic sets of input data in which the speeds and times-of-arrival of individual vehicles in each lane of a multilane highway are prescribed. These data sets should encompass the entire range of likely operating conditions, from uninterrupted low density traffic through stop-and-go conditions. Early in the efforts, attempts were made to locate and obtain such data. I found that data this finely resolved in space and time is not available for any traffic conditions, let alone for the full range of conditions needed for system design and optimization. Consequently, I was forced to use computer modeling to generate our own simulated traffic data.
We model the microscopic passage of cars past a point using an adaptation of the Greenshields nonlinear traffic-following model Appendix A, References 1 and 2!. This model is based on four simplifying assumptions.
(1) Traffic in each lane is strictly one dimensions, unidirectional and uncorrelated with traffic in any other lane;
(2) Traffic consists of a single vehicle type (dual-axle passenger cars);
(3) Vehicles do not change lanes; and
(4) Speeds and accelerations are internally controlled and not affected by any external influence over the traffic stream.
In addition, the model incorporates two common sense notions of traffic kinematics:
(a) The sign of the acceleration of an individual car is directly proportional to its velocity relative to the car immediately ahead of it (i.e., whether it is catching up or lagging behind), and
(b) The magnitude of the acceleration/deceleration is inversely proportional to the distance between the two vehicles.
For an arbitrary vehicle n within a traffic stream containing N cars, Greenshields model can be expressed: ##EQU6## where Xn and Vn denote the position (tagged to the front bumper) and velocity, respectively, of the vehicle at time t; τ=0.4 sec is a small time increment assumed representative of the reaction time of a typical freeway driver; C and am are adjustable parameters; and δn is a normal-distributed random deviate with zero means and unit variance. Here we have ordered the cars such that Xn-1 >Xn --i.e., Car #1 is furthest downstream in the traffic stream, followed by Car #2, etc.
Equation (1) contains two empirical parameters which must be specified. The first parameter C, which has units of velocity, is a global constant chosen to give the correct relationship between speed and density when the traffic statistics are averaged over space and time. Following Appendix A, Reference 2, I chose C to be equivalent to the mean traffic speed at capacity. Thus, for ideal four-lane freeway conditions, I set C=30 mph Reference 3!. The second parameter, am, is a small lane-specific adjustment factor which, when multiplied by the Gaussain deviate δn and the global constant C, approximates in a crude way the distribution of engine powers and drivers' styles typical of individual cars in each lane m on a freeway. For the simulations reported here, I choose am =(0.20, 0.15, 0.10, 0.05) for m=1,2,3, and 4, respectively, where Lane 1 is assumed to lie adjacent to the shoulder (the "slow" lane) and Lane 4 is next to the median (the "fast" lane).
I apply Equation (1) to each of the N vehicles in Lane m with δn chosen at t=0 and held fixed throughout the simulation. The model therefore takes the form of N coupled differential equations with variable coefficients. "Forcing" is provided by a fictitious pace car at the head of the queue ("Car #0"), whose velocity V0 is externally prescribed as a function of time independent of Eq. (1). Early experiments with this model found that by prescribing a time-varying V0, a wide variety of realistic traffic behaviors could be produced upstream (i.e., for n≦1), including local density rarefaction and compressions, queuing motion, and traffic "waves" which propagate upstream at a phase speed controlled by the reaction time τ. To generate statistics for system design and optimization, however, a much simpler scenario was devised in which the pace car is assumed to travel at a time-invariant V0 representative of all cars in Lane m. Each vehicle behind the pace car, starting from rest and initially arrayed bumper-to-bumper, then develops its own "natural" acceleration and speed based on Eq. (1) as it follows along. For these simulations, we use N=1000 cars per lane and integrate Eq. (1) with a 0.01-sec. time step using a first-order, time-forward (Euler) marching scheme to obtain updated velocities Vn,m. These velocities are then integrated once more to arrive the updated vehicle positions Xn,m. Integration proceeds until the mean travel speed (integrated over all N cars) has asymptotically converged to the pace car speed V0 as illustrated in FIG. 8. The time-or-arrival for each car at an arbitrary point far downstream from the start of the queue (X=0, the starting position of the pace car) is then recorded, and the resultant "traffic scripts" used for system testing of specific system geometries.
TABLE 2______________________________________Sample traffic simulation script (extract) for V0 = 49mph at X - 70 miles. LateralCar Time of Arrival Speed, Gap, Headway Displacementn HH:MM:SS Va (mph) Ga (VL) Ha (sec) Ya (ft)______________________________________1 1:26:17.90372 49.0 2.393 2.205 1.1642 1:26:19.53502 49.0 8.907 1.631 0.1253 1:26:22.36237 49.0 16.171 2.827 1.8144 1:26:24.43530 49.0 11.589 2.073 -0.0465 1:26:27.40623 49.0 17.043 2.971 -0.2736 1:26:32.17946 49.0 27.989 4.773 0.2287 1:26:34.97256 49.0 15.963 2.793 0.6838 1:26:36.13024 49.0 6.031 1.158 -2.2069 1:26:38.19063 49.0 11.513 2.060 2.32310 1:26:39.55090 49.0 7.261 1.360 -0.63311 1:26:41.04116 49.0 8.051 1.490 -0.65012 1:26:43.49230 49.0 13.886 2.451 -1.40213 1:26:45.54862 49.0 11.489 2.056 0.43114 1:26:46.90783 49.0 7.255 1.359 -0.65815 1:26:48.47640 49.0 8.526 1.569 1.16216 1:26:50.89148 49.0 13.667 2.415 -0.34417 1:26:53.36594 49.0 14.028 2.474 -0.27718 1:26:55.39531 49.0 11.325 2.029 0.49919 1:26:57.79254 49.0 13.559 2.397 -0.01220 1:26:59.51567 49.0 9.465 1.723 -0.68921 1:27:0.98029 49.0 7.895 1.465 -1.61822 1:27:2.74821 49.0 9.737 1.768 -0.29023 1:27:4.89985 49.0 12.067 2.152 -0.00224 1:27:6.48561 49.0 8.631 1.586 -0.46125 1:27:8.09371 49.0 8.766 1.608 0.19126 1:27:9.93477 49.0 10.181 1.841 2.93127 1:27:11.59166 49.0 9.063 1.657 1.28828 1:27:14.19472 49.0 14.809 2.603 -0.24929 1:27:19.62633 49.0 31.987 5.432 -0.63230 1:27:22.47397 49.0 16.294 2.848 -1.96731 1:27:23.89006 49.0 7.600 1.416 -0.59632 1:27:25.83442 49.0 10.809 1.944 -1.03533 1:27:27.00127 49.0 6.087 1.167 1.50834 1:27:28.52281 49.0 8.241 1.522 1.47635 1:27:30.38873 49.0 10.332 1.866 2.17536 1:27:33.27832 49.0 16.549 2.890 1.55937 1:27:35.37633 49.0 11.742 2.098 -0.53135 1:27:39.20492 49.0 22.252 3.829 1.02539 1:27:41.73035 49.0 14.338 2.525 1.03540 1:27:44.12568 49.0 13.547 2.395 -0.18641 1:27:46.71474 49.0 14.724 2.589 -1.00142 1:27:48.29792 49.0 8.615 1.583 0.17543 1:27:50.07155 49.0 9.772 1.774 -0.75444 1:27:52.15063 49.0 11.627 2.079 0.35545 1:27:54.22422 49.0 11.593 2.074 -0.41546 1:27:56.79839 49.0 14.634 2.574 -0.40847 1:27:58.46169 49.0 9.102 1.663 -0.30448 1:27:59.73991 49.0 6.763 1.278 -3.04349 1:28:1.64573 49.0 10.575 1.906 -0.84750 1:28:3.95073 49.0 12.999 2.305 0.14251 1:28:6.13769 49.0 12.282 2.187 0.59852 1:28:8.64947 49.0 14.255 2.512 1.71853 1:28:14.74414 49.0 36.014 6.095 -0.07954 1:28:18.13578 49.0 19.598 3.392 0.15455 1:28:19.98798 49.0 10.249 1.852 -2.14656 1:28:24.79780 49.0 28.211 4.810 1.37857 1:28:26.98760 49.0 12.299 2.190 1.43958 1:28:30.97853 49.0 23.238 3.991 0.40759 1:28:32.30897 49.0 7.080 1.330 -0.04460 1:28:33.76362 49.0 7.834 1.455 1.97261 1:28:34.98516 49.0 6.419 1.222 -0.95762 1:28:36.76223 49.0 9.793 1.777 1.17663 1:28:38.04659 49.0 6.800 1.284 2.08964 1:28:40.83151 49.0 15.913 2.785 -0.24865 1:28:57.63059 49.0 101.025 16.799 -1.32766 1:28:59.58427 49.0 10.865 1.954 2.624______________________________________
Table 2 shows a portion typical script for a single traffic lane and forcing velocity. Note that even through the velocities of each car are the same, the headway and gap between each varies.
The gap Gn associated with vehicle n is defined Gn =Xn-1 -Xn -L, where L is the end-to-end vehicle length (assumed the same for all n). The headway Hn is a temporal interval between successive front bumper passages at a fixed point; it is defined Hn =(Xn-1=Xn)/Vn.
This variation is a direct consequence of the random function δn incorporated into Eq. (1). Indeed, if I have set δn =0 for all n (or, equivalently, set am =0) I would have obtained a uniform gap and headway in the asymptotic limit. The fact that the gap and headway are not uniform is similar to the situation found in real traffic, where spacings between cars can vary widely, reflecting the opinions of different drivers regarding "safe" following distances. In reality, some of this variation would disappear over time as cars changed lanes or exited the freeway--a mechanism not modeled in my simulations. But we nevertheless find that our simulated distributions of headway to qualitatively mimic real traffic, as illustrated in FIG. 9. In particular, we find that prescribing a relatively large dispersion of accelerations in the slow lane (a1 =0.20), we can reproduce the positive skew in the headway probability distribution characteristic of real traffic, for example, on the Long Island Expressway as reported in Appendix A, Reference 1, DOT, 1985 and shown FIG. 9b. This asymmetry presumably results from the fact that, at any given time, a large fraction of the cars in the slow lane are either decelerating in preparation for exiting the freeway or speeding up in order to merge into the traffic stream. On the other hand, cars in the fast lane (m=4), tend to be traveling more or less at their cruising speed and so have a smaller range of accelerations (a4 =0.05--a fact captured by the more symmetric probability distribution both in the simulation, FIG. 9a and in the available data, FIG. 9b.
Another key simulation variable is the lateral (i.e., perpendicular to traffic) position of each car within its lane. We assume that every car in the simulation is identical, with a wheel track (the lateral spacing between wheels) WV =66 inches (5.5 feet). Therefore, within the assumed standard lane width WL =12 feet, the centerline of each car can be displaced as much as Y=�(12-5.5)/2=�3.25 feet to the left or right of the lane centerline. Such displacements can vary the timing of the beam blockages as the cars pass through the LAD beam array and therefore must be modeled. The approach is to assume that the centerline position Yn of each vehicle as it enters the array is randomly distributed with a symmetric Beta probability distribution of the form: ##EQU7## where Γ(x) is the gamma function and Ymax and Ymin are +3.25 and -3.25 feet, respectively. This distribution guarantees that the most likely displacement of any car is zero, with a small but nonzero probability that the displacement is as much ad 3.25-feet off-center, but zero probability that the tires on either side of the car across the lane boundary. Values for Yn are recorded as part of the simulation scripts, as indicated by the last column in Table 2. A plot of a sample distribution for N=1000 is shown in FIG. 10.
Traffic simulations were completed for nine distinct cases: A baseline case, meant to simulate free-flow conditions on a real four-lane freeway; and eight variants with in which the speed in is each lane is reduced in successive 5-mpg increments. The input parameters for each of these cases, as well as the resultant average speeds, traffic densities, and flow rates are listed in Table 3. Here we have computed the averages much as one would do real traffic--i.e., by counting the total number of cars in all lanes (and recording their speeds) which pass a point during a 15-minute interval, then averaging over space and time and expressing the results on a per-hour and per-lane basis. These results indicate that, while the density increases monotonically with a decrease in traffic speed, FIG. 11a, the flow rate maximizes at 1914 pcphpl (96 percent of capacity) at an intermediate speed around V=30 mph, as illustrated in FIG. 11b. This behavior is consistent with the concept of capacity flow e.g., Appendix A, Reference 1, DOT, 1985!, and is an indication that our model is providing a credible simulation of traffic flow over a fairly wide range of conditions.
As explained above, the LAD system consists of two distinct components: The Velocity Beam Array (VBA), and the Lane Discriminator Array (LDA). Each of these components involves a separate layout of beams and detectors whose configuration must be optimized over a wide range of simulated traffic conditions.
The first task in exploring the optimal layout of the VBA was to determine the maximum traffic density at which a prototype design could perform within the acceptable error range. For this effort I chose a configuration similar to the four-beam layout described above in connection with FIG. 1. A "double X" design consisting of two sets of parallel beam pairs separated by a distance s and set at an angle θ with respect to cross-traffic direction, but with zero separation between the pairs (d=0). I further set, more or less arbitrarily, θ=5� and s=5.5 inches--equivalent to one-fourth the assumed diameter of standard passenger car tire. A scaled drawing of the prototype design deployed on a four-lane highway is shown in FIG. 12.
A key elements in the optimization studies is the system response mode. Using the vehicle time-of-arrival scripts generated by the simulation model and the input parameters θ, s, and d, this model determines, whether or not the wheel of any car is within the line of sight of each beam at any given instant. Here we assume that the beam is blocked if it intersects any portion of a segment equal to the assumed tire diameter Dw =22 inches. Thus we effectively assume that the tires are rectangular (a worst case assumption) and do not consider the possibility of beam passage around their circular profiles.
FIG. 13 illustrates the operation of the response model for the prototype VBA design and the baseline (Case 1) traffic conditions. Like the Tabletop Demonstrator Model discussed below in connection with FIGS. 16-20, we assume that the response is binary--i.e., the detected signal is either ON or OFF. As a result, as traffic passes in front of the beams, an irregular sequence of pulses is recorded. When single cars pass through the array, these pulses appear as doublets corresponding to the passage of first the front pair and then the rear pair of wheels. (Clear lines of sight between left and right wheels is not possible for passenger cars provided θ is less than about 23�.) In this case the velocity of the vehicle can be easily determined, for example, from the difference between the timings of the ON/OFF transitions at Beams A and B or Beams C and D. In general, however, more than one cars may be in the array at any given moment. In these situations (for example, around the 8.5-sec. mark in FIG. 13), the pulse doublets may occur very close together in time or even overlap, making vehicle detection and speed estimation difficult. These are the situations which can lead to errors and must be mitigated by optimization.
The prototype VBA design shown in FIG. 12 was tested against each of the nine traffic scenarios listed in Table 3.
TABLE 3______________________________________Traffic simulation cases. Mean Prescribed Vehicle Speeds, V0 (mph) Mean Density Mean Lane Lane Lane Speed V ρ Flow FCASE 1 2 3 Lane 4 (mph) (pcpmpl) (pcphpl)______________________________________ 1a 49 51 58 62 54.8 25.6 14572 44 46 53 57 49.9 31.8 15873 39 41 48 52 44.9 38.0 17064 34 36 43 47 39.9 45.2 18075 29 31 38 42 35.0 53.7 18816 24 26 33 37 30.0 63.6 19147 19 21 28 32 25.3 74.7 18888 14 16 23 27 20.5 86.7 17809 9 11 18 22 16.0 97.7 1561______________________________________ a Baseline case: Highway I8, San Diego, CA DOT, 1985
For each test, a total of twelve simulations were carried out, each consisting of a five-minute sequence of traffic. Each traffic sequence was generated in such a way as to be independent of the others by randomly perturbing the starting time of the traffic scripts for each lane. In this way we effectively introduced a random phase shift between each lane, while still maintaining the same combination of traffic speed and density.
For each simulated axle crossing, we rated the VBA response as either a success or a failure. Success was declared only if both of the following conditions were met:
(1) A distinct ON/OFF or OFF/ON transition was detected at both Beam A and B or Beams C and D (condition of minimal overlap), and
(2) The estimated velocity associated with each axle crossing was within �5% of the true velocity as recorded on the input traffic script (condition of minimal overtaking).
Note that according to this definition, a success was scored if one of the VBA pairs detected a distinct axle passage. But if neither of the beam pairs recorded a successful detection, a failure was scored.
FIG. 14 shows the estimated probability of failure PF for the prototype VBA design as a function of mean traffic density determined by applying the scoring method to the nine traffic simulation cases listed in Table 2. I find that at relatively low density (free-flowing) four lane traffic, this design performs quite well. Indeed, for the baseline traffic case (Case 1), I find that the system detects and correctly estimates the speed in excess of 99 percent of the time. But as traffic builds and densities increase, FIG. 14 shows that system performance gradually degrades, eventually reaching its breakdown point (arbitrarily defined as PF ≦5%) at about ρ=75 pcpmpl (Case 7 in Table 3). Referring back to FIG. 11b, I see that this breakdown density lies beyond the peak in the simulated flow rate curve. Therefore, even without attempting to optimize the parameters θ, s, and d, I find that the VBA performs within the specified margin of error for all free-flowing traffic situations and only begins to break down as stop-and-go conditions develop. Note that I would expect much better performance for 3 or fewer lanes (100 percent accuracy is predicted for all cases of one lane traffic.)
In order to determine the optimum combination of parameters for the VBA design, I performed an additional series of simulations for traffic scenario Case 7. In these simulations, I held the interbeam spacing fixed, while independently varying the beam angle between θ=0 (perpendicular beam) and θ=20� and the separation distance d between 0 (the X-configuration) and d=WL (=12 feet, the standard lane width). The resultant variation in probability of failure detection PF is shown in FIG. 15 for two values of the interbeam spacing S. These results indicate that the best layout for the VBA--at least from the standpoint of minimal detection error--is to either place the beams in an X-configuration (d=0) at θ≈5� (i.e., the prototype design), or to widely separate the beams by 12 feet or more and have them traverse the roadway perpendicular to traffic (θ=0). In either case, a probability of failure in the vicinity of the breakdown threshold PF=5% can be expected, although these results could change if realistic variations in wheel diameter, vehicle types, accelerations, etc. were accounted for.
Description of Model
A table-top demonstration model breadboard was fabricated to illustrate the principles involved in LAD. This demonstrates 1/18 model cars MC1 and MC2 on a two lane highway. There are four pairs of AlGaAs Infrared Light Emitting Diodes 20a,b-23a,b and Silicon Photodetectors 24a,b-27a,b in the arrangement of to FIG. 16. Two pairs 20a,b and 21a,b use a light beam perpendicular to the roadway RW. The other two pairs 22a,b and 23a,b cross at approximately a 45 degree angle intersection at the center stripe dividing the lanes L1 and L2. All four LED/Photodetector pairs 24a,b-27a,b are controlled by a signal conditioner 25 which in turn is controlled by a counter timer board which plugs into a standard PC computer. The model cars MC1 and MC2 (Mustang and Alpha Romero) are pushed by hand along the model two lane highway RW to interrupt the light beams. The signal is processed by the computer to generate data on:
Lane discrimination
Velocity Determination
Wheel Base Distribution
Lane Displacement.
A photograph of the Model is shown in FIG. 17.
Referring now to FIG. 18, the circuitry of one channel is shown including the light source, e.g., LED 20a and a photo detector 24a. Power for the LED light source is supplied by its driver 30 and a conventional D.C. power supply. A separate or this same source may be used to supply power to a detector 31, 32 signal conditioner 34 and a PC adapter card 32 which provides signals over a bus 32 to a computer PC. When combined with the output of diodes 24a,b-27a,b of FIG. 1, the computer PC can provide the following data for the roadway monitored during the period monitored:
vehicles/hour on the roadway
vehicles/per lane on the roadway
vehicle velocity distribution/lane
vehicle classification
vehicle acceleration
vehicle deceleration
vehicle displacement from lane centerline
when utilizing the program set forth in Table 3.
The detector signal conditioner 31 and PC adapter card are located on the printed circuit card 33 shown in photograph, FIG. 17 in the layout shown in FIG. 19 including seven integrated circuits 40-46.
A block diagram showing one LED/Photodetector Path is shown in FIG. 18. The LED 20a is continuously running. Two interrupt signals are generated when the LED/Photodetector Path is broken. The first interrupt (start interrupt) designates the beginning of the path being broken and the second interrupt (stop interrupt) designates the path being clear again. The computer PC software records the time of each interrupt and the status or type of interrupt (start or stop) for this one LED/Photodetector pair 20a,b and 24a,b.
The start and stop interrupt-time values from all four detectors are collected by the PC software when a car passes through the LED/Photodetector paths. The PC software then processed these interrupts time values and generates data as outlined above.
The computer software employed accompanies this application as Appendix B. It is written in "C" and may be run on any IBM computer, 386 or better.
LED Emitter: Photonic Detectors High Powered Infrared Emitter, 100 ma max current, 5 Degree Beam Angle, at 800 nm wavelength. TO 46 can with plastic collimating lens.
Photodetector: Optologic Model QSA 156, Silicon Photodetector with internal Schmitt Trigger that is TTL logic compatible. Hermetically sealed in TO5 can with plastic lens which has a field reception angle of �12 deg.
This describes a system to demonstrate the feasibility of a novel traffic axle detection technology using non-contact sensors. This system, called LAD, was shown to be feasible, in that the axle counting is 95 percent accurate for a wide range of modeled, four lane traffic conditions. Further, this technology was demonstrated in a 1/18 scale, two lane traffic demonstrator.
The advantages of this technology is the systems high accuracy for conditions from free-flowing traffic to stop-and-go conditions. Vehicle velocity, acceleration, gap, headway and lane flow measurement were demonstrated to be feasible through computer modeling, as well as techniques that will allow for lane displacement measurement. The LAD also has the advantage of allowing installation, maintenance, and removal without requiring access to (or modification of) the roadway. Thus the LAD represents a significant advantage in safety, lower operation costs, and improved traffic flow (traffic does not have to be stopped for LAD system access). Since the LAD mounts to the roadway shoulder, there are no engineering and installation support structures required. The LAD is, therefore, a potentially capable replacement for tape switches, air switches and treadles.
This application references axle detection in accordance with accepted terminology in the traffic monitoring field. In actuality, as discussed above, radiation beam interruption is by passage of vehicle wheels with one axle per wheel pair. The detection of two wheels as illustrated in FIG. 4 denotes the passage of a car or truck and motorcycle as well. A tractor-trailer passage is denoted by single axle wheel passage for the front of the tractor, typically dual wheels and axles for the rear of the tractor and dual wheels and axles for a single trailer. Any combination of these denotes the passage of a single classifiable vehicle.
In the foregoing description of this invention and the drawings, the radiation sources are shown for ease of understanding located at one side of the roadway and the radiation detectors at the opposite side. It is recognized that for convenience of installation and maintenance that it is possible to place radiation source and detector side by side on one side of the roadway and a retro-reflector device on the opposite side with the beam, when uninterrupted, traversing the roadway and bring reflection back to the detectors. In operation, the system is identical with the single passage version disclosed in the drawings. Such a retro-reflective system is considered as a part of this invention.
The above described embodiments of the present invention are merely descriptive of its principles and are not to be considered limiting. The scope of the present invention instead shall be determined from the scope of the following claims including their equivalents.
1. Greenshields, B., "A Study of Traffic Capacity" in Proc. Highway Research, 14, Transportation Research Board, Washington D.C., 1034.
2. Haberman, R., Mathematical Models: Mechanical Vibrations, Popular Dynamics and Traffic Flow, Prentice-Hall, Inc., Englewood Cliffs, N.J., 1977.
3. U.S. Department of Transportation, The 1985 Highway Capacity Manual, Office of Traffic Operations, Federal Highway Administration, Washington, D.C., 1985.
APPENDIX B__________________________________________________________________________/****************************************************************************//* CNTR.C DERON LINSACUM 06/13/95 => *//****************************************************************************//* INCLUDE FILES#include <stdio.h>#include <stdlib.h>#include <string.h>#Include <stdlib.h>#include <time.h>#include <math.h>#include <mailoc.h>#include <dos.h>#include <conio.h>#include <graph.h>#include <bios.h>#define P8259A 0�21#define CTM05 0�300#define CTM05-- CMD (CTM05 + 0�01)#define DIGITAL-- IN (CTM05 + 0�02)#define DIGITAL-- OUT (CTM05 + 0�03)#define KEY-- a 97#define KEY-- A 65#define KEY-- b 98#define KEY-- B 66#define KEY-- c 99#define KEY-- C 67#define KEY-- f 102#define KEY-- F 70#define KEY-- h 104#define KEY-- H 72#define KEY-- i 105#define KEY-- I 73#define KEY-- m 109#define KEY-- M 77#define KEY-- n 110#define KEY-- N 78#define KEY-- o 111#define KEY-- O 79#define KEY-- r 114#define KEY-- R 82#define KEY-- s 115#define KEY-- S 83#define KEY-- t 116#define KEY-- T 84#define KEY-- v 118#define KEY-- V 86#define KEY-- x 120#define KEY-- X 88#define KEY-- ESC 27#define KEY-- y 121#define KEY-- Y 89/*---------------------------------------------------------------------------------------------------------------*//* STACK AND POINTER CHECKING OFF *//*---------------------------------------------------------------------------------------------------------------*/#pragma check-- stack( off )#pragma check-- pointer( off )#pragma intrinsic( -- enable, -- disable )/****************************************************************************//* EXTERNAL FUNCTIONS/VARIABLES .sup. *//****************************************************************************//*---------------------------------------------------------------------------------------------------------------*//* PROTOTYPES FOR INTERRUPT FUNCTIONS *//*---------------------------------------------------------------------------------------------------------------*/void ( -- cdecl -- interrupt -- far *oldroutine1)( );void -- cdecl -- interrupt -- far newroutine( void );/****************************************************************************//* LOCAL FUNCTIONS/VARIABLES */int init-- ctm05(void);int alloc-- data(void);int display-- data(void);void init-- isr(void);void dis-- isr(void);int clear-- data(void);int process-- data(void);int check-- keys(void);int process(void);unsigned int int-- enable-- mask;unsigned int int-- disable-- mask;unsigned int int-- number;unsigned int counter-- value;long int num-- points;unsigned int low-- byte;unsigned int high-- byte;unsigned int status;unsigned long int final-- cntr-- val;unsigned long int cntr2-- val;unsigned Long int cntr2-- val;int ret-- val;long int det1-- points;long int det2-- points;long int det3-- points;long int det4-- points;int exit-- program;typedef struct { unsigned long int cntr-- val; unsigned int status; }DATA;struct det-- status /* this allows accessing individual groupsof 2 b => its each using */ { /* a single integer value */ unsigned int det1:2; unsigned int det2:2; unsigned int det3:2; unsigned int det4:2; };union stat-- union /* union of status bits with a single integer*/ { /* this allows updating of all bits with a single integer */ unsigned int all; struct det-- status bits; } stat;/* to access a 2 bit group use this notation: *//* variable = stat.bits.det1 *//* define pointers for structured arrays *//* one for the actual array and another for just a pointer to incrementthrough => the array *//* without destroying the original pointer position */DATA -- huge *det1;DATA -- huge *det1-- ptr;DATA -- huge *det2;DATA -- huge *det2-- ptr;DATA -- huge *det3;DATA -- huge *det3-- ptr;DATA -- huge *det4;DATA -- huge *det4-- ptr;void main( )exit-- program = 1;ret-- val = 0;num-- points = 10000L;det1-- points = 0L; /* reset variables that contain the currentnumber of data p => oints taken */det2-- points = 0L;det3-- points = 0L;det4-- points = 0L;init ctm05( );ret-- val = alloc-- data( );if(ret-- val) exit(0);system("cls"); /* clear screen */-- settextposition(6,20);-- outtext("HIT -- S -- KEY TO START DATA COLLECTION");-- settextposition(7,20);-- outtext("HIT -- ESC -- KEY TO EXIT PROGRAM");while(exit-- program) { check-- keys( ); /* now check if data array are full, if they are then process data */ if( (det1-- points >= num-- points) ||(det1-- points >= num-- points) || (det1-- points >= num-- points) ||(det1-- points >= num-- points) ) process( ); }exit(0);}/****************************************************************************/int init-- ctm05( ){/* initialize ctm05 counter */outp(CTM05-- CMD, 0�17); /* select master mode register whichis 16 bits *//* now set master mode register to 0xcad0 *//* BIT 15 BCD SCALER *//* BIT 14 DISABLE AUTO INCREMENT *//* BIT 13 8 BIT DATA TRANSFER *//* BIT 12 ENABLE FOUT SIGNAL *//* BITS 11-8 SET CLOCK DIVIDERS TO DIVIDE BY TEN *//* BITS 7-4 SET INPUT SOURCE FOR FOUT TO F3(10KHZ) *//* BIT 3 DISABLE COMPARATOR 2 OUTPUT *//* BIT 2 DISABLE COMPARATOR 1 OUTPUT *//* BITS 1-0 DISABLE TIME OF DAY MODE */outp(CTM05, 0xd0); /* low byte */outp(CTM05, 0xca); /* high byte *//* now set individual counter modes *//* counters will operate in mode D (rate generator with no hardwaregating) *//* counters 1 and 2 will be concatenated together to provide a 32 bitcounter *//* counter 1 will be the low order bits(0-15) and counter 2 will be thehigh bit => s(16-31) *//* the counter will be set for a 10us resolution(100kHz) *//* this will allow the counter to run without resetting for about 11.9hours *//* the counters will count up from 00000000H to ffffffffH and then repeat*//* any negative numbered time duration caused by the reset can becorrected by s => ubtracting the *//* start count value from the maximum counter count(FFFFFFFFH) and addingthe fi => nish count value to it. *//* this assumes that the duration is less than 11.9 hours */outp(CTM05-- CMD, 0�01); /* select 16 bit mode register forcounter 1 *//* BITS 15-13 INPUT GATE DISABLED TO COUNTER *//* BIT 12 COUNT ON RISING EDGE OF SOURCE INPUT *//* BITS 11-8 SOURCE SELECTION FROM F2 (100KHZ) *//* BIT 7 DISABLE SPECIAL GATE *//* BIT 6 RELOAD FROM LOAD *//* BIT 5 COUNT REPETITIVELY *//* BIT 4 COUNT IN BINARY *//* BIT 3 COUNT UP *//* BITS 2-0 OUTPUT CONTROL INACTIVE SET TO HIGH */outp(CTM05, 0�2c); /* low byte */outp(CTM05, 0�0c); /* high byte */outp(CTM05-- CMD, 0�02); /* select 16 bit mode register forcounter 2 *//* BITS 15-13 INPUT GATE DISABLED TO COUNTER 10 *//* BIT 12 COUNT ON RISING EDGE OF SOURCE INPUT *//* BITS 11-8 SOURCE SELECTION FROM TERMINAL COUNT OF COUNTER 1 *//* BIT 7 DISABLE SPECIAL GATE *//* BIT 6 RELOAD FROM LOAD *//* BIT 5 COUNT REPETITIVELY *//* BIT 4 COUNT IN BINARY *//* BIT 3 COUNT UP *//* BITS 2-0 OUTPUT CONTROL INACTIVE SET TO HIGH */outp(CTM05, 0�2c); /* low byte */outp(CTM05, 0�00); /* high byte */outp(CTM05-- CMD, 0�03); /* select 16 bit mode register forcounter 3 *//* BITS 15-13 INPUT GATE DISABLED TO COUNTER *//* BIT 12 COUNT ON RISING EDGE OF SOURCE INPUT *//* BITS 11-8 SOURCE SELECTION FROM F5 (100HZ) *//* BIT 7 DISABLE SPECIAL GATE *//* BIT 6 RELOAD FROM LOAD *//* BIT 5 COUNT REPETITIVELY *//* BIT 4 COUNT IN BINARY *//* BIT 3 COUNT UP *//* BITS 2-0 OUTPUT CONTROL INACTIVE SET TO HIGH */outp(CTM05, 0�2c); /* low byte */outp(CTM05, 0�0f); /* high byte */outp(CTM05-- CMD, 0�04); /* select 16 bit mode register forcounter 4 *//* BITS 15-13 INPUT GATE DISABLED TO COUNTER *//* BIT 12 COUNT ON RISING EDGE OF SOURCE INPUT *//* BITS 11-8 SOURCE SELECTION FROM F5 (100HZ) *//* BIT 7 DISABLE SPECIAL GATE *//* BIT 6 RELOAD FROM LOAD *//* BIT 5 COUNT REPETITIVELY *//* BIT 4 COUNT IN BINARY *//* BIT 3 COUNT UP *//* BITS 2-0 OUTPUT CONTROL INACTIVE SET TO HIGH */outp(CTM05, 0�2c); /* low byte */outp(CTM05, 0�0f); /* high byte */outp(CTM05-- CMD, 0�05); /* select 16 bit mode register forcounter 5 *//* BITS 15-13 INPUT GATE DISABLED TO COUNTER *//* BIT 12 COUNT ON RISING EDGE OF SOURCE INPUT *//* BITS 11-8 SOURCE SELECTION FROM F5 (100HZ) *//* BIT 7 DISABLE SPECIAL GATE *//* BIT 6 RELOAD FROM LOAD *//* BIT 5 COUNT REPETITIVELY *//* BIT 4 COUNT IN BINARY *//* BIT 3 COUNT UP 10 *//* BITS 2-0 OUTPUT CONTROL INACTIVE SET TO HIGH */outp(CTM05, 0�2c); /* low byte */outp(CTM05, 0�0f); /* high byte *//* now load a value of 0 into the load registers of counters 1 and 2 *//* don't load any values to other counter load registers */outp(CTM05-- CMD, 0�09); /* select 16 bit load register forcounter 1 */outp(CTM05, 0�00); /* low byte */outp(CTM05, 0�00); /* high byte */outp(CTM05-- CMD, 0�0a); /* select 16 bit load register forcounter 2 */outp(CTM05, 0�00); /* low byte */outp(CTM05, 0�00); /* high byte *//* now send command to transfer the load register contents for counters 1and 2 => */outp(CTM05-- CMD, 0�43);outp(CTM05-- CMD, 0�23); /* arm counting for counters 1 and 2only */outp(DIGITAL-- OUT, 0�00); /* reset all detector interruptflip-flops *//* make all flip-flops active */outp(DIGITAL-- OUT, 0�ff); /* return presets to flip-flops totheir normal high => state *//* for the ones that requested an interrupt */return(0);}/****************************************************************************/int alloc-- data( )}int ret-- err;ret-- err = 0;/* allocate memory space and set up detector data arrays */if((det1 = (DATA-- huge*) halloc(num-- points, sizeof(DATA)))== NULL) { -- settextposition(23,1); printf("\n Not enough memory for det1 array. \n"); ret-- err = 1; }if((det2 = (DATA-- huge*) halloc(num-- points, sizeof(DATA)))== NULL) { -- settextposition(23,1); printf("\n Not enough memory for det2 array. \n"); ret-- err = 1; }if((det3 = (DATA-- huge*) halloc(num-- points, sizeof(DATA)))== NULL) { -- settextposition(23,1); printf("\n Not enough memory for det3 array. \n"); ret-- err = 1; }if((det4 = (DATA-- huge*) halloc(num-- points, sizeof(DATA)))== NULL) { -- settextposition(23,1); printf("\n Not enough memory for det4 array. \n"); ret-- err = 1; }/* assign data pointer to beginning of data array */det1-- ptr = det1;det2-- ptr = det2;det3-- ptr = det3;det4-- ptr = det4;return(ret-- err);}/****************************************************************************/int display-- data( ){int jump-- out;long int i;jump out = 1;i = 0L;system("cls"); /* clear screen */det1-- ptr = det1; /* reinitialize pointer value */det2-- ptr = det2;det3-- ptr = det3;det4-- ptr = det4;while(jump-- out) { printf(" %lX %lX %lX %lX\n", det1-- ptr->cntr-- val,det2-- ptr->cntr-- val, det3-- ptr->cntr-- val, det4-- ptr->cntr--val); printf(" %x %x %x %x\n", det1-- ptr->status, det2--ptr->stat => us, det3-- ptr->status, det4-- ptr->status); det1-- ptr++ ; det2-- ptr++ ; det3-- ptr++ ; det4-- ptr++ ; if ( (det1--ptr->cntr -- val = = 0L) && (det2-- ptr->cntr.sub.-- val = = 0L) && (det3-- ptr->cntr-- val = = 0L) && (det4-- ptr->cntr.sub.-- val = = 0L)) jump-- out = 0; i++ ; if(i >= num-- points) jump-- out = 0; }det1-- ptr = det1; /* reinitialize pointer value */det2-- ptr = det2;det3-- ptr = det3;det4-- ptr = det4;-- settextposition(21,20);-- outtext("HIT ANY KEY TO CONTINUE");getch( );return(0);}/****************************************************************************/void init-- isr( ){unsigned int intmask;/*---------------------------------------------------------------------------------------------------------------*//* SETUP INTERRUPT SERVICE ROUTINE (ISR) *//*---------------------------------------------------------------------------------------------------------------*//* set up masks for 8259A PIC. To enable the interrupt *//* this mask is ANDed with the mask register at 21h. To disable, *//* OR the disable mask with the mask register. The interrupt *//* number is 8 + the IRQ level of the interrupt. (due to the 8 NMI) *//* parallel port 2's IRQ 5 TYPE 13 is used for this interrupt *//* note: -- disable and -- enable is used to prevent interruptsoccuring while insta => lling new vector *//* otherwise computer may get a wrong interrupt vector address and hangup *//* MASK REGISTER *//* IRQ 7 6 5 4 3 2 1 0 *//* bit 7 6 5 4 3 2 1 0 *//* 1 1 0 1 1 1 1 1 ENABLE MASK VALUE & PORT(0�21) *//* 0 0 1 0 0 0 0 0 DISABLE MASK | PORT(0�21) *//*int-- enable-- mask = 0�f7;int-- disable-- mask = 0�08;int-- number = 11;*/int-- enable-- mask = 0�DF;int-- disable-- mask = 0�20;int-- number = 13;oldroutine1 = -- dos-- getvect(int-- number);-- disable( );-- dos-- setvect(int-- number, newroutine);-- enable( );/* now read 8259A's interrupt mask register and write it back afterAND-ing it w => ith int-- enable-- mask *//* this will enable IRQ5 */-- disable( );intmask = (inp(P8259A) & int-- enable-- mask);outp(P8259A, intmask);-- enable( );}void dis-- isr( ){unsigned int intmask;-- disable( );intmask = (inp(P8259A) | int-- disable-- mask):outp(P8259A, intmask);-- dos-- setvect(int-- number, oldroutine1);-- enable( );}/*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*//* *//* INTERRUPT SERVICE ROUTINE ==> void-- interrupt-- farnewroutine( ) *//* *//* Routine Functions: *//* *//* 1. Reset flip-flop on timer counter circuit. *//* 2. Send byte info through P48 I/O board to drive scanner*//* motors. *//* *//*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/void -- cdect -- interrupt -- far newroutine( ){/* latch counter 1 and 2 counter values into hold register */outp(*CTM05-- CMD, 0�a3);/* only one interrupt will be used for all flip-flops *//* when a detector is blocked, the flip-flop will pull the interrupt linelow *//* now read in data byte for detector status *//* BIT 7 6 5 4 3 2 1 0 *//* DET 4F 4S 3F 3S 2F 2S 1F 1S *//* *//* WHERE F = FINISH FLIP-FLOP S = START FLIP-FLOP *//* if bit is equal to 0, then that detector's start or finish time willbe recor => ded *//* that flip-flop will then be reset individually *//*now retreive counter 1 and 2 count values */outp(CTM05-- CMD, 0�11); /* select hold register for counter1 */low byte = inp(CTM05); /* read in counter 1 low byte */high-- byte = inp(CTM05); /* read in counter 1 high byte */counter-- value = ((high byte >> 8) | low-- byte);cntr1-- val = (unsigned long int)counter-- value;outp(CTM05-- CMD, 0�12); /* select hold register for counter2 */low-- byte = inp(CTM05); /* read in counter 2 low byte */high-- byte = inp(CTM05); /* read in counter 2 high byte */counter-- value = ((high byte << 8) | low-- byte);cntr2-- val = (unsigned long int)counter-- value;final-- cntr-- val = ((cntr2-- val << 16) |cntr1-- val);stat.all = inp(DIGITAL-- IN);/* now reset flip-flops that were turned on */outp(DlGITAL-- OUT, 0�00); /* RESET All FLIP FLOPS thiseliminates zero v => alues for data *//*outp(DIGITAL-- OUT, stat.all);*/outp(DIGITAL-- OUT, 0�ff); /* return presets to flip-flopsto their normal high => state */ /* for the ones that requested an interrupt *//* now route counter and status values to detector memory arrays */if(stat.bits.det1 < 3) /* check if need to record cntr value for thisdetec => tor */ { det1-- ptr->cntr val = final-- cntr.val; /* values are a 32bit number */ det1-- ptr->status = stat.bits.det1; /* values can be 0, 1, 2 */ /* 0 -- start and finish of detector blockage occurred */ /* at same time(unable to measure duration) */ /* 1 -- finish of detector blockage */ /* 2 -- start of detector blockage */ det1-- points++ ; /* increment current data points counter */ det1-- ptr++ ; /* increment pointer for detector 1 data array*/ }if(stat.bits.det2 < 3) /* check if need to record cntr value for thisdetec => tor */ { det2-- ptr->cntr-- val = final cntr-- val; det2-- ptr->status = stat.bits.det2; det2-- points++ ; /* increment current data points counter */ det2-- ptr++ ; /* increment pointer for detector 1 data array*/ }if(stat.bits.det3 < 3) /* check if need to record cntr value for thisdetec => tor */ { det3-- ptr->cntr val = final-- cntr-- val; det3-- ptr->status = stat.bits.det3; det3-- points++ ; /* increment current data points counter */ det3-- ptr++ ; /* increment pointer for detector 1 data array*/ }if(stat.bits.det4 < 3) /* check if need to record cntr value for thisdetec => tor */ { det4-- ptr->cntr-- val = final-- cntr-- val; det4-- ptr->status = stat.bits.det4; det4-- points++ ; /* increment current data points counter*/ det4-- ptr++ ; /* increment pointer for detector 1 data array*/ }outp(0�20, 0�20);}/****************************************************************************/int clear-- data( ){long int ii;det1-- ptr = det1; /* reinitialize pointer value */det2-- ptr = det2;det3-- ptr = det3;det4-- ptr = det4;for(ii = 0; ii<num-- points; ii++) { det1-- ptr->cntr-- val = 0L; det1-- ptr->status = 0; det2-- ptr->cntr-- val = 0L; det2-- ptr->status = 0; det3-- ptr->cntr-- val = 0L; det3-- ptr->status = 0; det4-- ptr->cntr-- val = 0L; det4-- ptr->status = 0; det1-- ptr++ ; det2-- ptr++ ; det3-- ptr++ ; det4-- ptr++ ; }det1-- ptr = det1; /* reinitialize pointer value */det2-- ptr = det2;det3-- ptr = det3;det4-- ptr = det4;det1-- points = 0L; /* reset variables that contain the currentnumber of data p => points taken */det2-- points = 0L;det3-- points = 0L;det4-- points = 0L;return(0);}/****************************************************************************/* TAG( )** Description:** Returns:* . . .* Inputs:** Outputs:* . . .* Considerations:* . . .* Assumptions:* . . .* Related Routines:* . . .****************************************************************************/int check-- keys(){unsigned int ascii-- val;/unsigned int scan-- code;unsigned int keyactive;if(kbhit( )) {ascii-- val = getch( ); /* get ascii value *,keyactive = ascii-- val;if(ascii-- val = = 0) { scan-- code = getch( ); /* get scan code */ }/*printf(" keyactive = %d, scan-- code = %d ", keyactive,scan-- code);*/switch(keyactive) { /*= = = = = = = = = = = = = = = = = = = = = = = = f,F - PROCESS DATA AND DISPLAY IT /*= = = = = = = = = = = = = = = = = = = = = = =*/ case KEY-- f: case KEY-- F: process( ); break; /*= = = = = = = = = = = = = = = = = = = = = = = = s,S - start data collection /*= = = = = = = = = = = = = = = = = = = = = = =*/ case KEY-- s: case KEY-- S: system("cis"); /* clear screen */ outp(DIGITAL-- OUT, 0�00); /* reset all detector interruptflip-flops *=> / -- settextposition(6,20); -- outtext("DATA ARRAYS CLEARED"); clear-- data( ); /* clear data arrays */ -- settextposition(7,20); -- outtext("DETECTOR INTERRUPTS CLEARED"); outp(DIGITAL-- OUT, 0�ff); /* return presets to flip-flopsto their norma=>l high state */ -- settextposition(8,20); -- outtext("DATA-CAPTURE ENABLED"); -- settextposition(9,20); -- outtext("HIT -- F --- KEY TO PROCESS DATA"); init-- isr( ); break; /*= = = = = = = = = = = = = = = = = = = = = = == esc - exit program /*= = = = = = = = = = = = = = = = = = = = = =*/ case KEY-- ESC: system("cls"); /* clear screen */ dis-- isr( ); /* disengage interrupt service routine */ /* unallocate memory space */ hfree(det1); hfree(det2); hfree(det3); hfree(det4); exit-- program = 0; break; default: break; } fflush(stdin); /* FLUSH KEYBOARD BUFFER */ }return(0);}/***************************************************************************** TAG( )** Description:** Returns:* . . .* Inputs:** Outputs:* . . .* Considerations:* . . .* Assumptions:* . . .* Related Routines:* . . .****************************************************************************/int process-- data( ){/* process data here *//* for now just displaying data arrays */display-- data( );return(0);}/****************************************************************************/int process( ){system("cis"); /* clear screen */-- settextposition(6,20);-- outtext("DATA-CAPTURE DISABLED");dis-- isr( ); /* disable interrupt routine */-- settextposition(7,20);-- outtext("PROCESSING DATA");process-- data( );system("cls"); /* clear screen */-- settextposition(6,20);-- outtext("HIT -- S -- TO START DATA COLLECTION");-- settextposition(7,20);-- outtext("HIT -- ESC KEY -- TO EXIT PROGRAM");return(0);}__________________________________________________________________________
|Cited Patent
|Filing date
|Publication date
|Jan 13, 1943
|Dec 26, 1944
|Edward Lauterbach George
|System and apparatus for detecting high and wide railroad cars and open top lading
|Jul 13, 1973
|Mar 18, 1975
|Cadre Corp
|Vehicle identification method and apparatus
|Jun 29, 1995
|Jun 3, 1997
|Quantronix, Inc.
|In-motion dimensioning system for cuboidal objects
|Greenshields, Bruce D., A Study of Highway Capacity, Hiighway Research Board, Dec. 6 7,1934, pp. 448 477.
|Greenshields, Bruce D., A Study of Highway Capacity, Hiighway Research Board, Dec. 6-7,1934, pp. 448-477.
|Haberman, Richard, Mathematical Models, Prentice Hall, Inc. (1977) pp. 259 298.
|Haberman, Richard, Mathematical Models, Prentice-Hall, Inc. (1977) pp. 259-298.
|Lu, Jian., Traffic Data Logical Detection by Infrared Sensor Array., ITE 1993 Compendium of Technical Papers, 493 497.
|Lu, Jian., Traffic Data Logical Detection by Infrared Sensor Array., ITE 1993 Compendium of Technical Papers, 493-497.
|U.S. Department of Transporation, Federal Highway Administration, The 1985 Highway Capacity Manual, Apr. 1986.
|Citing Patent
|Filing date
|Publication date
|May 31, 2000
|Dec 3, 2002
|Keihin Corporation
|Car controlling unit using a multitasking system
|Feb 26, 2004
|Sep 12, 2006
|Spectra Research, Inc.
|Non-intrusive traffic monitoring system
|Jan 8, 2004
|Sep 16, 2008
|Wavetronix, Llc
|Systems and methods for monitoring speed
|Dec 23, 2003
|Sep 23, 2008
|Wavetronix Llc
|Vehicular traffic sensor
|Jun 4, 2002
|Apr 21, 2009
|Ceos Industrial Pty Ltd
|Monitoring process and system
|Dec 19, 2002
|Feb 1, 2011
|Logobject Ag
|Method and device for following objects, particularly for traffic monitoring
|Jul 14, 2009
|Aug 21, 2012
|Detecting targets in roadway intersections
|Oct 1, 2010
|Jul 23, 2013
|Kapsch Trafficcom Ag
|Device and method for detecting wheel axles
|Oct 1, 2010
|Jul 30, 2013
|Kapsch Trafficcom Ag
|Device and method for determining the direction, speed and/or distance of vehicles
|Jul 15, 2011
|Jan 28, 2014
|George C Dedes
|GPS/IMU/video/radar absolute/relative positioning communication/computation sensor platform for automotive safety applications
|Feb 23, 2010
|Mar 4, 2014
|Wavetronix Llc
|Detecting roadway targets across beams including filtering computed positions
|Jul 15, 2011
|Apr 1, 2014
|International Paper Company
|System to determine if vehicle correctly positioned during weighting, scale ticket data system and methods for using same
|May 17, 2012
|Aug 19, 2014
|MindTree Limited
|Circular object identification system
|Jun 5, 2012
|Nov 11, 2014
|Kapsch Trafficcom Ag
|Method and apparatus for detecting vehicle wheels
|Apr 17, 2014
|Sep 15, 2015
|Conti Temic Microelectronic Gmbh
|Method and device for estimating the number of lanes and/or the lane width on a roadway
|Mar 27, 2014
|Dec 8, 2015
|Xerox Corporation
|Vehicle wheel and axle sensing method and system
|Jan 24, 2014
|Jan 19, 2016
|Wavetronix Llc
|Detecting roadway targets across beams
|Jan 30, 2013
|Aug 9, 2016
|Wavetronix Llc
|Traffic flow through an intersection by reducing platoon interference
|Feb 28, 2014
|Sep 27, 2016
|International Paper Company
|System to determine if vehicle correctly positioned during weighing, scale ticket data system and methods for using same
|Jun 19, 2012
|Nov 29, 2016
|Kapsch Trafficcom Ag
|Method and device for detecting a rotating wheel
|Dec 8, 2015
|Mar 21, 2017
|Wavetronic Llc
|Detecting roadway targets across radar beams by creating a filtered comprehensive image
|Dec 23, 2003
|Jul 15, 2004
|Arnold David V.
|Vehicular traffic sensor
|Jun 4, 2002
|Aug 5, 2004
|Adam Matthew Dickson
|Monitoring process and system
|Jan 8, 2004
|Sep 9, 2004
|Systems and methods for monitoring speed
|Feb 26, 2004
|Dec 9, 2004
|Capozzi Jerry V.
|Non-intrusive traffic monitoring system
|Dec 19, 2002
|Mar 31, 2005
|Roberto Brega
|Method and device for tracking objects, especially for monitoring traffic
|Jun 21, 2004
|Apr 26, 2007
|Qinetiq Limited
|Image processing system
|Jul 14, 2009
|Jun 10, 2010
|Arnold David V
|Detecting targets in roadway intersections
|Feb 23, 2010
|Jun 17, 2010
|Arnold David V
|Detecting roadway targets across beams
|Oct 1, 2010
|Apr 7, 2011
|Alexander Leopold
|Device and method for determining the direction, speed and/or distance of vehicles
|Oct 1, 2010
|Apr 7, 2011
|Oliver Nagy
|Device and Method for Detecting Wheel Axles
|Jul 15, 2011
|Nov 15, 2012
|Dedes George C
|GPS/IMU/Video/Radar absolute/relative positioning communication/computation sensor platform for automotive safety applications
|Jun 5, 2012
|Dec 27, 2012
|Kapsch Trafficcom Ag
|Method and Apparatus for Detecting Vehicle Wheels
|Jun 19, 2012
|Aug 7, 2014
|Kapsch Trafficcom Ag
|Method and Device for Detecting a Rotating Wheel
|Apr 17, 2014
|Oct 30, 2014
|Conti Temic Microelectronic Gmbh
|Method and Device for Estimating the Number of Lanes and/or the Lane Width on a Roadway
|Sep 22, 2000
|Jul 1, 2014
|Envirotest Systems Holdings Corp.
|Speed and acceleration monitoring device using visible laser beams
|May 26, 2011
|Mar 28, 2012
|Presence Detection System and Method
|Sep 17, 2004
|Apr 6, 2006
|Vehico Gmbh
|Driving dynamics device for yielding measured values to determine driving dynamics capacities for motor vehicles has devices to scan a marker signal and to evaluate scanned values captured
|May 19, 2004
|Nov 24, 2004
|JOANNEUM RESEARCH Forschungsgesellschaft mbH
|Contactless axle counter for road traffic
|May 19, 2004
|Jan 18, 2006
|JOANNEUM RESEARCH Forschungsgesellschaft mbH
|Contactless axle counter for road traffic
|Oct 1, 2009
|Apr 6, 2011
|Kapsch TrafficCom AG
|Device and method for detecting wheel axles
|Jul 19, 2011
|Jan 23, 2013
|Fraunhofer-Gesellschaft zur F�rderung der angewandten Forschung e.V.
|Calculator, system, method and computer program for obtaining one or more motion parameters of a target
|Sep 11, 2002
|Mar 20, 2003
|Pips Technology Limited
|Dtermining occupancy of a region monitored by a video apparatus
|Sep 11, 2002
|Apr 29, 2004
|Pips Technology Ltd
|Dtermining occupancy of a region monitored by a video apparatus
|Jun 21, 2004
|Dec 29, 2004
|Qinetiq Limited
|Image processing system
|Aug 12, 2004
|Feb 24, 2005
|Petrus Paulus Haasbroek
|Classification of vehicles
|May 30, 2008
|Dec 11, 2008
|Autopistas Concesionaria Espa�ola S.A.
|Method for detecting the presence of moving objects
|U.S. Classification
|340/942, 340/933, 340/935, 340/936
|International Classification
|Cooperative Classification
|European Classification
|Aug 5, 1996
Owner name: PACIFIC SIERRA RESEARCH CORP., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LIEPMANN, TILL W.;REEL/FRAME:008147/0665
Effective date: 19960802
|Oct 9, 1998
Owner name: NBD BANK, N.A., INDIANA
Free format text: SECURITY AGREEMENT;ASSIGNOR:PACIFIC-SIERRA RESEARCH CORPORATION;REEL/FRAME:009516/0764
Effective date: 19980930
|Dec 6, 1999
Owner name: FIRST UNION NATIONAL BANK, NORTH CAROLINA
Free format text: GUARANTOR SECURITY AGREEMENT;ASSIGNOR:PACIFIC-SIERRA RESEARCH CORPORATION;REEL/FRAME:010437/0231
Effective date: 19990903
|Apr 12, 2002
|Fee payment
Year of fee payment: 4
|Apr 30, 2002
|Maintenance fee reminder mailed
|Jun 20, 2002
Owner name: WACHOVIA BANK, NATIONAL, NORTH CAROLINA
Free format text: ASSIGNMENT OF SECURITY INTEREST;ASSIGNOR:VERIDIAN SYSTEMS DIVISION, INC.;REEL/FRAME:012991/0435
Effective date: 20020610
|Aug 21, 2003
Owner name: VERIDIAN SYSTEMS DIVISION, INC., VIRGINIA
Free format text: SATISFACTION OF COLLATERAL AGREEMENT/TERMINATION OF SECURITY INTEREST;ASSIGNOR:WACHOVIA BANK, NATIONAL ASSOCIATION;REEL/FRAME:014420/0009
Effective date: 20030811
|Dec 22, 2005
Owner name: PACIFIC-SIERRA RESEARCH CORPORATION, CALIFORNIA
Free format text: NOTICE OF SATISFACTION OF SECURITY AGREEMENTS;ASSIGNOR:WACHOVIA BANK, NATIONAL ASSOCIATION;REEL/FRAME:017136/0746
Effective date: 20051019
|May 3, 2006
|Maintenance fee reminder mailed
|Oct 13, 2006
|Lapse for failure to pay maintenance fees
|Dec 12, 2006
|Expired due to failure to pay maintenance fee
Effective date: 20061013


text:
There are many ways to get involved and the children in our area need your help! We partner with the NJ Division of Child Protection and Permanency (formerly the Division of Youth and Family Services, DYFS), to help families receive the training they will need to becoming resource (foster) families.
If you have ever considered becoming a foster parent, it has never been easier than now! To sign-up to participate in the training to become licensed email Sandy Duck at email@example.com. For more information, email our team at email@example.com.
Families who are not able to provide temporary care and permanent families can take action for NJ's children by preserving their families! Consider how you might reach out to a family in need, donate food and clothing to My Neighbor's Ministries, intercede and offer prayer and support to single-parent families and families in crisis!
*To become licensed, couples will take 27 hours of training.

subset: commoncrawl


text:
|Separate WC's
|Property type
|Minimum Stay
|3 nights
Lake Clay Vacation Home From the moment you pull into the driveway, you will instantly feel like you are on vacation. When you step inside, the wooden floors and cedar ceilings may be reminiscent of a log cabin, yet with the amenities of the more modern world, cable television and wireless internet. You will quickly realize that you have landed on the perfect playground for children and adults alike, particularly if you are a water enthusiast. Bring your jet skis, boat, and fishing gear and prepare for a day on or near the water. Your family and friends can enjoy tubing, wake boarding, water skiing, fishing, swimming and relaxing. I know that our family and friends sure do! Lake Clay boasts a sandy bottom and this home is designed to impress. A two story, four bedroom, two and a half bathroom comfortably sleeps 12. The King Size Master has breathtaking sunset views and a jacuzzi in the master bathroom. The downstairs rooms include a Queen Size bed, two bunk beds, and two single beds. Each floor has its own family room/den. -
This property was chosen because of the relaxing and beautiful lake views that can be seen from many of the rooms in this house. This a house for the sports lover where boating, tubing, fishing and swimming is fun at anytime of the year.
Imagine gorgeous sunset views at the end of a fun filled day on the water. There is a sandy beach area where the kids can play at anytime. There is a large upstairs screened in porch where you enjoy a game or sip a glass of wine or relax in the downstairs porch area. There is also two spacious living rooms where adults can enjoy a movie while the kids can enjoy their own space. If you want to continue enjoying the views this home is equipped with a barbecue set.
The property was amazing and a perfect place to make memories.
For our extended family of 9, this house was a perfect fit. We had enough space to have great family time, but if you needed a little "alone time," there was room for that too. The outside porches were wonderfully inviting with covered seating and dining areas. The kids had a blast fishing off the dock, and caught enough fish to make it exciting. All in all, it's everything you could ask for in a lakeside vacation.
Enjoyed setting and home full of amenities
Our family had a great time in this house. The house is well stocked with all needed supplies. Perfect location with a western exposure on the lake shore. The kids had lots of fun on the beach and fishing for bass from the dock. There is a 2 person kayak in the house which was a hit too. We stayed for 4 nights and mostly relaxed by the lake, except for a day trip to Legoland.
Definitely recommend this place.
My family from multiple states met up at Bear Cottage on Lake Clay to visit our parents wintering in the area. It comfortably housed our 7 adults and 3 kids for 4 nights. Having it fully furnished (like home) made it very comfortable; all we needed to add was our own food and fun. The owners were very responsive to questions we had. We will definitely stay here if visiting this area again.
My family rented this home for the weekend and found it to be a lovely, well-furnished home with every possible amenity. The kitchen is very well supplied with every kind of kitchen utensil, cooking pots and pans, and appliance that anyone would want in their own home, and has plenty of dishes, plates, glasses, etc. for a large family. The only unusual thing about this house is that the kitchen is located upstairs, necessitating carrying all your groceries upstairs. But once everything is there, the kitchen is great for preparing meals. The upstairs also has sliding glass doors that open onto a screened porch that has a gas grill for cooking, and a table and chairs for dining or just sitting and enjoying a bug-free evening. The view of the lake from upstairs is gorgeous. It faces west so you can watch the sunset over the lake. There is a dining area and a living room area upstairs, a half-bath, and the master suite. It has a large walk-in closet, and a huge, beautiful bathroom with a whirlpool tub and a separate large shower.
Downstairs are three bedrooms, a living room, and a full bathroom. One bedroom has a queen-sized bed, another has a double bed, and the third has two sets of bunk beds. The downstairs porch has a swing and a refrigerator to keep cold beverages in while you are enjoying the beach and dock area. My family spent a lot of time fishing and swimming off the dock. There is a large supply of beach towels, games, and even a blowup air bed if someone needs an extra place to sleep. A washer and dryer are also available. Both the upstairs and downstairs living rooms have flat-screen televisions, DVDs, etc., as does the master suite. At least one downstairs bedroom also has a flat screen television in it.
Everyone in my family was impressed with this house and the beach and dock area. This house was the perfect place for a large group to spend time on the lake. I will definitely have this house on my list of top places to stay the next time I return to Lake Placid.
|Rental Period
|Minimum Price
|Additional Nights
|Weekend Night
|Monthly *
|Event Price
Holiday Season 2017
1 Nov 2017 - 31 Dec 2017
3 night minimum stay
for 3 nights
My Standard Rate
3 night minimum stay
for 3 nights
|Cleaning Fee
|Refundable Damage Deposit
|Tax Rate
There is a cleaning fee of $150.00 that applies for all stays.
******The weekly rate during the 12 hours of Sebring Race is $3,000 a week.*******March 14th - March 21st
* Approximate monthly price. Actual pricing will depend on the days of the month you stay.


text: News June Compact Sales: Chevrolet Cruze Jumps to First Jason Udy writerJuly 2, 2013 Jason Udy writerJuly 2, 2013 Share this article in: Facebook Twitter Google Plus Email Free Price Quote From a Local Dealer View Special Offers No Obligation, Fast & Simple Free New Car Quote Change Car Select Make Acura Alfa Romeo Aston Martin Audi Bentley BMW Buick Cadillac Chevrolet Chrysler Dodge Ferrari FIAT Ford Genesis GMC Honda Hyundai Infiniti Jaguar Jeep Karma Kia Lamborghini Land Rover Lexus Lincoln Lotus Maserati Mazda McLaren Mercedes-Benz MINI Mitsubishi Nissan Porsche Ram Rolls-Royce smart Subaru Tesla Toyota Volkswagen Volvo Select Model GO 1. Vehicle Option Trim Exterior Color No Preference Black Blue Brown Gold Green Orange Red Silver White Yellow Interior Color No Preference Beige Black Blue Gray Green Other Red White Buying Time Frame Within 48 hours Within a week Within two weeks Within a month More than a month Payment Method Undecided Loan Lease Cash Trade In? Yes No 2. Contact Info First Name Last Name Address City State -- AL AK AZ AR CA CO CT DE DC FL GA HI ID IL IN IA KS KY LA ME MD MA MI MN MS MO MT NE NV NH NJ NM NY NC ND OH OK OR PA RI SC SD TN TX UT VT VA WA WV WI WY Zip Code Phone Email 3. Dealer Selection Receive your free dealer pricing information by completing your contact information! Chevrolet Cruze sales took a surprising upswing in June, with the compact bow-tie passing the Honda Civic, Toyota Corolla, Ford Focus, and Hyundai Elantra to take the compact sales lead. For most of 2013, the Cruze has hovered just below a podium finish in fourth or fifth place.Chevrolet sold 32,871 Cruze sedans last month, an increase of 9816 units from May as well as an increase of 73.2 percent from June 2012. Each of May's top four finishers were pushed down one spot each with the Honda Civic finishing in second place with 29,724 units sold, while 26,458 Toyota Corolla/Matrix cars were sold. Ford moved 23,144 Focus sedan and hatchbacks for a fourth place finish with the Hyundai Elantra finishing in fifth place with 22,163 units sold.Read about May compact sales: May Compact Sales: Honda Civic Still on Top, Corolla Takes SecondThe Volkswagen Jetta/Jetta Sportwagen (14,813) and Nissan Sentra (10,199) held onto their sixth- and seventh-place spots, respectively, while the Mazda3 (7566) defended its eighth place finish. Swapping places with the Dodge Dart, the Subaru Impreza/WRX (6907) climbs two spots to ninth place, while the Kia Forte (6620) remains in tenth place.Slipping two spots to ninth place, the Dodge Dart (6437) finishes ahead of the Volkswagen Golf/GTI lineup, which remains in twelfth place with 2602 units sold.While the Cruze may be first in June, the Corolla is still number one for the first half of 2013 with the Civic in a close second place. The Focus is in a distant third with the Cruze close behind in fourth place; the Elantra is fifth place to date with a strong lead over the rest of the segment.Check out the full sales breakdown in the chart below.Source: The Automakers Vehicle June 2013 June 2012 Year-to-Date Chevrolet Cruze 32,871 18,983 133,689 Honda Civic 29,724 27,500 158,704 Toyota Corolla/Matrix 26,458 26,647 158,972 Ford Focus 23,144 21,186 134,785 Hyundai Elantra 22,163 17,655 126,244 Volkswagen Jetta/Sportwagen 14,813 13,604 81,296 Nissan Sentra 10,199 9211 66,439 Mazda3 7566 8835 52,701 Subaru Impreza/WRX 6907 6319 39,106 Kia Forte 6620 7461 34,351 Dodge Dart 6437 202/995 (Dodge Caliber) 44,949 Volkswagen Golf/GTI 2602 4092 16,784 Share this article in: Facebook Twitter Google Plus Email June Compact Sales: Chevrolet Cruze Jumps to First /14 Advertisement to Skip 1 | 14 2 | 14 3 | 14 4 | 14 5 | 14 6 | 14 7 | 14 8 | 14 9 | 14 10 | 14 11 | 14 12 | 14 13 | 14 14 | 14


text:
In i Tunes you creare a library by either ripping your CD's to it or buying via the i Tunes store.(I only ues i tunes vouchers for this and when you redeem them the store "knows" how much credit you have left.) When you sttach the i Pod, Synching is where you allow the i Pod to acquire the whole or some of the library, As I have a number of i Pod users on my PC (Self, grand children) and we all have different tastes, I prefer to set preferences NOT to automatically synch. First, with a voucher, in iTunes, ensure you have created an account - usually your e Mail and a password, with address etc. Follow the prompts. Then in "Store" you should be able to browse by title, artist or genre.Later you can create playlists. Do ask specific things as this is a big subject!
iPhone X review