On 20/07/12 00:32, Dustin Gooding wrote:
> On 07/18/2012 06:41 PM, Felix Kaser wrote:
>> On 2012-07-18 19:54, Dustin Gooding wrote:
>>> Hi Felix,
>>>
>>> This looks like an interesting project.  We might be using it to meet a
>>> short-term goal.
>>>
>>> Where do you define how arbitrary data is displayed when it's published
>>> from logdata()?
>> Hi Dustin,
>>
>> what exactly is your short-term goal? I'm really interested in every
>> possible use case.
>>
>> The purpose of logdata was to publish more complex data. E.g. if you
>> want to publish a message which contains a couple of fields at once, you
>> can use logdata. There are no special widgets for it right now, but you
>> can add one widget per data field and connect each widget to a different
>> field in the message.
>>
>> Example:
>> Your message looks like this:
>> '''
>> float32 acceleration
>> int32 mode
>> string currentStatus
>> '''
>>
>> You can log this data with:
>> '''
>> #build data message
>> data = YourMessage()
>> data.acceleration = 3.7
>> data.mode = 5
>> data.currentStatus = 'running smoothly'
>>
>> #log message
>> rosdashboard.logdata('accelerationStatus', data, YourMessage)
>> '''
>>
>> To display the data you can either create your own widget (I'm still
>> working on that part) or add three widgets to the dashboard. You can
>> connect them to the published topic by setting the topic to
>> "/rosdashboard/accelerationStatus" and the datafield respectively to
>> "acceleration", "mode" or "currentStatus".
>>
>> Did that answer your question or only raise more questions? The process
>> still has some rough edges which I'm trying to find and smooth out.
>>
>> I've wikified the example with a screenshot here:
>> https://github.com/kaserf/rosdashboard/wiki/Publish-and-Display-Arbitrary-Data
>>
>>
>> Cheers
>> Felix
>>
> 
> Thanks for the extra help.  That cleared it up.  When you mentioned
> arbitrary data, I was considering serialized C++ objects and the like,
> but you meant arbitrary ROS messages.  My fault for misunderstanding.
> 
> Our specific use case is that we want to visually represent the
> health/status of our robot, both holistically and on a per-joint,
> per-status-bit level.  Until your post, we were considering hijacking
> the DiagnosticStatus message, but it's all strings and doesn't lend
> itself to plotting or "gadgeting".  But, given you're work on the
> display side, we can design a message that holds the data we want to
> visualize and then use rosdashboard to see it. Specific data for each
> joint to display includes: motor enabled (bool), brakes set (bool), mode
> (int/string), faulted (bool), specific fault (string), and a few
> others.   On the flip side, at some point it would be great if we could
> also command from rosdashboard: enable motor, set brakes, change mode,
> clear faults, safe the robot, etc.
There is a long term plan to support publisher widgets as well. See
issue #3: https://github.com/kaserf/rosdashboard/issues/3
> 
> Given a complex set of data like this, that "add save and restore
> functionality" issue is pretty important.
Yes. The only reason I did not implement save and restore yet is because
I am planning to integrate rosdashboard as plugin into rqt/rosgui and I
could implement the save and restore functionality which is already part
of the plugin interface.

Cheers
Felix
> 
> Thanks,
> -dustin
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>