elsp1991's profile - activity

Hello Guys I just convert my controller.yaml to utilize the Joint Trajectory controller for using it in a 3-dof manipulator. My system is fully compatible with ros_control abstraction format (using the RobotHW class).

The problem that I am facing is that shoulder and elbow joints exposes effortCommand but wrist is a hobby servo so it exposes a PositionCommand. So my initial thought was to do something like that

controller_list:
  left_manipulator_trajectory_controller
    type: effort_controllers/JointTrajectoryController
    joints:
      - left_shoulder
      - left_elbow
    gains: # Required because we're controlling an effort interface
      left_shoulder: {p: 1,  d: 1, i: 1, i_clamp: 1}
      left_elbow: {p: 1,  d: 1, i: 1, i_clamp: 1}
    type: position_controllers/JointTrajectoryController
    joints:
      - left_wrist

This file throw no error but parses only the position joint. And if I remove the left_wrist the trajectory controller parses the effort joints. Is there any valid syntax to combine types in the same controller instance

Hello I recently use a position controller in a continuous joint on Indigo and I came across a very strange problem

What I understand is that a continuous joint controller only control the absolute position of a joint. So it supposed to handle the angles in a space [-2pi, +2pi] and even if I command it to 7.5pi it will go to 1.5pi ignoring multiples of 2*pi.

The problem that I found is with a zero command (set_value=0.0) and rotating the joint with my hand the joint holding positions that are multiples of 2 and not 2pi. So I figure that the joint position is expressed in radianspi and not radians.

I also found that if I set a command value of 2*pi (6.28) the joint goes to position 2.0.

So the set_values is expressed in radians and the process value is expressed in radian*pi. I suppose this is a bug or do I miss something?

I Also found in the source code, So maybe is a problem from angles package:

// Compute position error
  if (joint_urdf_->type == urdf::Joint::REVOLUTE)
  {
   angles::shortest_angular_distance_with_limits(
      current_position,
      command_position,
      joint_urdf_->limits->lower,
      joint_urdf_->limits->upper,
      error);
  }
  else if (joint_urdf_->type == urdf::Joint::CONTINUOUS)
  {
    error = angles::shortest_angular_distance(current_position, command_position);
  }
  else //prismatic
  {
    error = command_position - current_position;
  }

Hello everyone, I've just get my robots arms running with ros_control.

My robot read joints position using incremental (quadrature) encoder. These sensor doesn't provide absolute position but only relative to the initial position.

So to set the real position I just sent to joint a small amount of effort and waiting to hit a limit switch, then I set the real position value.

I was wondering if ros_control has something (service or interface) to support initialization processes like this described above, before load the controller, or even better to be part of the load service call. Do you think that is a hardware related issue so it must handled from my node after all?

Thank you

Hello,

I Have a PC with IO expansion card that can be accessed with outb and inb function from sys/io.h

I want these outputs as PWM signals, the task is not very time critical so I choose to go software PWM (bit banging)

I found out that lot of soft PWM codes (RPI, beaglebone) are actually kernel modules not a typical node.

What do you believe it would be the Best Practise?

does anyone ever used sysfs pwm

Hi, I'm using also a pc/104 (advantech PCM-3362) with ROS indigo with no problem.

• make sure to choose a PC/104 with ix86 CPU architecture in order to be able to install ubuntu and ROS with no source code compilation.

The only thing that i came across was, when i try to run rviz it notify me that doesnt support hardware openGL so i switched to software with just a simple command. This has to do with the embedded graphics but you can choose a PC/104 with hardware openGL. For me doesnt really matters because the PC is on a autonomous robot.