Roboteq encoder agnostic

[akwalker2048]

This code should allow the Roboteq node to use the encoder configuration on the Roboteq hardware to correctly calculate position and velocity in rad and rad/sec respectively. That way, other nodes do not have to have knowledge of the specific encoder hardware in an individual implementation.

[vitorboschi]

Isn't position/velocity already published in the feedback/[measured_position,measured_velocity] topic?

[akwalker2048]

Vitor,

We had a few problems with the way that the code is currently constructed. We use the same roboteq ROS node for multiple implementations of hardware. They do not all use the same encoder. The Roboteq hardware that we are using has an mbs script running on it which sets the Max RPM for the -1000 to 1000 scaling as well as the number of lines per rev of the encoders. Because that information was not being passed from the Roboteq hardware in the "feedback" message, it was required to have those numbers also hard coded inside the ROS node. Unfortunately, that means that we would have to change the information in both places and recompile for each piece of hardware.

The problems we were having were: 1) The velocity command was not being scaled correctly coming from the ROS node to the controller because someone didn't know that they needed to change the max rpm #define in the channel.cpp file to match the script (Because you have to have a Windows PC running the Roboteq utility to query what the values are...even if you knew that you needed to change them...this seemed clumsy and most of our developers are on Linux boxes and have to go hunt for a Windows PC to even perform this task.) 2) The position was being fed back from the controller as the raw 32 bit encoder count register. In order to scale it to radians inside the ROS node, the node needed to know the number of lines per rev of the encoder. This was also in a #define inside the ROS node. 3) In our application, the motor was running far enough that the position register was rolling over. That was not being handled inside the ROS node.

The fix: We wish to only change the max rpm and lines per rev in one place. That should be in the script running on the hardware. That way it only occurs one time, in one place. By simply feeding these values back in the feedback message, they do not need to be hard coded inside the ROS node. As long as the hardware is properly configured, the node does not need to be changed when there is an encoder change or max rpm scaling factor.

Other options: 1) It might not be necessary to send this data with "every" feedback message in order to limit bandwidth...but it is safest to have the information available every time the calculations are done. 2) It might be possible to do all necessary conversions in the mbs script and pass back values that are already in real world units. That would also require passing real world velocity commmands to the unit as well. I thought it was best to keep the mbs script as simple and straight forward as possible. I also wasn't sure how much bandwidth/processing power was available to do the math on the Roboteq... 3) You could also add code to the ROS node to query the LPR of the encoder and the Max RPM scaling. That might be a better long term solution, but I needed to get our hardware up and running quickly and I have a lot of other work to do.

Best Regards,

Andrew Walker (859)533-8064 Badger Technologies, LLC andrew@badger-technologies.com

This message, including any attachments, may contain information which is proprietary to Badger Technologies, LLC and confidential in nature. Unless you are the addressee (or authorized to receive for the addressee), you may not read, use, copy or disclose to anyone the message, its attachments, or any information contained therein. If you have received the message in error, please advise the sender by reply e-mail and delete the message and any attachments.

On Wed, May 10, 2017 at 9:43 AM, Vitor Boschi da Silva < notifications@github.com> wrote:

Isn't position/velocity already published in the feedback/[measured_position,measured_velocity] topic?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/g/roboteq/pull/17#issuecomment-300485700, or mute the thread https://github.com/notifications/unsubscribe-auth/AYClHyazM7haiXDfKWSMolYDNnzZKzZDks5r4b7ngaJpZM4NQy35 .

[vitorboschi]

Thanks Andrew! I'm using this driver on a controller and also working mainly on a Linux box, so I guess I should use your patch too.

[akwalker2048]

We have only been testing it in it's current form for about a day now. I won't make any claim that all the kinks are worked out yet. I did check in a lot of fixes just yesterday...so make sure you have the latest. The version when I submitted the pull request didn't work. I had to push the changes in order to be able to pull them down on our hardware to even start debugging.

If you find any more bugs...please let me know!

Best Regards,

Andrew Walker (859)533-8064 Badger Technologies, LLC andrew@badger-technologies.com

This message, including any attachments, may contain information which is proprietary to Badger Technologies, LLC and confidential in nature. Unless you are the addressee (or authorized to receive for the addressee), you may not read, use, copy or disclose to anyone the message, its attachments, or any information contained therein. If you have received the message in error, please advise the sender by reply e-mail and delete the message and any attachments.

On Wed, May 10, 2017 at 10:15 AM, Vitor Boschi da Silva < notifications@github.com> wrote:

Thanks Andrew! I'm using this driver on a controller and also working mainly on a Linux box, so I guess I should use your patch too.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/g/roboteq/pull/17#issuecomment-300495400, or mute the thread https://github.com/notifications/unsubscribe-auth/AYClH2PQJxoYONT7BYYggpJY9i5N1a2eks5r4cZlgaJpZM4NQy35 .

[akwalker2048]

One more thing...You will need to add the two extra variables to the feedback from your hardware...

These lines were added at the beginning of the mbs script:

Dim CPR as Integer Dim RPM_SCALING as Integer

CPR = 512 RPM_SCALING = 2500

setconfig(_EPPR, ch, CPR) setconfig(_MXRPM, ch, RPM_SCALING)

And these lines were added added at the end (other lines may be different than the upstream version of the mbs script as well):

PrintFeedback: print("&f:", ch) print(":", getvalue(_MOTAMPS, ch)) print(":", getvalue(_MOTCMD, ch)) print(":", getvalue(_MOTPWR, ch)) 'Original values in Roboteq script read from the encoder 'Use Encoder feedback print(":", getvalue(_ABSPEED, ch)) 'print(":", getvalue(_BLSPEED, ch)) print(":", getvalue(_ABCNTR, ch)) 'print(":", getvalue(_BLCNTR, ch)) print(":", getvalue(_VOLTS, 2)) print(":", getvalue(_BATAMPS, ch)) print(":", getvalue(_ANAIN, ch)) print(":", getvalue(_TEMP, ch+1)) print(":", CPR) print(":", RPM_SCALING) 'print(":512") print("\r") Return

Best of luck!

Andrew Walker (859)533-8064 Badger Technologies, LLC andrew@badger-technologies.com

This message, including any attachments, may contain information which is proprietary to Badger Technologies, LLC and confidential in nature. Unless you are the addressee (or authorized to receive for the addressee), you may not read, use, copy or disclose to anyone the message, its attachments, or any information contained therein. If you have received the message in error, please advise the sender by reply e-mail and delete the message and any attachments.

On Wed, May 10, 2017 at 10:17 AM, Andrew Walker < andrew@badger-technologies.com> wrote:

We have only been testing it in it's current form for about a day now. I won't make any claim that all the kinks are worked out yet. I did check in a lot of fixes just yesterday...so make sure you have the latest. The version when I submitted the pull request didn't work. I had to push the changes in order to be able to pull them down on our hardware to even start debugging.

If you find any more bugs...please let me know!

Best Regards,

Andrew Walker (859)533-8064 <(859)%20533-8064> Badger Technologies, LLC andrew@badger-technologies.com

This message, including any attachments, may contain information which is proprietary to Badger Technologies, LLC and confidential in nature. Unless you are the addressee (or authorized to receive for the addressee), you may not read, use, copy or disclose to anyone the message, its attachments, or any information contained therein. If you have received the message in error, please advise the sender by reply e-mail and delete the message and any attachments.

On Wed, May 10, 2017 at 10:15 AM, Vitor Boschi da Silva < notifications@github.com> wrote:

Thanks Andrew! I'm using this driver on a controller and also working mainly on a Linux box, so I guess I should use your patch too.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/g/roboteq/pull/17#issuecomment-300495400, or mute the thread https://github.com/notifications/unsubscribe-auth/AYClH2PQJxoYONT7BYYggpJY9i5N1a2eks5r4cZlgaJpZM4NQy35 .