ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
2021-06-28 11:34:57 -0500 | received badge | ● Guru (source) |
2021-06-28 11:34:57 -0500 | received badge | ● Great Answer (source) |
2014-10-16 19:57:06 -0500 | received badge | ● Great Question (source) |
2013-06-12 04:36:29 -0500 | received badge | ● Taxonomist |
2013-04-28 22:14:11 -0500 | received badge | ● Famous Question (source) |
2013-03-02 21:48:04 -0500 | received badge | ● Enlightened (source) |
2013-01-28 07:17:15 -0500 | received badge | ● Famous Question (source) |
2013-01-27 07:26:18 -0500 | received badge | ● Good Answer (source) |
2013-01-26 04:47:04 -0500 | received badge | ● Nice Answer (source) |
2013-01-25 16:40:24 -0500 | received badge | ● Teacher (source) |
2013-01-25 09:37:00 -0500 | received badge | ● Editor (source) |
2013-01-25 09:30:33 -0500 | answered a question | Writing a Python node that publishes AND subscribes to topics of different message frequency An example might look like this (roughly): |
2013-01-25 09:25:23 -0500 | answered a question | Writing a Python node that publishes AND subscribes to topics of different message frequency import rospy from std_msgs.msg import Int32 class Echo(object): def __init__(self): self.value = 0 self.rate = 10.0 |
2012-12-08 12:22:44 -0500 | received badge | ● Notable Question (source) |
2012-12-06 15:33:23 -0500 | received badge | ● Popular Question (source) |
2012-12-06 02:53:39 -0500 | received badge | ● Good Question (source) |
2012-12-05 21:34:17 -0500 | received badge | ● Nice Question (source) |
2012-12-05 18:06:56 -0500 | asked a question | URDF with tool-changer Consider the application of a robot w/ tool changer that needs to update its URDF. I'd like to dynamically change the origin of a joint that connects an END_EFFECTOR link to a TOOL link. The approaches I can think of are: Model the joint as a FIXED joint My first approach was to model the joint as a fixed joint, and publish its transform to /tf myself. However robot_state_publisher continued to publish the transform described in the URDF, conflicting with the values I was publishing. I could patch robot_state_publisher, but I'd like to avoid modifying a standard library if possible. Then I tried taking the approach of parsing the robot_description rosparam, modifying its XML, and writing it back to the rosparam whenever the tool changed. I believe this is how the calibration stack handles adjusting fixed joints. But I don't think a change to the robot_description rosparam is propagated to robot_state_publisher at run-time unless I modify it to use dynamic_reconfigure, for example. Model the joint as a FLOATING joint I thought this could work and I could publish the transform to /tf directly without conflicting with robot_state_publisher. But in my Electric install the kdl_parser does not support 'FLOATING' type joints. It throws the warning "Converting unknown joint type into a fixed joint". After reading https://code.ros.org/trac/ros-pkg/ticket/4000 (this ticket) I'm very confused as to whether floating joints are supported at all. Model the joint as the sum of six REVOLUTE joints This is the approach suggested by Wim https://code.ros.org/gf/project/ros/mailman/?_forum_action=ForumMessageBrowse&thread_id=23468&action=ListThreads&mailman_id=20 (here). Then robot_state_publisher could be responsible for publishing to /tf, but it seems ugly. |
2012-12-03 12:37:55 -0500 | received badge | ● Notable Question (source) |
2012-12-02 20:49:45 -0500 | received badge | ● Supporter (source) |
2012-12-02 20:49:37 -0500 | commented answer | ROS Fuerte, rviz, NX on Amazon EC2 instance Thank you, good to hear it should be possible. I'll give it a try with standard X-forwarding to try and get to the root of the segfault. |
2012-12-02 10:13:41 -0500 | received badge | ● Popular Question (source) |
2012-12-02 00:07:59 -0500 | asked a question | ROS Fuerte, rviz, NX on Amazon EC2 instance Has anyone had any luck getting a Desktop-Full version of ROS up and running in the cloud? I commissioned an Ubuntu 12.04 EC2 instance, installed ROS Fuerte on it, and have been using x2go as a graphical interface to the remote machine. TurtleSim and rxgraph run fine, but rviz segfaults with the message: On the http://www.ros.org/wiki/rviz/Troubleshooting (rviz troubleshooting page) I see a reference to the fact that that running rviz remotely is not possible. I also wonder if NX clients such as x2go would even support a 3D-accelerated application like rviz. But it would be nice to run ROS Desktop in the cloud -- maybe even create an AMI for a one-click trial of ROS. Should I give up on that dream for now? |
2012-08-15 09:03:20 -0500 | received badge | ● Popular Question (source) |
2012-08-15 09:03:20 -0500 | received badge | ● Famous Question (source) |
2012-08-15 09:03:20 -0500 | received badge | ● Notable Question (source) |
2012-07-31 10:41:05 -0500 | commented question | "thin clients" communicating with ROS @JonMace, @ipso: I was nervous about the stability and maintenance of ROSBridge, but I was only aware of v1. v2 looks like it could do the trick. Exciting! |
2012-07-31 10:36:24 -0500 | commented question | "thin clients" communicating with ROS @Mac: I do have bare-bones ROS building on OS X, but it takes about an hour and requires various bits of troubleshooting to make it all the way through. If you have any shortcuts I'd be curious. |
2012-07-31 10:30:14 -0500 | received badge | ● Scholar (source) |
2012-07-27 11:11:25 -0500 | received badge | ● Student (source) |
2012-07-27 09:23:58 -0500 | asked a question | "thin clients" communicating with ROS One of my use-cases for ROS is that I'd like to have a 'thin client' on OS X that can communicate with our Ubuntu ROS master for some simple tasks: perhaps calling a service or querying a parameter from the parameter server. But the overhead of installing and configuring ROS on our OS X machine is too much, especially because we're trying to build a releasable binary that is pretty much drag-and-drop install on OS X. The first solution that comes to mind for me is a TCP server running in a ROS node on the Ubuntu machine that provides a limited interface to the ROS world for thin clients to call. Sort of like what ROSBridge tries to do for a web client. Do you know of any mature stacks that implement something like that? Is the idea of running a TCP server in a ROS node unpalatable / full of pitfalls? A sort of standardized interface to ROS for non-ROS clients seems like a common use case, but I don't have a great idea of the technical implications. |