LAIR Communication with Test Case and Simulator

1. LAIR Communicationwith Test Case and Simulator Thesis overview Sean Forsberg

2. LAIR Background What is LAIR?

3. What is LAIR? “…research at the LAIR is focused on multi-robot systems and its applications in their field. Within these domains, topics of interest include motion planning, localization, mapping, integration of social systems, and control.” [LAIR Website]

4. LAIR Research Platform • OceanServer IVER2 • Current Features • Dual CPU • GPS/Compass • Altimeter & Depth Sensor • WiFi & Acoustic Modem • Near Future Additions • Dual-Hydrophone Beacon Detector • Side-Scanning Sensor (for Localization) Source: LAIR Website Source: Sean Forsberg

5. LAIR Development Goals • Provide a stable, verbose platform for research • Add (and test the capabilities ) new sensors & tech • Dual-Hydrophone Beacon Locator • Acoustic Modem • Integrate a second IVER2 into missions • Develop an API for User CPU Apps • Ensure safe functionality/recoverability of IVER2 • Utilize/Test the IVER2 platform • Various Masters Level research projects • Spark interest of incoming Freshman (CPE123)

6. Current LAIR Projects • Shark Tracking • Track (chase) a beacon-tagged shark • Phased, Load-Balanced Tasking • Used for optimized search, mapping, and data acq. • Communication • Using Wi-Fi, Underwater Modems (and possibly more) • roboSim • Development environment for research and testing

7. IVER2 Communication Current State and Goals

8. Communication Requirements • Cooperative Robots must be able to talk • Dynamic environments • Special protocols must be considered in order to successfully transmit from robot A to robot B • Delay tolerant • Multi-path, redundant ad-hoc routing • Underwater Robots • Water absorbs EM therefore acoustic modems used when submerged (or communicated with other submerged items.) • Acoustic systems still have limited range

9. Current IVER2 Communication • WiFi (802.11G) Modem • Antenna is integrated into tail mast • Modem is integrated into Main CPU • Must Remote Desktop to Main CPU to access IVER2 • Then Remote Desktop to User CPU to access app • Remote Transmitter for power controller • Hard reset and power supply shutoff only • Has caused Windows to corrupt more than once • WHOI Acoustic Modem • IVER2’s come modem built in but hasn’t be used • Ground/Surface station modem just received

10. Underwater Communication Source: WHOI Website

11. IVER2 Comm. Thoughts • Communication Protocols must include • Mix of Wi-Fi and Acoustic Modems • Routing of data/packets must be dynamic • Should assume non-continuous connection with base station (therefore ad-hoc system required) • Due to dual systems within the IVER2, extra routing is required • Wi-Fi is on main processor • Acoustic modem is on secondary

12. Project Driven Development Push Concept with Task

13. Project Driven Development • User a project requiring communication to… • Define specifications • Encourage development • Discover limitations of protocols • Find bugs • Research the benefit of strategic communication on Multi-Robot Systems • What benefits are achieved • Just data logging? • Quicker performance • More complete functionality

14. Phased & Load-Balanced Data Acquisition • Phased, load-balanced cooperative MRS (Multi-Robot Systems) can achieve tasks… • Quicker • More people doing the work (without large overlaps) • More accurately • Composited sensor readings (can) reduce error • Overlapping work & communication can help in localization • More complete results • Can detect changes quicker in a dynamic environment • Quicker detection means less is missed in a highly dynamic world

15. Phased & Load-Balanced Data Acq. (Cont.) • Gather Oxygen/Bio data in a body of water • Robots will take readings over a 3D region by oscillating around dimension. Top View

16. Perfect Environment • Uniform depth and width • Automatically Balanced • Synchronization Easily Maintained • Width < Max Communication Range • Robots will always be in communication Front/Back Slice

17. Actual Environment • Curved, Uneven Ground and Bay Shape • Must Dynamically Balance • Synchronization Quickly Lost • Width is Dynamic • Robots will not always be in communication Top View

18. Project Comm. Demands & Goals • Communicate with other robots in order to maximize productivity and minimize delay between data points. • Tolerate communication losses due to submersion, range, or a combination of the two. • Operate in an unknown environment • Mapping on the fly • Absolute Positioning Trust Between Robots • Other Desires • Allow the addition (and removal) of robots on the fly. • Synchronized movements

19. Environment Simulation Not Just Convenient, Required!

20. Why Simulate? • Robots are expensive! • Being able to simulate large scale activities without a large budget allows new projects to be prototyped • Humans make mistakes • Bad code in an underwater, flying, or even ground robots can result in a lost robot ($$) • Researchers can test algorithms/concepts • Although only simulated data is being shared with the robot, we can make it complete enough to test concepts without having to be in the field • Tests are reproducible!

21. The roboSim Environment • A virtual environment that simulates the real world for code development and research. • Real & Virtual Agents can interact/communicate • An agent is composed of modules (C++ classes) • New agents can be added • New sensors created • “Error” can be added • Agent code is independentof the environment Source: Sean Forsberg

22. RoboSim Design Overview RoboSim World Devices Agents GIS Terrain Input Sensors Physical Locomotion Simulated Local Area Lat/Long Comm. Beacons Radios Devices: Feedback based on world & agent instructions Agents: Objects that interact with the world and are a collection of devices Each device and agent constructed as a module building on previous to allow quick creation/modification.

23. Object-Oriented Design UnderwaterAgent TorpedoAgent IVER2Agent modAgent SurfaceAgent DiffDriveAgent X80Agent CommAgent RadialCommAgent WiFiAccessPoint modDevice LocationDevice GPSDevice LocomotionDevice PropellerDevice TriBeaconDevice FinDevice EnvSensorDevice DistanceSensor SonarSensor CommDevice WiFiModem

24. IVER2 System Design • IVER2 has a dual, independent CPU design with COM based interface • Both CPUs are currently running Windows XP • User CPU reqs.and recvs datausing telnet tothe main Source: OceanServer Manual

25. IVER2-roboSim Interface (Cont.) Current IVER2 Configuration OceanServer App Sense/Control User App User CPU COMPort Main CPU roboSim-IVER2 Interface Configuration User App EthBridge roboSim Environment Sim User CPU COMPort Graphical Render

26. roboSim Challenges • Real Terrain Modeling • Import GIS (and other data source) topographic maps (various resolution) • Real-time Graphics • Requirement to minimize the polygon/vertex count (aka low-res terrain) • Distance Sensors • Require high resolution detail in order to accurately simulate the environment (aka high-res terrain)

27. Presentation Review What Just Happened?!

28. Overview • LAIR = multi-robot development • Underwater systems = comm. challenges • Lack of RF based transmission • Bandwidth limitations of Acoustic modems • Dynamic environments • Multi-robot systems require communications • Effective comm. can result in quicker (and more effective) systems • Experiments on expensive platforms are risky & expensive • The IVER2 provides an excellent interface for simulation.

29. Questions! Harassment is Encouraged