Hi Daniel,<br><br>I recently created controllers for irp6 manipulators. It use software only servo algorithm implemented as OROCOS component. It's run 1kHz servo loop for 8dof on pentium3 600MHz so performance isn't an issue heare. I think OROCOS is the optimal solution for integration low-level real-time control with ROS. You can look at orocos_controllers and irp6_robot stacks at <a href="http://github.com/RCPRG-ros-pkg">http://github.com/RCPRG-ros-pkg</a> . As far as i know servo loop must have constant period so real-time is what you need. There is some problems with ROS and multiple servo loops running at different periods (for example robot_state_publisher ) .<br>

<br clear="all">Pozdrawiam<br>Konrad Banachowicz<br>
<br><br><div class="gmail_quote">2010/11/7 Daniel Stonier <span dir="ltr"><<a href="mailto:d.stonier@gmail.com">d.stonier@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Hi all,<br>
<br>
I've been working over the last few weeks to put together a core robot<br>
subsystem for one of our robots - it's pr2 like with a mobile base, a<br>
manipulator and various other motor driven mounts (14 motors in all),<br>
but on an a real budget and I was wondering what experiences others<br>
have had doing something similar.<br>
<br>
The primary challenges with ours are two fold:<br>
<br>
1) It isn't running an ethercat based system. i.e. it's non-real time,<br>
though thats something I would like to upgrade on this particular<br>
robot in the future, however its not something that all of our robots<br>
will have. This means the motors are often driven on multiple loops,<br>
some fast and some slow (so not to burden the low spec embedded<br>
board). Also, the controllers in ros are using a real time publisher -<br>
and I made the assumption that is not usable for non real time (please<br>
correct me if I'm wrong!), so rebuilt all the<br>
controllers/transmissions we had to use.<br>
<br>
2) We're running on a low spec intel atom (the lowest), so topic<br>
communication and loop frequencies need to be kept down. Since its not<br>
centralised, it needed some care designing to ensure callback<br>
frequencies didn't escalate and control loop periods weren't consuming<br>
too much horsepower. Most of it is interrupt driven now too because<br>
different subsystems are cycling at different speeds.<br>
<br>
Finally, its roughly working, but its quite ad-hoc and took alot of<br>
building in the long run and am wondering if there's an easier way to<br>
do it, or a way to genericise components so that they can be recycled<br>
for both non-realtime and realtime systems.<br>
<br>
Regards,<br>
Daniel Stonier<br>
<br>
--<br>
Phone : +82-10-5400-3296 (010-5400-3296)<br>
Home: <a href="http://snorriheim.dnsdojo.com/" target="_blank">http://snorriheim.dnsdojo.com/</a><br>
Yujin Robot: <a href="http://www.yujinrobot.com/" target="_blank">http://www.yujinrobot.com/</a><br>
Embedded Ros : <a href="http://www.ros.org/wiki/eros" target="_blank">http://www.ros.org/wiki/eros</a><br>
Embedded Control Libraries: <a href="http://snorriheim.dnsdojo.com/redmine/wiki/ecl" target="_blank">http://snorriheim.dnsdojo.com/redmine/wiki/ecl</a><br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</blockquote></div><br>