| Distributed Tracking Demo
|
|
|
|
</tr>
</table>
Script
Distributed Pursuit Evasion Games Demo
Synopsis:
This demo will demonstrate the integration of wireless sensor network (WSN) hardware platform and software services in a distributed control application. A team of three evaders will enter the field monitored by the WSN. The WSN will detect motion in the field and will report detection to a central station. Supernodes (Tier 2) at the edge of the WSN will route detection packets to the central controller using 802.11b. This, in turn, will perform the multiobject tracking [1] of the evaders, by using a data association algorithm to estimate the number of different entities to track in the field and then build a track for each of them. The demonstration will show robustness of the algorithm at crossing points. Evaders will then exit the field and re-enter from the exit point. This second part of the demo will introduce the control part, as a team of pursuers will be dispatched to catch evaders. While the tracks of the evaders will be computed from real people walking, the action of the pursuers will be only simulated. Central controller will use tracking estimates of evaders to dispatch pursuers, to dynamically assign evaders to them and provide evaders' tracking info. A “bat,” which is a small remotely controlled fixed-wing aerial vehicle, will be equipped with a video camera and will report video of the scene from above. Static cameras will also observe the scene.
Display:
The conference room will be used as the center of operations.
Three displays will show:
>> Real time tracking info on matlab
>> Top view of the field showing real time camera view from the bat
>> Camera views from static cameras on the field
Personnel:
1-evader1
2-evader2
3-evader3
4-bat operator (Travis)
5-assistant to Travis
6-Computer Operator in conference room for display
7-Computer operator to activate static cameras
8-responsible for making sure wi-fi network works
9-responsible for monitoring WSN
10-coordinator of activities
11-MC
Infrastructure:
-WSN (need to decide with song spacing, in particular for crossing points)
-Network connection between WSN and control computer
-3 displays with computers for conference room
-network to transmit the video from bat and cameras to conference room
-10 FRS radios to all the personnel for coordination and communication in case of emergency.
-4 webcams and a wireless router to capture and display images from the field.
Plan of action:
Time(min) ACTION
0 Network up and running shows map of nodes
1 Bat takes off to show video from the field.
2 Evader 1 enters the field at x_1 and move in direction \phi_1, with speed v_1
2.30 Evader 2 enters the field at x_2 and move in direction \phi_2, with speed v_2
3 Evader 3 enters the field at x_3 and moves in direction \phi_3 with speed v_3; 1 and 2 will cross each other at a distance d_12 while 3 will stay at distance d_3 from them.
8 All three evaders will have left the field.
10 3 re-enters the field from the exit position moving in direction \phi_3, with velocity v_3,
11 1 enters the field from the exit position moving in direction \phi_1, with velocity v_1=v_3
13 Pursuers P_1 and P_2 are dispatched from position P_x_1 and P_x_2 (in simulation screen) they will be chasing 1,3 with velocity 1.1*v_3
Distributed Tracking Demo
Synopsis:
This demo will demonstrate the capability of the Wireless Sensor Network to provide tracking information about moving objects in the field in a distributed way. Differently from MCMC tracking algorithm used in the PEG demo, here there is no need for a centralized infrastructure. The tracking algorithm is distributed in the network. Information about the track of a target moving through the network is transmitted to all the nodes in the network via flooding and can be retrieved from any node. As a consequence, the algorithm is less vulnerable to certain attacks – a more centralized algorithm could not function if the root node or nodes were disabled. Such a distributed algorithm is particularly suited in the cases where nodes are deployed in adversarial territory, perhaps by dropping them from an aerial vehicle, and data is retrieved "on the fly" in a similar way. In this demo we will demonstrate distributed tracking and information retrieval by airplane. An intruder will enter the field and will be tracked. Tracking info will be collected by a bat (a small fixed-wing aerial vehicle), which will relay it to the operation center (conference room) where it will be displayed on a screen along with images from the on-board camera and the static cameras.
Display:
The conference room will be used as the center of operations.
Three displays will show:
>> Real time tracking info on Matlab
>> Top view of the field showing real time camera view from the bat
>> Camera views from static cameras on the field
Personnel:
1-evader1
2-bat operator (Travis)
3-assistant to Travis
4-Computer Operator in conference room for display
5-Computer operator to activate static cameras
6-responsible for making sure wi-fi network works
7-responsible for monitoring WSN
8-coordinator of activities
9-MC
Infrastructure:
-WSN
-Network connection between WSN and control computer
-3 displays with computers for conference room
-network to transmit the video from bat and cameras to conference room
-infrastructure to put video from bat on the network
-10 FRS radios to all the personnel for coordination and communication in case of emergency.
-4 webcams and a wireless router to capture and display images from the field.
Plan of action:
Time(min) ACTION
0 Network up and running shows map of nodes
1 Bat takes off to show video from the field.
2 Evader 1 enters the field at x_1 and moves in direction \phi_1, with speed v_1
3 Bat flies over the network and collects real time tracking info, sending them to the conference room for display.
10 Evader 1 exits the field
Requirements
- pytos
- drip/drain/nuclues
- cd $TOSROOT/beta/Drain/tools/java/net/tinyos/drain && make
- cd $TOSROOT/beta/Drip/tools/java/net/tinyos/drip && make
- cd $TOSROOT/contrib/nucleus/tools/java/net/tinyos/nucleus/ && make
- CLASSPATH needs the above dirs too
- Czar: Jaein
- Status: Done
- Caveats: Add solar charging to the demo
- Verified: 8/8/2005(except Prometheus)
- Czar: Jonathan
- Status: Done.
- Caveats: Needs gui. Verify that it works w/multiple base stations.
- Verified : 8/9/2005: works with 2 Trios and 1 telosb TOSBase over the radio
- Czar : Gil
- Status: Done.
- Caveats: Drip/drain must be shown to work w/multiple base stations
- Verified: ??
- Czar: Kamin
- Status: Done
- Caveats: None
- Verified: ??
- Czar: Sukun
- Status: Done
- Caveats: More test in large scale
- Verified: ??
| Milestones
</tr>
|
| Jul 27
| Aug 3
| Aug 10
| Aug 17
| Aug 24
</tr>
|
- Fix logging bugs
- Add crc checking to every 1k transfer
- Take out bcast, add drip, drain and GroupSend
|
- Add checksum to the entire data instead of each 1K chunk
- Tune shooting speed
|
- Directed dissemination and Drain are used.
- Functionality freeze
|
|
</tr>
</table>
| Risks
</tr>
|
| Jul 27
| Aug 3
| Aug 10
| Aug 17
| Aug 24
</tr>
|
|
None?
|
- Flow control depends only on depth, not on congestion
|
|
|
</tr>
</table>
Scenarios:
- Scenario #1: drain to gateways, use 802.11 backchannel to get data to tablet.
- Scenario #2: drain to gateways, use GroupSend to get data to tablet.
- Scenario #3: drain to gatewas, use clog to get data to tablet.
Status:
- Scenario #1 is done.
- Scenario #2 is Close.
- Scenario #3 is Hard.
| Milestones
</tr>
|
| Jul 27
| Aug 3
| Aug 10
| Aug 17
| Aug 24
</tr>
|
- Add UVA detection code
- Add scenario #2 functionality to TestDetectionGui.py
- Add a buzz (with enable toggle) to each detection event
|
|
- UVA detection code running stably for 3+ days on 5 node setup in 410 Soda
- Basic MTT algorithm tested on 4 nodes and works
|
|
</tr>
</table>
| Risks
</tr>
|
| Jul 27
| Aug 3
| Aug 10
| Aug 17
| Aug 24
</tr>
|
|
ROM size!!!
|
|
Scaling to more nodes
|
|
</tr>
</table>
Scenario #1: TBA
Demonstrate a distributed tracking algorithm which operates in the network without requiring a base station.
- Status
- Nesc code works in simulation.
- Code size:
- Does not compile with either Nucleus or Deluge included.
- Compiles when Nucleus and Deluge are removed.
- Size difference between distributed tracking test app and detection test app, both with nucleus and deluge removed, is 42206 - 30140 = 12066 bytes. I may be able to compress it.
- Runs on two motes with Phoebus' code underneath. (Need more motes.)
OSU Trio Demo
Please note the changed area that OSU intends to use for the demo - after looking at the grass pictures, we feel that this area is much more PIR-friendly than the one to the east of the road. Hopefully, this change won't cause any problems.
We would like to figure out where to setup the base station for this topology depending on factors such as:
1. Availability of power (for laptops etc) around this region
2. Radio range of trios on tripods (to figure out max hop count for routing - we are planning to do radio range tests on tripod-mounted trios to figure this out soon) - this will dictate whether our base station will be at a corner or in the center of the deployment.
Could someone at UCB confirm that this area would be ok and that nodes in this area would be deployed in time to perform expts on the morning of Saturday Aug 27?
Also, as was discussed in the telecon, could the deployment be planned so that these nodes are deployed first so that we get the id, GPS information early on to hardcode in our app? |
|
|
|
|