sglaser's profile - activity

Hi Robert. None of these controllers will work with floating joints. I'm not sure how to do what you'd like to do, but hopefully someone else will.

The controller commands effort on the the joint, and the transmission translates them into effort on the actuator.

Is this joint connected to any actuators?

Given two consecutive joint angles a and b, if b > a, the controller will move in the positive direction, and if b < a it will move in the negative direction. It does not normalize the angles, nor does it choose the shorter angular distance to travel.

This interpretation allows you to command trajectories that move joints through more than 180 degrees, which would be impossible if the controller normalized angles or picked the direction implicitly.

To get the behavior you want, you should "denormalize" the joint angles of your trajectory before sending it to the controller.

The controllers apply effort to the joints.

The transmissions transform state from actuator space to joint space (and efforts from joint space to actuator space). The robot is simulated in joint space, so in simulation, the efforts are immediately transformed back into joint space (and the state is first transformed from joint space), as shown in this diagram.

In simulation, the mechanicalReduction and motorTorqueConstant are immediately applied and unapplied, so changing them will have no effect on the simulation. They only change the reported values of the actuators.

For #1, does this happen for the first point in your trajectory, or only for intermediate points?

Hi sam,

The mm_teleop package does not already exist--it is the package that you create and place the Python scripts into. (Of course, you can call it anything you want).

I don't think rxgraph allows you to move nodes around (though that would be a welcome contribution). If you can't see all the nodes, you can left-click and drag the window around to pan and use the mouse scroll wheel to zoom.

Recording the point cloud from the Kinect requires more bandwidth than your average hard drive provides.

The Kinect produces an XYZRGB point cloud with around 300k points, where each point takes 32 bytes. At 30Hz, that produces about 281 Mb / second. Your average hard disk only supports 100-200 Mb/sec, so the Kinect point cloud just cannot be written quickly enough.

Ivan's solution is correct: You should write the raw disparity and rgb images to disk and only expand them to point clouds during playback.

Hi Dimitar,

I just started on something called rxlaunch, which does exactly that. It's still in active development, but may already be useful to you.

You can get rxlaunch from its kforge page. Just checkout the mercurial repository and run rxlaunch.py. You may also need to install PySide.

Some things that don't work yet (2011-07-14):

• It doesn't load parameters, so you should roslaunch the launch file first, then use rxlaunch (fixed 2011-07-14)
• Everything is launched locally
• It's hard-coded to use the master at http://localhost:11311

When things go wrong, just file a ticket.

Hi Brice,

You've described two extremes of designing ROS systems: break it into tiny pieces with many communication channels, or pack everything into one monolithic process. I can't give you the right answer; it depends on your specific needs and without experimenting there are too many unanswered questions. However, I will try to give some suggestions for designing the system you've described.

You asked how quickly ROS can run. I have seen ROS pass messages reliably at 1kHz, however, as the system load increases and the connection quality drops, ROS will start to drop messages. I would suggest combining the PID controller, the encoder reader, and the voltage writer into a single process. A PID controller can be sensitive to running at an inconsistent frequency, and there isn't a straightforward solution to dealing with dropped messages.

The design does get trickier when you are controlling a full arm. If you are writing an aggressive controller that is very sensitive to perturbations in timing, then you should keep it in a single process. Dropped messages will cause intermittent problems with your controller, and it will be difficult to determine if the issue is dropped messages or a bug in your controller.

If your full arm controller is "simpler", then you can put it in a separate node. Communicating over ROS will give you a few benefits. The commands from the controller are easier to view or plot in realtime. It's easier to change to a different full arm controller without taking down the PID controllers running the motors. If your controller crashes, then it will only take down its own process. By communicating over ROS you gain introspection, flexibility, and better error diagnostics.

For your full arm control and inverse kinematics, I would suggest first separating the components into separate nodes, and then combining them into a single process if there are any issues.

Best of luck with your system

Hi Guido,

Some uses of boost::shared_ptr are thread safe, but other uses are not.

The documentation for shared pointers describes which operations are thread safe:

A shared_ptr instance can be "read" (accessed using only const operations) simultaneously by multiple threads. Different shared_ptr instances can be "written to" (accessed using mutable operations such as operator= or reset) simultaneosly by multiple threads (even when these instances are copies, and share the same reference count underneath.)

These are the two things you can do with a shared pointer: access it without changing it and modify separate shared pointer instances simultaneously. The realtime box solves a third use case: passing an instance of a shared pointer from one thread to another.

Consider the following scenario. Two threads share a global shared pointer named ptr. Thread A writes to ptr, and thread B reads from it:

=== Thread A

ptr.reset(new Object);

=== Thread B

my_ptr = ptr;

This is not guaranteed to be thread safe because shared pointer assignment is not atomic. The assignment to my_ptr can occur at the same time that thread A is modifying ptr, leading to a corrupted shared pointer.

If you're still doubtful, here is a stackoverflow question with a similar example.

Hi Guido,

If your controller crashes, the entire realtime loop will die. In the PR2 controller manager, all controllers are run in the same process, so if one crashes, the entire process crashes.

Try attaching gdb before loading your controller (you will probably need to run it as root).