Recent changes to Home

Home modified by brandon shrewsbury

brandon shrewsbury — Thu, 29 Aug 2013 05:55:55 -0000

--- v18
+++ v19
@@ -15,7 +15,6 @@

 On to [Setup]

-The wiki uses [Markdown](/p/respondr/wiki/markdown_syntax/) syntax.

 [[members limit=20]]
 [[download_button]]

Home modified by brandon shrewsbury

brandon shrewsbury — Thu, 29 Aug 2013 05:55:35 -0000

--- v17
+++ v18
@@ -2,18 +2,15 @@
 ==========
 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.

-Logging
------------------
+**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
----------------------
+**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
--------------------------
+**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]

Home modified by brandon shrewsbury

brandon shrewsbury — Thu, 29 Aug 2013 05:55:07 -0000

--- v16
+++ v17
@@ -1,15 +1,19 @@
-**RESPOND-R framework**
+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.

-**Logging**
+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**
+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**
+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]

Home modified by brandon shrewsbury

brandon shrewsbury — Thu, 29 Aug 2013 03:59:39 -0000

--- v15
+++ v16
@@ -12,43 +12,7 @@
 **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.

-**Setup**
-The RESPOND-R system is based on existing packages in ROS. You will need to install and configure ROS for each piece of equipment you want to log (Unless they can be joined) and on a standalone machine for centralized logging. We are using Groovy.
-
-Installing ROS: http://www.ros.org/wiki/ROS/Installation
-Configuring the environment: http://www.ros.org/wiki/ROS/Tutorials/InstallingandConfiguringROSEnvironment
-Source your catkin workspace automatically: 
-
-> echo "source ~/catkin_ws/devel/setup.sh" >> ~/.bashrc
-
-
-
-Install Master Fkie - http://www.ros.org/wiki/multimaster_fkie
-
->sudo apt-get install ros-groovy-master-discovery-fkie
-
-
-this will install the MSGS and the sync node
-
-**Create the interface between the logger and the equipment**
-Each cyber physical system (CPS) must have an interface to gather equipment data either in real time or post event. We have provided 3 templates to gather data. A real time template for gathering data over a socket, an offline template for converting CSV data, and a video template for capturing network streams.
-
-[Real Time Socket Template]
-[Offline CSV Template]
-[Video Stream Template]
-
-**Creating a startup file for Real Time Collection**
-Under special circumstances, software may need to be launched outside of ROS, so a .sh template is provided for running the nodes required to gather the data. [Startup Template]
-Roscore must be launched either via roslaunch or manually.
-Rosbag must be set to record, preferably excluding duplicate video streams
-The telemetry node must be launched if available
-The video node must be launched if available
-The fkie zeroconf discovery node must be launched for centralized logging
-
-**Configuring the Centralized Server**
-A single machine can collect data from multiple masters using fkie multimaster's master_sync node. Each logger must be on the same network as the centralized logging hub, and each logger must be running the fkie master_discovery zeroconf node. [RESPOND-R Tactical Server]
-
-Configure the centralized logger just as you would any other logger, but instead of running a telemetry and video node, run the fkie multimaster's master_sync node. Because this machine will be collecting data from each system, more drive space will be required. Once a master is found using the discovery node, the sync will collect messages and post them to the ROS blackboard. Rosbag will store the synced topics in a centralized location and allow synced multirobot replay for analysis and review. In order to view this data it is important to build the rosmsgs associated with each logged system.
+On to [Setup]

 The wiki uses [Markdown](/p/respondr/wiki/markdown_syntax/) syntax.

Home modified by brandon shrewsbury

brandon shrewsbury — Thu, 29 Aug 2013 03:59:08 -0000

--- v14
+++ v15
@@ -1,8 +1,13 @@
 **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.

+**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 log centralized if the bandwidth and network paths are available.  Local logging is simply recording all data using rosbag on the local master. If you have the ability to flip data to another master that can collect data from multiple systems, record there as well. This allows for both a more complete picture of theatre as well as redundant backups. This will also allow for less compilation during post event data joins.
+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.
@@ -13,16 +18,15 @@
 Installing ROS: http://www.ros.org/wiki/ROS/Installation
 Configuring the environment: http://www.ros.org/wiki/ROS/Tutorials/InstallingandConfiguringROSEnvironment
 Source your catkin workspace automatically: 
-~~~~~~
+
+> echo "source ~/catkin_ws/devel/setup.sh" >> ~/.bashrc

-echo "source ~/catkin_ws/devel/setup.sh" >> ~/.bashrc
-~~~~~~
+
 Install Master Fkie - http://www.ros.org/wiki/multimaster_fkie
-~~~~~~

-sudo apt-get install ros-groovy-master-discovery-fkie
-~~~~~~
+>sudo apt-get install ros-groovy-master-discovery-fkie
+

 this will install the MSGS and the sync node

Home modified by brandon shrewsbury

brandon shrewsbury — Thu, 29 Aug 2013 03:33:45 -0000

--- v13
+++ v14
@@ -12,10 +12,17 @@

 Installing ROS: http://www.ros.org/wiki/ROS/Installation
 Configuring the environment: http://www.ros.org/wiki/ROS/Tutorials/InstallingandConfiguringROSEnvironment
-Source your catkin workspace automatically: echo "source ~/catkin_ws/devel/setup.sh" >> ~/.bashrc
+Source your catkin workspace automatically: 
+~~~~~~
+
+
+echo "source ~/catkin_ws/devel/setup.sh" >> ~/.bashrc
+~~~~~~
 Install Master Fkie - http://www.ros.org/wiki/multimaster_fkie
+~~~~~~

-> sudo apt-get install ros-groovy-master-discovery-fkie
+sudo apt-get install ros-groovy-master-discovery-fkie
+~~~~~~

 this will install the MSGS and the sync node

Home modified by brandon shrewsbury

brandon shrewsbury — Thu, 29 Aug 2013 03:31:55 -0000

--- v12
+++ v13
@@ -8,7 +8,7 @@
 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.

 **Setup**
-The RESPOND-R system is based on existing packages in ROS. You will need to install and configure ROS for each piece of equipment you want to log (Unless they can be joined) and on a centralized machine before continuing. We are using Groovy.
+The RESPOND-R system is based on existing packages in ROS. You will need to install and configure ROS for each piece of equipment you want to log (Unless they can be joined) and on a standalone machine for centralized logging. We are using Groovy.

 Installing ROS: http://www.ros.org/wiki/ROS/Installation
 Configuring the environment: http://www.ros.org/wiki/ROS/Tutorials/InstallingandConfiguringROSEnvironment

Home modified by brandon shrewsbury

brandon shrewsbury — Wed, 28 Aug 2013 17:35:54 -0000

--- v11
+++ v12
@@ -35,9 +35,9 @@
 The fkie zeroconf discovery node must be launched for centralized logging

 **Configuring the Centralized Server**
-A single machine can collect data from multiple masters using fkie multimaster's master_sync node. Each logger must be on the same network as the centralized logging hub, and each logger must be running the fkie master_discovery zeroconf node. 
+A single machine can collect data from multiple masters using fkie multimaster's master_sync node. Each logger must be on the same network as the centralized logging hub, and each logger must be running the fkie master_discovery zeroconf node. [RESPOND-R Tactical Server]

-Configure the centralized logger just as you would any other logger, but instead of running a telemetry and video node, run the fkie multimaster's master_sync node. Once a master is found using the discovery node, the sync will collect messages and post them to the ROS blackboard. Rosbag will store the synced topics in a centralized location and allow synced multirobot replay for analysis and review. In order to view this data it is important to build the rosmsgs associated with each logged system.
+Configure the centralized logger just as you would any other logger, but instead of running a telemetry and video node, run the fkie multimaster's master_sync node. Because this machine will be collecting data from each system, more drive space will be required. Once a master is found using the discovery node, the sync will collect messages and post them to the ROS blackboard. Rosbag will store the synced topics in a centralized location and allow synced multirobot replay for analysis and review. In order to view this data it is important to build the rosmsgs associated with each logged system.

 The wiki uses [Markdown](/p/respondr/wiki/markdown_syntax/) syntax.

Home modified by brandon shrewsbury

brandon shrewsbury — Wed, 28 Aug 2013 17:25:48 -0000

--- v10
+++ v11
@@ -15,9 +15,9 @@
 Source your catkin workspace automatically: echo "source ~/catkin_ws/devel/setup.sh" >> ~/.bashrc
 Install Master Fkie - http://www.ros.org/wiki/multimaster_fkie

-> sudo apt-get install ros-groovy-multimaster-fkie
+> sudo apt-get install ros-groovy-master-discovery-fkie

-
+this will install the MSGS and the sync node

 **Create the interface between the logger and the equipment**
 Each cyber physical system (CPS) must have an interface to gather equipment data either in real time or post event. We have provided 3 templates to gather data. A real time template for gathering data over a socket, an offline template for converting CSV data, and a video template for capturing network streams.

Home modified by brandon shrewsbury

brandon shrewsbury — Wed, 28 Aug 2013 16:13:31 -0000

--- v9
+++ v10
@@ -34,7 +34,10 @@
 The video node must be launched if available
 The fkie zeroconf discovery node must be launched for centralized logging

+**Configuring the Centralized Server**
+A single machine can collect data from multiple masters using fkie multimaster's master_sync node. Each logger must be on the same network as the centralized logging hub, and each logger must be running the fkie master_discovery zeroconf node. 

+Configure the centralized logger just as you would any other logger, but instead of running a telemetry and video node, run the fkie multimaster's master_sync node. Once a master is found using the discovery node, the sync will collect messages and post them to the ROS blackboard. Rosbag will store the synced topics in a centralized location and allow synced multirobot replay for analysis and review. In order to view this data it is important to build the rosmsgs associated with each logged system.

 The wiki uses [Markdown](/p/respondr/wiki/markdown_syntax/) syntax.