brandon shrewsbury

RESPOND-R framework

The RESPOND-R framework is a modular data logging framework built for the purpose of studying Emergency Informatics as it relates to human-robot performance during disaster responses. The framework details how to use ROS for both centralized and decentralized logging of both homogeneous and heterogeneous systems in both real time and post analysis scenarios. This framework relies on existing ROS systems and provides tools to ease the incorporation of the RESPOND-R framework for data logging.

The Goal of RESPOND-R is simple. Log as much data as you can from robots and sensors during field use in a replayable format. Implementing a logging suite with full coverage of heterogeneous systems is not as simple. ROS provides an excellent avenue for both replay and standardization but many of the existing libraries do not cover data collection exclusively.

The RESPOND-R framework proposes a decentralized approach, one where each producer (system or agent) that creates accessible data in real-time should have an independent logger, consuming this data through whatever interface is available and publishing to the ROS blackboard for recording. An independent logger for each system is a hefty hit on mobility and logistics but the gathered data is invaluable to HRI and HCI studies. Additionally, a centralized/decentralized concurrent logging approach is also suggested to improve full scenario analysis.

Centralized vs Non Centralized
The answer is to always log locally in a non-centralized manner and also log centralized if the bandwidth and network paths are available. Local logging is simply recording all data using rosbag on the local ROS master. If you have the ability to sync data with another ROS master that can collect data from multiple systems, do it! This allows for both a more complete picture of theater as well as redundant backups. This approach will also allow for less compilation during post event data joins should you want to combine datasets.

Online vs. Offline
There are two types of systems, online and offline. Online systems, or real time, have an interface for real time logging and allow data to be published as it becomes available. Offline systems have an interface to download data post use that must be converted to rosmsgs after use and joined with other data. Offline systems require extra attention to timestamps as joining the data without synced times will offset correlation with other logged data. Well documented start times, manually set time stamps, and unified times throughout system will help alleviate this problem.

On to [Setup]

Project Members:


Wiki: Setup