vschmidt's profile - activity

There's an interesting side effect of this script. The resulting merged bag is much larger than the sum of the two origi

This should totally be in the ros_bag utility. Awesome!

I built on the answer above and added a run script that sets the ROS_MASTER_URI and sources the ROS environment. It has

Hello, I'm trying to learn how to properly set up a standard ROS navigation and control stack to drive a field robot (one that operates outdoors, navigating primarily by GPS and possibly a compass). My own previous experience with other systems keeps getting in the way and so I have some questions about how this is meant to work.

1) This system is not a wheeled system, (it's a boat) and so there's not a direct measure of "odometry", which move_base seems to require. Even with speed measured by the GPS and heading measured by a separate compass, the combination don't typically reflect the actual movement of the vessel, since the vessel's direction of travel rarely matches it's heading. The speed from the GPS is course made good, not speed in the vessel's reference frame. My questions is, how should one best set this up?

2) I understand the canonical output from move_base (from the local_planner specifically) is the Twist message, containing linear and angular velocity information. Having been told the robot's position, given a local cost map and a goal, the local planner calculates the optimal velocity message for the vehicle. What is confusing to me is that the output of all this. What the robot needs (it seems to me) is a direction to travel and a speed at which to go. But a Twist message outputs not a desired direction of travel, but the angular velocity or the change in direction of travel. It seems to me move_base is acting like a controller (think PID controller) on some level by not specifying the desired direction of travel directly. Do I understand this correct?

3) Finally, ros_control can implement a PID (or other) controller to adjust the speed of motors (or maybe maneuver a rudder on a boat) to match the desired setpoint. But in this case, it is matching a heading rate, not a heading directly. Is this not backwards? Shouldn't the output of the local_planner be a desired heading and since the motors, driving wheels or a rudder, actually change the heading rate directly, a PID controller in ros_control would then take adjust the heading rate to achieve the desired heading published by the local planner?

I hope this all makes some sense. I can't help but feel like the roles of the local_planner and ros_control are reversed in some sense (at least with respect to the desired direction of travel).

Thanks for your thoughts, in advance. Val

tf2 Documentation Needs Work As we get ramped up on our own ROS environment, we've found the tf2 implementation extremel

This discussion seems to revolve around where the existing documentation can be found. But it doesn’t, in my opinion rea

This answer was some time ago, but is this not incorrect? PEP 103 specifies that yaw measured from the x-axis (i.e. in

Rosbridge is probably the better answer, but just in case, here's a method that will at least work on messages whose con

I have a 3rd party gadget whose ROS interface is compiled against an older version of ROS.

I'm curious, to what extent is it possible to intermix clients and ROS Master from different distributions. Is there any compatibility between them?

Thanks, Val

Hello, I'm (perhaps foolishly) integrating a Kinetic ROS install with a third-party package whose implementation is built on Indigo.

In initial tests with clients built on Kinetic I've been able to read every message published by nodes built on Indigo.

However I am unable to subscribe to and read messages published by nodes built on Kinetic by clients built on Indigo.

Can anyone verify for me, is this a fool's errand? Is ros_comm as built in Indigo sufficiently different that is not fully compatible with Kinetic. There is precious little documentation regarding the compatibility between ROS versions so it is hard to tell without testing.

Thanks!

I discovered my problem here. I did not realize that ROS requires fully resolvable host-names in addition to routable ip

Thanks for reminding me that I'd asked the question. Must be frustrating. :) Now I'm actually trying it. I'm defining th

Indigo and Kinetic Compatibility Hello, I'm (perhaps foolishly) integrating a Kinetic ROS install with a third-party pa

I'm trying to use the nmea_msgs/Sentence message and I'm stumped on what is probably a python problem.

I've built the package and I can see the results in devel/

$ ls ~/catkin_ws/devel/lib/python2.7/dist-packages/nmea_msgs/msg
__init__.py  __init__.pyc  _Sentence.py  _Sentence.pyc

And it shows up fine with rosmsg:

$ rosmsg show nmea_msgs/Sentence
std_msgs/Header header
  uint32 seq
  time stamp
  string frame_id
string sentence

But if I source devel/setup.bash and then run ipython, and then import the module I don't actually get a proper Sentence class. For example:

In [1]: from nmea_msgs.msg import Sentence
In [2]: a = Sentence
In [3]: print a.header
<member 'header' of 'Sentence' objects>

Although there is a "header" object, it is not a "Header" object in the sense of a ROS message definition. That is, it has none of the attributes of 'stamp', 'seq' and 'frame_id' for the Header message.

I cannot figure out why.

-Val

I found the problem!!! I should have defined the message in iPython like this: a = Sentence() Thanks!

Sentence.msg Header Missing I'm trying to use the nmea_msgs/Sentence message and I'm stumped on what is probably a pytho

Hello,

I have a series of questions about REP-105 and the robot_localization package.

What is confusing to me is the utility of the odom reference frame and it is possible that I don't understand its definition. REP-105 describes the odom reference frame as a world-fixed reference frame. But it also says that the pose of a robot can drift in the odom reference frame without any bounds.

I understand the problem. A vehicle whose position is estimated from dead-reckoning alone will accrue position estimate errors that will grow unbounded unless checked by an absolute position measurement.

So is the idea that one can track the dead-reckoned position estimate and the error between that and the true position separately? Perhaps this is done in the transform between the map frame and the odom frame?

What is the utility of the odom reference frame vs the map reference frame? Why is having a continuous "no-jumps" reference frame better than having a globally accurate one? If one is using an EKF and there are jumps in the positioning due to GPS data, does that not mean that the measurement covariance (or possibly the process covariance) are not set properly? It seems to me one is relying on the GPS too much. Maybe it means the IMU is too poor quality to adequately filter the GPS? I guess what I'm getting at is that it seems to me that a properly modeled and tuned EKF should (barring resets) not have jumps and the odom frame might be unnecessary.

I can't wait to hear your thoughts!