mikepurvis's profile - activity

I would strongly prefer that chimera packages like plotjuggler do a find_package(catkin QUIET) check as proposed in this

If I understand your situation, it shouldn't be too hard to have a single .test file and single gtest binary, and then p

FWIW, add_rostest_gtest was added later as an optimization for this common case. The old way was to _always_ compile you

Use of add_rostest_gtest specifically assumes a 1:1 mapping of tests to gtest binaries, which is not the case for you. S

If I understand your situation, it shouldn't be too hard to have a single .test file and single gtest binary, and then p

If I understand your situation, it shouldn't be too hard to have a single .test file and single gtest binary, and then p

I have a ros-controls controller publishing a topic, and I'd like to remap that topic with a roslaunch <remap> tag. I tried applying the remap to both the controller spawner and the hardware interface node, and neither seemed to take.

Is there some other method required?

Is there a policy on this? It's a problem if the same package in different rosdistros install the same file.

Options:

• Install the file to a name like xyz-hydro.rules, so that there's no conflict.
• Create a non-distro package which installs the rules, that the distro packages can depend on.
• Don't install them; make it a manual step for the user to copy them from /opt/ros/hydro/share into the system location.
• Install to share, but provide a postinst script to copy/link to udev/rules.d

What's the process to add a non-distro package to packages.ros.org? Thoughts?

You did everything right. It's just the particular parameter file that that launch file depended on wasn't being install

This looks like an oversight in the upstream package. I've filed the following PR: https://github.com/cra-ros-pkg/robot

Currently waiting on several packages to be spidered for the wiki. For example, um6 and robot_upstart have both been in hydro/doc.yaml for almost three weeks with no wiki pages created. Have I not done something quite right?

Alternatively, if I just create the pages manually from the package template, will that create any problems down the road?

Thanks.

There are official armhf packages from OSRF for Ubuntu Xenial (ROS Kinetic). Is that what you mean? cf. http://wiki.ros

Headers like string and vector are part of the STL, which isn't included with the Arduino IDE by default. See this discu

I'm developing a rosserial node for reading some sensor values, and I was hoping to pull in a few parameters. There seems to be support in the code, and there's an old documentation page here (which isn't actually linked-to from the main documentation). This is my code:

void setup()
{
  nh.initNode();
  nh.advertise(pub);

  while(!nh.connected()) {
    nh.spinOnce();
  }

  nh.getParam("devices", device_counts, 3);
  nh.getParam("rate", &rate);
}

I consistently get Tried to publish before configured, topic id 6, which is the parameter-fetch magic topic. I'm using Electric on an Oneiric system, with the rosserial debs. (I'm aware that I haven't got default values in here; I've removed those blocks, for simplicity of presentation.)

Is parameter server support incomplete in rosserial?

The idea would be to pass dependency version information through as a flag and conditionally compile different code paths.

The specific scenario is having packages which depend on a package which I'm in the process of pushing several upstream changes to. In my local workspace, I'd like to build the package against my version of the dependency, but still have it build correctly on the buildfarm against the dependency's upstream (and then ideally switch over to the new code path when upstream merges my changes).

A perhaps better alternative would be using SFINAE tricks to detect if the specific methods I want to take advantage of are present in the class.

Is there an official recommendation for this type of situation?

AFAICT, using apt packages is a bit of an all-or-nothing deal— you can either:

1. install everything from apt, letting apt resolve dependencies, or

2. install everything from a rosinstall, letting rosinstall_generator resolve them.

The obvious thing for a mature package is to install the latest release from apt, and then use rosinstall to create an overlay which you can hack on. But this is not a great solution for packages which are not yet released, perhaps because they are still experimental, in early development, etc.

Am I mistaken here, or is there some ROS invocation which can scan the package.xml dependencies of a workspace, and then spit out (or execute) the necessary apt-get install command? Or is the solution to just create apt releases from the earliest possible point?

For future travellers, here are some cut and paste friendly versions of the incantation given below by @tfoote:

rosdep install --from-paths src --ignore-src --rosdistro=groovy -y
rosdep install --from-paths src --ignore-src --rosdistro=hydro -y
rosdep install --from-paths src --ignore-src --rosdistro=indigo -y
rosdep install --from-paths src --ignore-src --rosdistro=jade -y

Hey all,

I'm looking at building an rviz plugin which would display the state of OTTO's programmable LED strip. I'm pretty sure I don't want to create 300+ new pieces of single-colour geometry, so I'm wondering about the feasibility of supplying a single geometry for the strip as a whole, and then texturing it at runtime from a plugin.

I found some info on doing this in Ogre here: http://ogre3d.org/tikiwiki/Creating+d...

But I'm wanting to get a general sanity check on what the pitfalls are going to be with this approach. How possible is it to mix native Ogre calls in with rviz's geometry? Is there another plugin which demonstrates something like what I'm wanting to do here?