[ros-users] ROS Clients that work out of the box without ROS .msg, .srv, and .action pre-compilation

Aaron Schiffman aarondsc at yahoo.com
Wed Jan 7 22:15:30 UTC 2015


Hi Tim,
Those performance metrics are great! Are they based on an actual connection to a ROSNode? Or was the performance tested on a high performance mach ROSNode? The clients will only perform as fast as the weakest link, therefore if the ROSNode is performing poorly, you may never know the potential of your ROS Client.
My custom loggers aren't actually custom at all, they are an implementation of rosbag. The Java based Autonomous Robotics Framework I've been working on contains a SensorProcessorManager, that incoming messages are sent to. The framework architecture includes the requirement to proxy specific Sensors (or in ROS Speak - Topics, Services, Actions) from incoming RCSM (Robot Control System Messenger) Plugins (of which ROS Client is an RCSM plugin). The Perception Engine contains the SensorProcessorManager, and by default a Hardware Event Control Manager, that calls an InstructionManager to obtain Instruction Objects that are reused via Object Pools for each Hardware Sensor, if one does not exist, one will be autogenerated on the fly Input/Output Handler classes, and a Native Instruction Object. Android can use a web service to compile new Instruction Objects remotely via our web service, and then download the new Instruction Objects. Incoming data messages are migrated from binary to Instruction Objects, and passed on for handling via perception engine in the first Sensor Processor, and ROSBag recording of specified topics services is via the second synchronously called Sensor Processor. The same process is implemented on outgoing messages via my Frameworks Movement Processor Manager.
ROSBag made sense for recording because ROSBag Playback tools can be used in simulation on any implementation, and It can be used without any modifications to record all incoming messages regardless of whether they are from ROS, or another RCSM Provider.
As for where to record ROSBag files to, it doesn't matter in the framework I am using, because its flexible enough to write a ROSBag to a local file, a web service like Dropbox, Google Drive, any JDBC compliant SQL DB, or MongoDB with a minor amount of code. Currently, the dev plugin implementation is writing to file, but its so huge, it may be a network location, bandwidth permitting.
The reason to use custom logging? Flexibility is necessary, when you are implementing a robotic system that can plugin to any robot for AI out of the box, with a long term goal of self replicating, repairing, mining, farming, manufacturing complex humanoid robots. Sounds crazy, huh?
Thanks,

Aaron
 

     On Wednesday, January 7, 2015 1:52 AM, Tim Niemueller <niemueller at kbsg.rwth-aachen.de> wrote:
   

 Am 06.01.2015 um 22:37 schrieb Aaron Schiffman:
> Hi Tim,
> 
> We are doing
> data logging with a custom rosbag recorder implementation in Java, that writes to an outputstream.

Hi Aaron.

Can you give some hints why you want to have a custom logger? If it is
about making the data structures available and query-able, you might
want to check out mongodb_log [1, 2], maybe it already does what you
intend to do (it's fast and provides powerful query capabilities). If it
is really just about recording the binary (encoded) message flow, what
would your method provide over rosbag?

Back in the days I did some simple benchmarks in particular regarding
decoding performance of messages in C++, Lua, and Python. The results
are on http://timn.github.io/roslua/ and the code used at
https://github.com/timn/ros-actionlib_benchmark. Maybe you want to
compare these to Java decoding performance. It turns out that this very
step is often what limits you the most for large-scale logging,
especially when you want to store the data in a query-able format
(because you often have many small messages which are hierarchically
structured and thus expensive to decode CPU-wise, rather than blobs you
could decode quicker which would actually be limited by available I/O
bandwidth).

The data was recorded back in 2010 with Diamondback or Electric I guess,
so things might have changed. Back then rosbag also had the bug of
storing the message definition verbatim for each and every message
(resulting in the enormous compression rates one could achieve on bag
files and bad I/O performance, don't know if that has been fixed in the
meantime, presented my findings at OSRF in 2013).

  Tim

[1] http://www.fawkesrobotics.org/projects/mongodb-log/
[2] http://wiki.ros.org/mongodb_log

-- 
KBSG - Knowledge-Based Systems Group            AllemaniACs RoboCup Team
========================================================================
http://robocup.rwth-aachen.de                     RWTH Aachen University
http://kbsg.rwth-aachen.de                               Ahornstrasse 55
http://www.fawkesrobotics.org                             D-52056 Aachen


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20150107/1e22c688/attachment.html>


More information about the ros-users mailing list