[ros-users] Core robot controller manager

Sun Nov 7 15:25:36 UTC 2010

Pozdrawiam
Konrad Banachowicz


2010/11/7 Daniel Stonier <d.stonier at gmail.com>

> On 7 November 2010 23:46, Konrad Banachowicz <konradb3 at gmail.com> wrote:
> > Hi Daniel,
> >
> > 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
> > http://github.com/RCPRG-ros-pkg . 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 ) .
> >
> Indeed, robot state publisher is going to get a customisation for now,
> at least till I can think of something better.
>
> Up until now (at least till I get time to put together a real time
> solution), I've been putting our manipulator control loop into a posix
> real time scheduling mode. That seems to work ok for simpler, more
> constrained manipulators, but it's probably not enough for everything
> we're going to slam dunk at the system this time around. I'm really
> curious as to just how much better our system would perform with a
> real time loop. Next job for me I suppose!
>
We are using POSIX real-time scheduler and modified linux kernel (
rt.wiki.kernel.org).
We are also using QNX RTOS in our legancy mrrocpp system but we are moving
toward linux for some time.


> Where do you think OROCOS handles things much better than the pr2
> style approach? Or is it just that the pr2 isn't really converted for
> generic purposes yet?
>
PR2 approach isn't really reusable. It is quiet dedicated to pr2 shema of
control (all control tightly integrated using EtherCat ), which i not usable
for me beceose i have many diferent controllers and control schemas (we have
diffrent control hardware for manupulators, conveyor, gripper, ptz ). OROCOS
simplified integration of those and gives ability to implement more advanced
controllers (indirect force control) independently of low level control.

>
> Also, robots without manipulators dont really need real time solutions
> I reckon. They can get away with being a bit rough around the edges
> with regards to timings (e.g. something like a telepresence robot with
> only wheels, camera tilts, lcd tilt and the like).
>
It's depend on hardware used, for example we have mobile base which
integrate velocity control on board so there is no point in using real-time
controller.
Look at Erratic controller.

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