Scope of This Case Study
This case study describes the design and build of a two-modality early-warning prototype for wildlife crossings on roads, developed for an IEEE student competition in 2018. It covers the problem, the design requirements, the architecture, the fusion rule and the prototype. The prototype was demonstrated in a controlled setup using staged signals. No quantitative evaluation records were retained, so this study makes no claims of detection rate, false-alarm rate or latency, and no claim of performance on a live road.
Abstract
Wild animals, including elephants and deer, cross roads in Sri Lanka, and collisions endanger drivers, passengers and the animals. Fixed signage warns drivers in general but does not indicate that an animal is near a crossing at a given moment. This case study describes a low-cost prototype that combines two sensing modalities: an infrared beam across the expected crossing path, and a geophone that detects ground vibration. An Arduino at each sensing node samples its sensor, and a Raspberry Pi fuses the events. An alert is generated only when both modalities register an event within a fixed time window, which is designed to reduce false alarms from either sensor alone. The study sets out the requirements, the architecture, the fusion rule and the build, and identifies the constraints that a field study must address.
1. Introduction
Roads that pass through wildlife corridors present two problems. Drivers receive little warning that an animal is present at a particular point, and long road sections are difficult to monitor by hand. An early-warning system addresses the timing gap. If an animal near the road can be detected a short distance ahead of the crossing, a warning can reach approaching drivers while the risk is current.
The design goal was a system that is cheap to build, simple to maintain, and able to run without an operator. This case study treats the project as a design and build exercise, and it reports the engineering decisions, not the results of a field study.
2. Design Requirements
The prototype was designed against four requirements. It had to use inexpensive, readily available components. It had to detect a crossing event from the beam and a ground-borne event from the vibration sensor. It had to avoid alerting on either signal alone, since each alone is ambiguous, with a beam break possibly caused by a small object and vibration possibly caused by traffic or wind. And it had to log events with timestamps, so that a later review could check what triggered each alert.
3. System Architecture
The system has two sensing nodes and a processing unit. Figure 1 shows the architecture.
Node A is the infrared beam-break array. An emitter and receiver pair forms a beam across the expected crossing path. An interruption of the beam longer than a minimum duration is recorded as a crossing candidate, and the minimum duration filters out brief disturbances and small objects.
Node B is the geophone. A geophone coupled to the ground measures vibration. The Arduino computes a short-window amplitude measure and flags a vibration event when the measure exceeds a threshold. Geophones respond to ground motion from nearby traffic as well as from animals, so the threshold and the frequency band are the main design choices at this node.
The processing unit is a Raspberry Pi. It receives events from both nodes, applies the fusion rule, logs every event with a timestamp, and generates the alert when the rule is met.
4. Fusion Rule
An alert requires a beam-break event and a vibration event within a defined time window. Figure 2 shows the logic. A beam break on its own is logged as a possible small object or fault. A vibration on its own is logged as possible traffic or wind. Requiring both reduces the chance of an alert from either source alone, at the cost of possibly missing an animal that crosses quietly or with little ground vibration. The trade-off is the central design decision in the system, and it can only be judged properly in a field study.
5. Build and Controlled Demonstration
The prototype was built from the two sensing nodes and the processing unit, with the nodes connected to the Raspberry Pi through a serial link. The fusion logic and the event log were implemented on the Raspberry Pi.
The prototype was demonstrated at the IEEE student competition in a controlled setup, using staged crossings and simulated vibration. Staged crossings differ from real animal movement in speed, weight, path and the ground vibration they produce, so the demonstration shows that the logic works as designed, not how it would perform with real animals. No records of detection, false alarms or latency were kept from the demonstration, and no such figures are reported here.
6. Known Constraints
The design has constraints that a field study must address. Geophone readings are affected by traffic, wind and machinery, so the threshold and frequency band must be set for the specific road. The beam-break module is affected by vegetation, weather and objects that are not animals. Power supply for remote sections, weatherproofing, maintenance, and protection against theft and vandalism are all unaddressed by the prototype. The warning output for drivers was designed as a concept and was not tested in a road setting.
7. Future Work
The next stage is a field study on a real road section, with permission from the relevant road and wildlife authorities. It should record detections and false alarms against real animal crossings, measure alert latency, and test the warning output with drivers. Thresholds and the fusion window should be set from recordings made on the road. Until that work is done, the system should be described as a prototype and a design, not as a deployed or validated early-warning system.
8. Conclusion
This case study describes the design and build of a two-modality early-warning prototype for wildlife crossings. The prototype combines an infrared beam with a geophone, and fuses them so that an alert requires both. The design is a credible basis for a field study. Its performance on real roads and with real animals has not been measured, and the next step is that field study.
Sources
This case study cites no external sources. The description of the road problem reflects the author’s project brief and motivation, and the competition is stated as it occurred.