thebyohazard's profile - activity

When a launch file is launched on a remote machine, is anything different about that remote process? The tag allows you to set the user, so I would assume the groups and permissions are the same on the remote machine? But this does not match my experience. Does anything make the launch different than launching directly on the machine?

Case:

• I have an executable to operate some hardware that was given by the manufacturer. They did not provide a library.
• Since they did not provide a library, I am only able to execute the program on the command line or through system calls in my code. I have a node that executes the system call.
• If I run the node or execute the command line program on Machine A as user x, everything works fine. If I run the node or execute the command line program on Machine B as user x, everything works fine.
• However, if I remote launch the node on machine B from machine A, the program will not work on machine B. Both the user on machine A launching the launch file is user x and the user attribute in the machine tag is user x.

The program output is unhelpful.

launch file:

<launch>    
    <machine  name="machineB" address="machineB" default="true" env-loader="/home/x/ros_ws/devel/remoteEnv.sh" user="x"/>

    <node name="mynode" pkg="mynode" type="mynode" respawn="true"/>    
</launch>

remoteEnv.sh on machineB:

#!/usr/bin/env bash

source /home/x/ros_ws/devel/setup.bash
export ROSCONSOLE_FORMAT='${time}[${severity}] ${node}/${logger}: ${message}'
export ROS_IP=192.168.1.123
export ROS_MASTER_URI=http://machineA:11311
export ROS_NAMESPACE=machineB

exec "$@"

One thing that is different is that the process has no associated tty. I noticed that when I ran my launch file in a s

remote launch permissions When a launch file is launched on a remote machine, is anything different about that remote pr

remote launch permissions When a launch file is launched on a remote machine, is anything different about that remote pr

I'm not sure it's possible as it's written. The code in question imbues a stringstream with the C locale: boost::posix_

I have set up my shells to have a custom ROSCONSOLE_FORMAT

export ROSCONSOLE_FORMAT='${time:%T.%f}[${severity}] ${node}/${logger}: ${message}'

When I run or launch nodes, they have the desired format:

22:45:20.180207[ INFO] /test_node/ros.test: Test node message

However, if I use the rosconsole command line utility,

rosconsole echo -l info

I get the default format that does not have the time in it:

[ INFO  ] [/test_node]: Test node message

How do I make the output of the rosconsole command line utility show in the desired format?

I know I can pass option -v to show verbose messages, but I don't want all of that. Honestly, I am having trouble finding documentation for the command line utility. Everything I search for brings me to the library and it's not on the wiki's utility page.

rosconsole command line utility not honoring ROSCONSOLE_FORMAT I have set up my shells to have a custom ROSCONSOLE_FORMA

ROSCONSOLE_FORMAT time zone I am using the new feature as of noetic in rosconsole where you can format the time accordin

ROSCONSOLE_FORMAT time zone I am using the new feature as of noetic in rosconsole where you can format the time accordin

Is there any way to pass a list of strings as an argument in a launch file? Something like

<launch>
  <arg name="source_list" default="[a_topic,a_second_topic]"/>
  <node>
     <param name="source_list" value="$(arg source_list)"/>
  </node>
</launch>

I'm confused about how to implement cancelling in action servers. I'm under the impression that I'll need an ActionServer rather than a SimpleActionServer, but I'm hoping I'm wrong.

The actionlib detailed description page says that cancel request is a client action rather than a server action. It also shows a cancel request as the only way to transition to the preempting or recalling states. Yet the SimpleActionServer can recall goals upon receipt of a new goal. Is it just interpreting new goals as cancel requests and cancelling its own goals, or is a SimpleActionClient also sending a cancel message along with a new goal? Must I use a SimpleActionServer with a SimpleActionClient or could I have a specialized regular ActionServer with a SimpleActionClient?

Here's why I'm asking: I'm designing an action server. The client must be able to cancel active goals. However, no newly received goal should replace an active goal; instead the server should reject them. I'll need a special callback for cancelling goals where I stop motors and whatnot.

Thanks for your help.

In my understanding, nodes can get initialization arguments in two ways:

1. rosrun or roslaunch xml files can pass command line arguments straight to the main method
2. the node can use the ros parameter server to get parameters that have been loaded by rosparam or roslaunch loading a yaml config file.

Are there any benefits to one over the other? Perhaps in terms of performance (I plan to use ROS on embedded devices), flexibility, or some other way I'm not thinking of? Or is there a best practice?

I see a clear case for yaml in the case of things like motor parameters, since you may want to tweak them while the node is running and save the value you ended up with for subsequent runs.

But what about a parameter that will not change during execution such as a parameter that specifies whether a node is left or right handed?

Or what about parameters that are not always used? For example, a node type could be 'tcp' or 'serial.' It then either needs an IP address or a port, but not both.

I'm using xacro's new ability to load a yaml file into a property in order to update a URDF with new calibration data.

The file in the example is local. Is there any way to hook this up to rospack so I can include this xacro file in another one? I tried an inner $( ) but it didn't work.

I am using the perception_pcl nodelets. I have a point cloud being fed to a SACSegmentation nodelet. That nodelet works fine and I am able to see the output at the expected 30Hz.

However, when I feed the inliers from the segmenter and the original point cloud into a pcl/ExtractIndices nodelet, I get no output, or perhaps one frame randomly every 1 - 2 minutes.

This appears to be caused by some recent update as it has worked before and still works on another, unupdated computer. Has there been a change of this node or the way to use it or should I file a ticket?

EDIT: I dug a little deeper and found out the cause of my problem. The extractIndices filter uses a Synchronize message filter with an exact timestamp policy to match the input point cloud and the indices found by the segmenter. The segmenter is NOT producing an inlier message with the same timestamp as the original pointcloud on my updated computers. Therefore, the extractIndices callback never gets called. The original point cloud has a stamp that is more precise than the indices.

For example, the pointcloud will have a stamp of

secs: 1438114448
nsecs: 434060100

while the indices will have

secs: 1438114448
nsecs: 434060000

So the segmentation nodelet loses precision when it reads the input point cloud. Not so in my unchanged computer. I noticed the segmenter uses a pointcloud rather than a pointcloud2, but I still can't find the place where things changed to cause my error. Anybody know where the change was?

ROS2: How to tell service clients that a provided service cannot be executed? Back in ROS1, when a node provided a servi

I didn't find this question before I asked my duplicate question, but after digging and finding it impossible, I have cr

The transition from active to error processing does not exist in the current lifecycle state machine, so as it is, this

I am experimenting with giving one of my nodes a lifecycle:

From the ROS 2 node lifecycle design document in regards to the management interface of lifecycle nodes:

It is expected that a common pattern will be to have a container class which loads a managed node implementation from a library and through a plugin architecture automatically exposes the required management interface via methods and the container is not subject to the lifecycle management. ... These services may also be provided via attributes and method calls (for local management) in addition to being exposed ROS messages and topics/services (for remote management).

Also from the design document, in the section after the above in regards to transitioning among the lifecycle states:

Most state transitions are expected to be coordinated by an external management tool which will provide the node with its configuration and start it. The external management tool is also expected monitor it and execute recovery behaviors in case of failures. ... And a node could be configured to self manage, however this is discouraged as this will interfere with external logic trying to manage the node via the interface.

There is one transition expected to originate locally, which is the ERROR transition.

So the lifecycle command line utilities and lifecycle rqt plugins would be examples of external management tools referenced. I would also classify the python launch files that control the lifecycle to be external tools (that could fight with the command line/rqt tools since the python launch files will be automatic). But even if it's discouraged, I think my node will need to self-transition. Maybe a container class like the one referenced could do the self transitioning I require, though I'm not sure. So...

Are there any examples of lifecycle nodes self-transitioning with the ERROR transition or examples of container classes that orchestrate lifecycle transitions of loaded node implementations? I can find the lifecycle code and demos for rclcpp_lifecycle, but no nice documented API page.

Thanks!