Scenario Proposals

The MAST project aims to unite the efforts of a disparate group of researchers studying microsystems. The main thrust of the Integration Center involves designing experiments that demonstrate and evaluate the capabilities of technologies developed in the other MAST centers. In this Luncheon, we seek to propose and discuss several such scenarios developed following the brainstorming lunch at La Val's last Thursday.

Below is a copy of the presentation.
Attach:scenarios_presentation.pdf

Mast Forum: Scenario Proposals Feedback

When reasoning about mobility requirements for a particular platform, we should distinguish between requirements imposed by terrain complexity and constraints on the actual dynamic ability of the platform. In addition, we should consider how much computational power will be required to attain a specific level of mobility.

In general, we should distinguish between minimal capabilities required to achieve some goal and the ideal or optimal capabilities. Further, we should idendify cases where, e.g., the deployment scheme can eliminate the need for high agent mobility.

Note that, from a funding perspective, the third- and fourth-year demos are the most critical.

It is desirable, but not critical, that demonstrations be holistic; in the absence of true integration, we may demonstrate the effectiveness of each omponent separately.

It is potentially feasible to launch an agent 1 - 2 km via a projectile system. However, this may not be useful, since the ideal launch distance would be on the order of 100 km, i.e. the distance from the 'green zone' on a battlefield to the front line.

Sending our agents deep into the field may pose problems for communications, but it may be possible to rely on a relay system operated via UAV's to establish communication across vast distances. The real challenge in our case may be to simply transmit a signal from within a building to a base station somewhere outside. From there, UAV's or Humvee's may relay the signal back to base.

It is apparently easy to build a glider, however: it is no longer an area of active research, and it should be noted that gliders are extremely susceptible to gusts of air, hence the probability of success is low in many environments.

Note that the microelectronics that go into a vibration center are quire sophisticated; it is possible to estimate the proximity and quantity of intruders to high accuracy. The real challenges involved in using vibration sensors are in deployment (autonomous robots), data collection (wireless sensor networks), and data analysis (sensor fusion). If there was a compelling reason to build a new vibration sensor, the microelectronics center could conceivably work on it.

It would be good to obtain/construct a wider variety of quality sensors: thermal (for people, machinery), chemical (for human exhalation, deisel). However, until these sensors arrive, we may use currently-available technology as surrogates to develop algorithms and machines.

It may be a good idea for those interested to meet a few times to discuss the construction of a new MAST-specific sensor board that incorporates a wide variety of sensors. To benefit the Microelectronics Center, it would be a good idea to choose sensors that logically lead to replacement by components developed by that Center. A possible approach might be to deliniate classes of sensors--binary, continuous, range, ...--and select a representative sensor from each category. This would provide a nice abstraction for the Autonomy center and make it easy to explain how new sensors developed by the Microelectronics center would be employed.

There is funding allotted in the MAST program to study human interfaces for the systems we are developing; it may be worthwhile for those interested to pursue that aspect.

Note that tele-operated robots cannot advance with a squad for safety reasons. Any robots that will be deployed with humans must not distract them; it would be fantastic but really difficult to make autonomous robots that reconfigured based on the human situation.

This year, we need to perform some experiments at UMD and create demonstrations in simulation.

Note that re-collecting agents might be important to keep them out of the hands of the enemy. However, a possible alternative solution would be to include a self-destruct mechanism in each board.

By the end of June, each group should give specifications and software as applicable for one or two deliverables they plan to have available by September. These components will be integrated into the demonstration simulation for this year.

PmWiki can't process your request

Cannot acquire lockfile

We are sorry for any inconvenience.