Scenario Design

Main.ScenarioDesign History

Hide minor edits - Show changes to markup

January 24, 2009, at 07:59 AM by 76.218.68.71 -
Changed line 14 from:
  • so many people won't waste time trying to destroy them all
to:
  • so many, people won't waste time trying to destroy them all
January 21, 2009, at 11:49 AM by 128.32.43.144 -
Added line 28:
  • Diversion tactics
January 15, 2009, at 02:57 PM by 128.32.43.144 -
Changed lines 53-67 from:
  • maintain security in friendly building, detect intrusion
to:
  • maintain security in friendly building, detect intrusion

Deployment Strategies

  • mortar launch with aerial deployment
  • ballistic launched from green zone
  • static network, buried beforehand
  • grenade toss
  • Drop on roof
    • Lots of holes in buildings in active war-zone
  • Entry through windows
    • lots of broken, open windows in active war-zone
  • Drop out of plane (raven, currently in use is possibility)
  • controllable glider to land on building, deploy other sensors
  • Deploy from packbot
  • 1km standoff deployment
January 15, 2009, at 02:53 PM by 128.32.43.144 -
Changed line 24 from:
  • Human movement control, intimidation
to:
  • Human movement control, intimidation
January 15, 2009, at 02:53 PM by 128.32.43.144 -
Changed lines 1-2 from:

High-level scenario design

  • Tradeoffs/Qualities
to:

High-level scenario design

  • Tradeoffs/Qualities
Changed line 28 from:
  • Intelligence gathering (used to support human ops)
to:
  • Intelligence gathering (used to support human ops)
Changed lines 48-53 from:
  • infiltrate building, map, locate targets
to:
  • infiltrate building, map, locate targets
  • Support/security
    • Dynamic perimeter
      • set up on the fly around humvee
      • assist in securing unknown, partially infiltrated building
      • maintain security in friendly building, detect intrusion
January 15, 2009, at 02:51 PM by 128.32.43.144 -
Changed line 2 from:
  • Tradeoffs/Qualities
to:
  • Tradeoffs/Qualities
Changed lines 23-48 from:
  • some "mobile" sensors cannot move far from where they are deployed. Only slightly adjust deployment
to:
  • some "mobile" sensors cannot move far from where they are deployed. Only slightly adjust deployment
  • Human movement control, intimidation
    • intelligent flash-bang grenade
      • locate people, navigate to good location, detonate
    • robot "body language", evoke fear/confusion, drive combatants out
  • Intelligence gathering (used to support human ops)
    • cameras
      • robot deploys static cameras as surveilance
      • swarm flies through building/city, take pictures, 3D map reconstruction
    • vibration sensors
      • drop on roof, locate snipers
      • deploy in field, network to track moving targets
    • aerial id of suspicious buildings
      • possibly, building is a trap, but need to investigate
      • don't want to deploy humans or packbot, alert enemy who will change trap
      • stealthy penetration of building, determine threat without tipping enemy off
      • Deployment from UAV practical here
    • weapon location, identification
      • Everyone has weapon, doesn't help friend/foe id
      • useful to distinguish AK-47/Rocket launcher
        • civilians don't have rocket launchers
      • vision based
    • monitor streets from rooftops
      • monitor building entrance
      • monitor movements for suspicious activity
    • infiltrate building, map, locate targets
January 15, 2009, at 02:44 PM by 128.32.43.144 -
Added lines 1-23:

High-level scenario design

  • Tradeoffs/Qualities
    • indoor/outdoor
      • Outdoor: robots can do a lot
      • indoor: need small platforms, case for MAST
    • stealth
      • unlikely to disguise as bug; if visible, will be squashed
      • useful in many operations, though difficult
    • quantity to deploy
      • large number, high scatter
        • high probability of having some useful sensors (though may be difficult to identify useful info)
        • lots of worthless sensors
          • useful as decoys?
          • so many people won't waste time trying to destroy them all
        • robust to failures
      • few sensors
        • high intelligence required
        • not robust to many failures
      • hierarchical scheme
        • nested "turducken" robots
        • high intelligence robots augmented by smaller, less mobile and intelligent systems
    • mobility
      • some "mobile" sensors cannot move far from where they are deployed. Only slightly adjust deployment

PmWiki can't process your request

Cannot acquire lockfile

We are sorry for any inconvenience.