Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added High Speed Encoders Phidgets Drivers #23

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

geoffviola
Copy link

Modified this code from an older driver. It fills in the header information, now. Tested it in Indigo.

Copy link
Contributor

@mintar mintar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your contribution! In general, I am for merging this after the changes have been made. Before merging, please rebase + squash. It's unfortunate that I don't have the hardware to test this, but it looks like a valuable contribution.

int32 index
int32 count
int32 count_change
int32 time
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To conform with ROS naming standards, this message should be called EncoderParams.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I think it would be better to use a sensor_msgs/JointState message instead and remove this message altogether.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not familiar with the JointState Message. It might fit, but it is technically for "torque controlled joints". The encoder is not necessarily for that.
The EncoderParms message is legacy from the old package. It would require an extra parameter to convert the counts to an angle, but seems like a little bit too much work for now.

{
nh.getParam("serial_number", serial_number);
}
ROS_INFO("frame_id = %s", frame_id.c_str());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This prints the frame_id before it is read from the parameter server (line 222).

phidgets_high_speed_encoder::encoder_params e;
e.header.stamp = ros::Time::now();
e.header.frame_id = frame_id;
e.header.seq = sequence_number++;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is unnecessary and should be removed. The publisher increments the sequence number automatically.

e.index = Index;
e.count = (inverted ? -Position : Position);
e.count_change = (inverted ? -RelativePosition : RelativePosition);
e.time = Time;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be converted to ROS time and be put in the header.stamp instead. For an example, see phidgets_imu.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The IMU is a little different, because it publishes periodically. The encoder only sends message, when there is at least one tick.

I noticed that the phidgets IMU resynchronizes if it is too old: https://github.com/ccny-ros-pkg/phidgets_drivers/blob/master/phidgets_imu/src/imu_ros_i.cpp#L180. I'm not sure if there is still value in using the devices time, when it resynchronizes often.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think you're right. I was mainly thinking that having both the time and header.stamp fields is redundant. You've removed the time field now, and that's fine by me.

@muhrix
Copy link
Collaborator

muhrix commented Nov 21, 2016

@mintar thanks for reviewing the PR!

I haven't got a phidgets encoder to test either. In fact, I don't even have my IMU (it's probably inside one of the boxes from my last move - or so I hope).

@geoffviola do you think you could make the changes suggested above? If not, just ping me and I can try to do it. Thanks for this PR by the way! 👍

@mintar
Copy link
Contributor

mintar commented Nov 24, 2016

Hi @geoffviola , thanks for responding so quickly to my comments even though your PR is now already 5 months old!

I'm not familiar with the JointState Message. It might fit, but it is technically for "torque controlled joints". The encoder is not necessarily for that.

Yeah, I have no idea why the comments in JointState.msg say that. The message can be used for all kinds of joints, not just torque controlled joints. If you don't know joint velocity and effort, it's perfectly fine to leave those arrays empty and just fill the name and position arrays.

The EncoderParms message is legacy from the old package. It would require an extra parameter to convert the counts to an angle, but seems like a little bit too much work for now.

I still think this has to be changed before merging. The sensor_msgs/JointState message is the ROS standard for joint states, and by using it people can plug this node into all other kinds of ROS software. The custom EncoderParams message is useless, because it has to be converted into a JointState anyway, and that requires knowledge of how many encoder tics per radian there are and what index number corresponds to what joint name. That could easily be passed into this driver node as parameters, and the conversion be done here.

We should fix that now, because everything else can easily be fixed later, but changing the public API is always a pain. If it's too much work, tell @muhrix, he offered to help.

@muhrix
Copy link
Collaborator

muhrix commented Nov 24, 2016

Yes let me know, I'm happy to help!

@mintar
Copy link
Contributor

mintar commented Aug 9, 2017

This PR is now continued in ros-drivers/phidgets_drivers#15.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants