0
$\begingroup$

Rosanswers logo

Hi All,

I'm starting to implement a better control framework for a manipulator. I'd like keep some level of compatibility with the ros_control project thats under development. I'm looking to implement a RT velocity controller using Xenomai Native API, and communicating with user space via shared memory. It appears that interacting with this shared memory should be the job of robot_hw class, which seems to load an interface.

Should I look to only modify the interface classes (joint_state_interface, actuator_interface) to conduct the memsharing operations? ie, is that the intention of ros_control, that users only have to adjust the interface classes to marry up with their hardware arrangement? Or is there some lower level?

EDIT The method by which the realtime controller is implemented is really not important, I just would like to know at which part of the ros_control api I should implement access to the lower level realtime controllers. Ie which classes should I modify to include the access point to the hardware.

any guidance would be welcome

cheers

Peter


Originally posted by PeterMilani on ROS Answers with karma: 1493 on 2013-09-28

Post score: 1

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

I found the information I was looking for and answers my questions:

https://github.com/ros-controls/ros_control/wiki/hardware_interface

well done to the team developing this package


Originally posted by PeterMilani with karma: 1493 on 2013-09-30

This answer was ACCEPTED on the original site

Post score: 4


Original comments

Comment by Dave Coleman on 2013-11-15:
Can you share how you integrated the RT Xenomai Native API with a ros_control hardware interface? I'm interested in doing the same, thanks!

Comment by PeterMilani on 2013-11-18:
I'm still working through it. The main issue is that the only reason for implementing xenomai is for accurate timing of the cm object. I think this means that the cm object should run within xenomai kernel but I'm not sure it would work with the networking elements of ros. Will share testing.

$\endgroup$
0
$\begingroup$

Rosanswers logo

If I understand correctly, you are using Xenomai to communicate with your hardware, and you want to expose the raw data (sensors, actuators) to ros_control. If so, you don't need to modify any of the existing ros_control classes, but rather create a RobotHW abstraction class for your robot and populate its hardware interfaces. Take a look at this simple example for inspiration.

ros_control does not know whether Xenomai or a realtime shared memory is being used. It only knows about the addresses of the raw data, and what they represent. This allows you to transparently switch between hardware and simulation backends.

P.S. I had intermittent Internet access and had prepared a draft answer offline. I see that by now you figured this one out, but I'm putting up this post for completeness.


Originally posted by Adolfo Rodriguez T with karma: 3907 on 2013-09-30

This answer was NOT ACCEPTED on the original site

Post score: 3


Original comments

Comment by PeterMilani on 2013-10-01:
No problem, the framework you guys have chosen certainly makes it easier and the documentation is pretty clear. Earlier this year I was trying to follow the PR2 controller manager documentation, it was like being trapped in a maze! For fuerte install, I'd have to download ros_control from source?

Comment by Adolfo Rodriguez T on 2013-10-01:
The official Fuerte branch is badly outdated. I was keeping Fuerte backports in my forks of ros_control&friends, but it's starting to lag behind as well, as we're about to migrate to Hydro. You can still find the forks in PAL's organization, fuerte_backport branch.

Comment by PeterMilani on 2013-10-01:
I'll probably just upgrade, there's a few other updates in Hydro I'd like to use. Cheers

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.