danep's profile - activity

I believe I used protocol buffers to handle the memory alignment issues. Unfortunately I haven't used this library in years so I can't be more specific. See my answer here: http://answers.ros.org/question/58388...

Sorry, the forum mangled the link: https://github.com/danepowell/omni_im If this doesn't work, just copy and paste the text of the link into your browser.

I created a package allowing you to control interactive markers with the Phantom Omni, maybe it will help you: https://github.com/danepowell/omni_im

I've found some bugs in the gazebo package for Groovy and would like to fix them. Currently, gazebo is installed via the ros-groovy-simulator-gazebo Debian package. My question is, what's the best practice for setting up a development environment to hack on Gazebo?

The problem is that Gazebo is a dependency of dozens (hundreds?) of other ROS packages, so I can't simply uninstall it and compile it from source. Should I use equivs to create a dummy package for Gazebo, and then compile it from source, or is it possible to have side-by-side installations of the source and packaged versions?

I was always taught that code should be strictly organized into header and source files, with the declaration in headers and actual implementation in cpp source files (or compiled into object libraries.)

I'm working with the rosserial_client package. A lot of the code (e.g. node_handle.h) is contained entirely in the header files, and the tutorials for the package even suggest writing new implementations entirely in header files.

I'm no C++ expert, so I'm not saying this is wrong :) I'm just trying to learn best practices, so I'd like to understand why so much code is organized this way. Is it just lazy/quick coding, or is there a method to the madness?

I am trying to implement rosserial on a new platform (STM32F0-Discovery board, which has a Cortex-M0 processor and is quite a bit more powerful than the Arduino, so I think it should be possible).

I've created a simple 'hello world' program, based on the hello world example for rosserial_arduino, which simply publishes the std_msgs::String 'hello world'.

I can upload and run the example on the board, and it receives data over the serial port. Unfortunately, once I run serial_node.py on my host, the board throws an exception (hard fault) in TopicInfo.h at line 42:

memcpy(outbuffer + offset, this->message_type, *length_message_type);

The values of the variables there look a little odd to me, but I'm not exactly sure what they should look like. offset seems correct (13, which matches 'std_msgs::String'). message_type seems corrupted though- it's a jumble of characters with elements of 'std_msgs' and 'String' embedded in it. I'm not sure if that indicates actual corruption, or if the debugger just isn't interpreting it correctly.

I'm really at a loss- any advice would be appreciated!

Interactive markers (and rviz in general) seem to be designed completely around mouse-based control (using the handleMouseEvent callback). I am interested in instead using a Novint Falcon, Microsoft Kinect, or similar 3D interaction device to select and manipulate interactive markers in rviz.

I'm not quite sure how to approach this project. My first idea was to override all of the classes that implement handleMouseEvent and write a 'handleJoystickEvent' callback. However, I'm not sure how to actually call handleJoystickEvent, or whether this is even the right approach in general.

I would really appreciate any advice on how to proceed. Note that this doesn't have to be a very 'general' solution at first- it can be hardcoded to support only a single type of device.

I thought about that, but it was too ugly to seriously consider :) I guess I'll just resort to hacking the other package's config file, and maintaining a vendor branch. It would be nice if there were a Better Way in the future...

I'm writing a package that is meant to be run after a 3rd-party package starts Rviz. My package simply provides a new display type, and some topics for that display type to subscribe to.

Currently, I have to launch the 3rd-party package, then launch my package, then manually add and configure the display type to Rviz. It would be nice if in the launch file for my package I could automatically add and configure the display.

Is this at all possible? I don't think Rviz exposes any services for this, or allows you to 'force' it to reload a custom config file, so I don't know how this would be possible.

Sorry, I don't have the text of the error message. But omni_description has very few dependencies so you could easily download it and build the pre- and post-commit versions to see the error message and resolution for yourself.

Woohoo! Alright, I've got a new tool that behaves just like InteractionTool. I'll work on using focused_object_ like you suggested.

I guess that makes sense. However, when I try to create a derived class with InteractionTool as the base class, the plugin doesn't show up in Rviz. rospack plugins --attrib=plugin rviz does show it. Any ideas? See here

It seems the 'brute force' answer would be to clone the rviz::InteractionTool, and have it also send mouse events to my plugin. It's just not ideal, since it requires users to select a different tool in Rviz, and it also means duplicating and tracking upstream code.

I'm writing an Rviz plugin that lets users control the most-recently touched interactive marker with a 3d mouse or haptic device. I'm trying to learn the Rviz / Ogre architecture as I go, so please bear with me.

The only problem I have is how to 'capture' the event where an interactive marker is selected. From within my plugin, I want to know when an interactive marker is clicked with the mouse, and then store the pointer to that marker so I can send events to it later.

I'm beginning to wonder if this is even possible. It seems that when the user clicks a marker, processMouseEvent() and handleMouseEvent() is fired through the chain of interaction_tool and interactive_marker_control. I'm not sure how an external plugin could hook into this to capture the marker.

Do you have any suggestions?

(note: originally posted at https://github.com/ros-visualization/rviz/issues/670)

EDIT: To clarify, based on responses in the Github issue- I want users to still be able to interact with the markers using the mouse. Whichever marker they clicked on most recently, I want to store as a pointer in my own plugin. I'll then call handle3DCursorEvent() on the marker to control it using the 3d device. My problem is just initially capturing and storing the pointer to the marker.