1 / 73

Active Spaces

Active Spaces. Roy H. Campbell rhc@cs.uiuc.edu Computer Science Department University of Illinois at Urbana-Champaign. “Where virtual reality puts people inside a computer-generated world, ubiquitous computing forces the computer to live out here in the world with people. . Mark Weiser.

morton
Download Presentation

Active Spaces

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Active Spaces Roy H. Campbell rhc@cs.uiuc.edu Computer Science Department University of Illinois at Urbana-Champaign Roy H. Campbell (rhc@cs.uiuc.edu)

  2. “Where virtual reality puts people inside a computer-generated world, ubiquitous computing forces the computer to live out here in the world with people. Mark Weiser Roy H. Campbell (rhc@cs.uiuc.edu)

  3. Introduction • A standard definition for an Active Space does not exist, but it is evolving. • There are different approaches regarding functionality required and implementation details. Roy H. Campbell (rhc@cs.uiuc.edu)

  4. Overview • Georgia Tech, Microsoft: • Emerging perspectives • University of Illinois: • Scale • Software Infrastructure • Berkeley, M.I.T., Washington: • Comparison Roy H. Campbell (rhc@cs.uiuc.edu)

  5. Active Spaces Properties • Some common requirements: • Location Detection • Contextual Model • Autonomous and Responsive Behavior • Correlation of Heterogeneous Input • Interaction Mechanism Roy H. Campbell (rhc@cs.uiuc.edu)

  6. Example ImplementationsClassroom 2000. Georgia Tech • Goal: Preservation and augmentation of electronic notes taken by students and teachers. • Attach and synchronize audio, video and annotations to class notes Roy H. Campbell (rhc@cs.uiuc.edu)

  7. Example ImplementationsClassroom 2000. Georgia Tech • The architectural scheme must be able to evolve with time. • Scheme phases: • Preproduction: Automate tasks to begin class Live • Capture: Record and timestamp all events associated to class. • Postproduction: Support development of interfaces to integrate and associate related streams. • Access: Provide a universal access method (WEB) Roy H. Campbell (rhc@cs.uiuc.edu)

  8. Example ImplementationsClassroom 2000. Georgia Tech • First implementation: • Useful as an experimentation prototype. • Equipment and software not good enough. • Lessons learned were applied to the next implementation. Roy H. Campbell (rhc@cs.uiuc.edu)

  9. Example ImplementationsClassroom 2000. Georgia Tech • Living Laboratory • Completely equipped classroom that hosted several courses • Improved software that allowed better media integration. • Software infrastructure did not require as much attention from users as in previous implementation (invisibility required by ubiquitous computing) Roy H. Campbell (rhc@cs.uiuc.edu)

  10. Example ImplementationsClassroom 2000. Georgia Tech • Their conclusions: • There should be a motivating application. • Built system should address some notion of scale: • Physical space covered. • Number of individuals involved. • Number and variety of devices supported. • Amount of time over which the application is run. • System must be subjected to real and everyday usage before being subject of authentic evaluation. Roy H. Campbell (rhc@cs.uiuc.edu)

  11. Example ImplementationsEasyLiving. Microsoft • Focuses on physical home and work environments. • Computing must be as natural as lighting Roy H. Campbell (rhc@cs.uiuc.edu)

  12. Example ImplementationsEasyLiving. Microsoft • People are the central entities of the Active Space. • Main characteristics of their intelligent environment: • Self-awareness • Casual access • Extensibility Roy H. Campbell (rhc@cs.uiuc.edu)

  13. Example ImplementationsEasyLiving. Microsoft • Self-awareness: “EasyLiving spaces must be aware of their own activity and contents to allow appropriate responses to the movement of people and their requests” • Requirements: • Geometry • People within space • People’s actions and preferences • Resources available Roy H. Campbell (rhc@cs.uiuc.edu)

  14. Example ImplementationsEasyLiving. Microsoft • Casual Access “Users should not be required to go to a special place to interact with the computer. Nor should they be required to wear special devices or markers to have the computer know where they are” • The computer is everywhere. Roy H. Campbell (rhc@cs.uiuc.edu)

  15. Example ImplementationsEasyLiving. Microsoft • Extensibility: “EasyLiving capabilities should grow automatically as new hardware is added” Roy H. Campbell (rhc@cs.uiuc.edu)

  16. Example ImplementationsEasyLiving. Microsoft • Design issues: • Sensing and Modeling: video cameras • User interfaces: new approaches, migration • Privacy Roy H. Campbell (rhc@cs.uiuc.edu)

  17. Example ImplementationsEasyLiving. Microsoft • Design issues: • Architecture for extensibility Room Server Device Device Central Server Room Server Device Device Roy H. Campbell (rhc@cs.uiuc.edu)

  18. Active SpacesUIUC The future of computing is • implicit • to sense and affect its surroundings • interconnected and mobile • nimble and adaptive Roy H. Campbell (rhc@cs.uiuc.edu)

  19. Vision: Pervasive Computing • Anywhere/anytime collaboration • “Real world” environments • augmented with information spaces • Mobility and ubiquity • Applications like design and prototyping Roy H. Campbell (rhc@cs.uiuc.edu)

  20. Implicit Computing • Features • embedded in every day devices • mobile and interconnected • pervasive throughout the environment • coupled to information sources • active, modifying their environment • Analogy • telephone (implicit) • telegraph (explicit) Roy H. Campbell (rhc@cs.uiuc.edu)

  21. Research Vision • Distributed, multimodal collaboration • situated and mobile • varying resources • bandwidth, computing, power, and display capabilities • varying collaboration intensities • focused, interested, and ambient • dynamic reconfiguration and adaptation • resources and modalities Roy H. Campbell (rhc@cs.uiuc.edu)

  22. Intelligent Spaces • Smart rooms • intelligent offices – domiciles of mobile users • conference and seminar rooms – multiway collaboration • Virtual environments • smart device prototyping and information space introspection • Lone rangers • local, high-bandwidth mobile collaborators • Road warriors • remote, low-bandwidth mobile collaborators • Prototyping laboratories • smart device stereolithographic fabrication Roy H. Campbell (rhc@cs.uiuc.edu)

  23. Research Vision • Three software pillars • dynamic, interoperable software frameworks • multimodal, adaptive networking • controls for adaptive management • Hardware testbeds • smart rooms and virtual environments • mobile users and devices • device prototyping • development infrastructure Roy H. Campbell (rhc@cs.uiuc.edu)

  24. Smart Rooms • Components • intelligent physical objects (“rocks”) • ambient condition sensors • user, object, and location identifiers • X10 automation sensors and controls • lighting, power, temperature controls • commercial speech tools • limited vocabulary voice commands • voice acknowledgments • tracking cameras • distributed collaboration and localization Roy H. Campbell (rhc@cs.uiuc.edu) DARPA CPOF

  25. Smart Rooms • Components (continued) • smart white boards • “brain storming” and digital ink capture • multiple displays • conference LCD displays • high-resolution flat panels • multiway conferences and digital video • digital video encoders • MPEG and HDTV multicast • multimodal networks • infrared, spread spectrum radio, Ethernet, and ATM Roy H. Campbell (rhc@cs.uiuc.edu)

  26. Lone Rangers • Rationale • continuous connectivity • local, mobile collaborators • “drop in” for smart room collaborations • Components • wearable computers with wireless networks • multimedia workstations/PCs Roy H. Campbell (rhc@cs.uiuc.edu)

  27. Road Warriors • Rationale • wide-area mobile collaborators • low bandwidth connectivity • Components • personal digital assistants (PDAs) • Palm Pilot • palmtop computers • Toshiba Libretto and/or Windows CE systems • two-way pagers • RIM/Bellsouth or Motorola ReFLEX PageWriter Roy H. Campbell (rhc@cs.uiuc.edu)

  28. Virtual Environments • Components • drafting table ImmersaDesks • gaze tracking hardware • tactile data gloves • Continuing EVL collaboration • virtual environment software • ImmersaDesk prototypes • Walls • 30 ft x 9ft 10 x 3 CPUs/displays Roy H. Campbell (rhc@cs.uiuc.edu)

  29. Prototyping Laboratory • Rationale • prototyping of smart space objects • physical/virtual interconnection • Components • stereolithographic prototyping system • object scanner Roy H. Campbell (rhc@cs.uiuc.edu)

  30. Challenge: Interoperable Component Architecture • Scalable • Flexible • Pervasive • Dynamic and adaptive • Mobile • Visual and aural Roy H. Campbell (rhc@cs.uiuc.edu)

  31. Challenge: Quality of Service • Spectrum of networks and computers • Wealth of multimedia and requirements • Dynamic requirements and resources Roy H. Campbell (rhc@cs.uiuc.edu)

  32. Challenge: Active Space Analysis and Control • Modality transduction • Heterogeneous devices • Information access metaphors Roy H. Campbell (rhc@cs.uiuc.edu)

  33. DefinitionsActive Spaces. UIUC • An "Active Space" (AS) is a framework which models and manages physical environments as well as its contents • "Space" implies that a principle use of the AS framework is to manage physical spaces, such as campuses, buildings, meeting rooms, cities, offices, cars, buses, trains, etc Roy H. Campbell (rhc@cs.uiuc.edu)

  34. PropertiesActive Spaces. UIUC • "Active" notes that the framework is intended to support reactive and customized behavior. • Key properties identified so far for Active Spaces: • Export an adaptable interaction model, that allows interacting with the active spaces • Provide a contextual model • Reflective and autonomous • Have an associated physical counterpart. Roy H. Campbell (rhc@cs.uiuc.edu)

  35. PropertiesActive Spaces. UIUC • Key properties identified so far for Active Spaces: • Contain entities with a well defined behavior that can be dynamically created and modified. • Provide a concept of inside and outside. • Define protocols to interact with other active spaces. • Autonomous, contextual and can trigger events spontaneously Roy H. Campbell (rhc@cs.uiuc.edu)

  36. Key Technical RequirementsActive Spaces. UIUC • Key Technical Requirements: • Dynamic Behavior • Reflection • Adaptability • Component Based Infrastructure Roy H. Campbell (rhc@cs.uiuc.edu)

  37. Example ImplementationsActive Spaces. UIUC ARCHITECTURAL REQUIREMENTS Roy H. Campbell (rhc@cs.uiuc.edu)

  38. ImplementationActive Spaces. UIUC • We provide a generic infrastructure that allows implementing different scenarios. • Every particular scenario defines the nature of the entities contained in the AS as well as the behavior of the particular AS. • The great diversity of Active Space scenarios makes it impossible to define a single Active Space that covers all semantic requirements. Roy H. Campbell (rhc@cs.uiuc.edu)

  39. Smart room configures itself as user enters PDA configures itself for room User OS manages accessible room resources in collaboration with room OS Video transferred from smart room HDTV display to palm top as user leaves User accesses smart room from remote facilities User environment follows user movements Future Example of Interaction Roy H. Campbell (rhc@cs.uiuc.edu)

  40. 2K • User-oriented, network-centric OS • built from components • Based on reflective distributed objects • Targets ubiquitous computing/smart spaces • Supports mobility and persistence • leveraging CORBA, DCOM, Java RMI services and protocols • Embedding legacy applications and systems Roy H. Campbell (rhc@cs.uiuc.edu)

  41. Distributed Objects • Reflective • naming, location, protocol, and implementation • Dynamic • dependency model, programmable reconfiguration • Self-Aware • self-monitoring, self-configuring, and dependency aware • Standardized • Object Request Broker (ORB), OMG, Java RMI, or DCOM Roy H. Campbell (rhc@cs.uiuc.edu)

  42. Profile Service 2K Env. Service Office 3201 Naming Service QoS Office 3234 Roy H. Campbell (rhc@cs.uiuc.edu)

  43. Components • Componentized ORBs: dynamic TAO • concurrency control and thread models • resource allocation and schedulers • Microkernel support for ORBs: Off++ • Corbarized device drivers: video, X10 • Corbarized distributed OS: 2K • LegORB: 8Kbytes, Palmshell, remote video • Proxy server: Palm video filter • Persistent store & name server: nameORB Roy H. Campbell (rhc@cs.uiuc.edu)

  44. Features Demonstrated • Configurable ORBs and reflection • Programming with dependency objects • Self-awareness in ORBs • LegORB – a thin ORB • PalmMPEG video – proxies for modality • X10 ORBs – ubiquity • The 2K environment – mobile users • Security UIUC Tiny Sesame Roy H. Campbell (rhc@cs.uiuc.edu)

  45. Automatic ConfigurationPrerequisites • Specifies component needs • HW resources • HW capacity • software services required • Helps implement WYNIWYG • Video client example • PC with MPEG decoder card • 50% of 200 MHz processor required • CORBA video server Roy H. Campbell (rhc@cs.uiuc.edu)

  46. Automatic ConfigurationDynamic Dependence ComponentConfigurator associated with each relevant component depends on depends on COMPONENT HOOKS CLIENTS Hooked Components CLIENTS Roy H. Campbell (rhc@cs.uiuc.edu)

  47. DynamicTAO: Dynamically Configurable CORBA ORB • Reflective ORB • architecturally self-aware • dynamic component (un)loading • Reconfiguration of • ORB engine • CORBA applications Roy H. Campbell (rhc@cs.uiuc.edu)

  48. Configuration Agent Application of dynamic TAO • A video distribution network • code distribution, group reconfiguration, state inspection • Configure graph of network • Agents multicast update • dynamic TAO dependencies synchronize update • Future: keep servers and clients running as permitted by dependencies Roy H. Campbell (rhc@cs.uiuc.edu)

  49. Server Client ORB Monitor Storage Server User Query Interface Users Context Monitoring Roy H. Campbell (rhc@cs.uiuc.edu)

  50. Profile Server Environment Service Environment Implementation Repository 2K Camera Device Driver PalmPilot Integration in 2K System Bootstrapping 2k System Utilization 2 1 3 4 5 6 Camera 7 Roy H. Campbell (rhc@cs.uiuc.edu)

More Related