[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-users
Subject:    [Orocos-users] About the WDLSPriorVelSolver in itasc_solvers
From:       marcus.liebhardt () yujinrobot ! com (Marcus Liebhardt)
Date:       2012-02-09 0:45:30
Message-ID: CAKG=6c6kGU-E1DGktKYTOcOGpsOFY7mrrnxL0=3NW3W=g-7r0Q () mail ! gmail ! com
[Download RAW message or body]

2012/2/8 Tinne De Laet <tinne.delaet at mech.kuleuven.be>

> On Wednesday 08 February 2012 17:26:31 Marcus Liebhardt wrote:
> > 2012/2/8 Herman Bruyninckx <Herman.Bruyninckx at mech.kuleuven.be>
> > 
> > > On Wed, 8 Feb 2012, Marcus Liebhardt wrote:
> > > Hi everybody,
> > > 
> > > > I was going through the iTaSC documentation and code, when I found
> > > > iTaSC's IK
> > > > solver WDLSPriorVelSolver.
> > > > I'm curious. Is it planned or possible to move/port this solver to KDL
> > > > to make
> > > > it easier to use it in other contexts?
> > > 
> > > KDL should indeed get a serious refactoring overhaul, by adding some
> > > things and removing other stuff. We have not yet found the time to make
> > > a decent roadmap, unfortunately.
> > > 
> > > If not, do you think it is difficult to do that, e.g. is it closely
> > > link
> > > 
> > > > to
> > > > other parts in the iTaSC framework?
> > > 
> > > The solver _is_ an iTaSC thing, but it uses some KDL algorithms. It is
> > > also a _component_, while KDL only contains _algorithms_. We think that
> > > is the right thing to do: to keep KDL fully independent of any
> > > component framework.
> > > 
> > > Why would you like to extend KDL with component-based solvers?
> > 
> > I don't exactly like to do that, but I'm interested in using a solver,
> > which implements priorities. I couldn't find a solver in KDL, which does
> > that (please correct me, if I'm wrong).
> 
> Why are you not just using the iTaSC software then?
> 

Well, I'm new to iTaSC and had no time to try it out yet. It looks
powerful, but also big and complicated. However, our talk made me even more
curious to try it out! :-)


> It already contains the solver you need. So you just have to implement your
> own task and then, you can use the solver for free :)
> > 
> > One use case of priorities would be implementing joint limit _avoidance_
> > (in contrast to only respecting these limits as the current position
> > solvers (*_JL) do).
> > I'm not sure how this is done in the human-robot comanipulation demo [1].
> > Is it implemented using priorities or weights or both?
> > "task activated close to the limit" made me think it is implemented as a
> > prioritised task.
> We use both prioritization and weights. These things are all configurable.
> So
> there is no recoding needed if you want to change priorities or weighting!
> Just change some properties and rerun!
> Futhermore iTaSC makes use of rFSM (reduced Finite State Machines), which
> allow to make a nice state machine for your task in which you can adapt the
> priorities and the weights ONLINE depending on the actual outcomes or
> performance of your task.
> 
> > 
> > Now, if I like to use such a feature with KDL, I probably would end up
> > writing a new solver.
> > Instead of writing multiple solvers for different tasks, I was wondering
> if
> > there are other ways to achieve this, e.g. by interfacing with iTasc?
> > Are there other modular ways to add functionalities to the current
> solvers?
> > 
> > > I'm wondering if it could work with KDL::Chain and KDL::Tree
> > > structures.
> > > 
> > > There are extensions on the way in this direction. Azamat is working on
> > > them (see some recent posts of his).
> > > 
> > > My idea is to use it to create a kinematics plugin for our robot in
> > > ROS.
> > > 
> > > That's best done with framework-independent KDL algorithms!
> Can you be more specific of the actual tasks you want to implement?
> This way we could maybe help you by pointing out what we would do to
> implement
> it.
> 

My main task at the moment is to improve an old, robot specific and not
parametrisable IK solver, which is based on the pr2_arm_kinematics. My idea
is to replace it with a generic KDL solver, what worked for me before.
This allows me to use the framework/code structure, which is already in
place.
However, I need to find a solution for joint limit avoidance. Also, this
change needs to happen fast.
Hence, in short term I will not be able to implement iTaSC. But in the long
run, I definitely want to try it out.

Marcus


> 
> Kind regards,
> Tinne
> --
> Orocos-Users mailing list
> Orocos-Users at lists.mech.kuleuven.be
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
> 
> 
> 


-- 
Dipl.-Ing. (M.Sc.) Marcus Liebhardt
Control Engineer
Yujin Robot
Address (Korean): ???? ??? ??? ??? 345-30 ????? #601, 153-023.
Address (English): #601, Namsung-Plaza, 345-30 Gasan-dong, Guemcheon-gu,
Seoul, 153-023, Republic of Korea
Website: http://www.yujinrobot.com
Email: marcus.liebhardt at yujinrobot.com
Phone: +82-2-2026-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mech.kuleuven.be/pipermail/orocos-users/attachments/20120209/d23503aa/attachment-0001.html \



[prev in list] [next in list] [prev in thread] [next in thread]