[cram-developers] issues with actionlib_lisp

Lorenz Mösenlechner moesenle at gmail.com
Thu Dec 5 09:14:16 CET 2013 

Hi Georg,

regarding tf2: transformation libraries, e.g. tf are simple enough that you
can implement them without too much effort as a native library (approx. 2~3
days effort). I think cltf2 wouldn't be too different from cltf and I'm
sure a lot of code can be re-used.

Lorenz


On Thu, Dec 5, 2013 at 8:56 AM, Georg Bartels <
georg.bartels at cs.uni-bremen.de> wrote:

> Hi,
>
> following up on this: Here's the issue I opened up on this:
> https://github.com/ros/roslisp_common/issues/8
>
> @Lorenz: Also thanks for your thoughts on wrapping CPP for Common Lisp.
> I was wondering how difficult wrapping the new tf2-core for Lisp would
> be. I will consider your advice when deciding how to proceed with that
> project. :)
>
> Cheers,
> Georg.
>
>
> On 12/04/2013 06:28 PM, Georg Bartels wrote:
> > Hi Lorenz,
> >
> > thanks for your detailed answer which got me looking into the right
> > direction.
> >
> > To quickly summarize my findings/status:
> > - It is indeed enough to use wait-for-server only once. :)
> > - The action server protocol is unchanged and the server continously
> > sends status.
> > - My network is fine, both client and server are running on my pc, and
> > there are no meaningful spikes in connectivity.
> > - I'm using the standard actionlib:SimpleActionServer
> > - I went through actionlib_lisp/action_client.lisp, and there is a
> > German saying for my current situation: "Einem geschenkten Gaul schaut
> > man nicht ins Maul." ;) Anyway, I'm pretty sure now that there is a race
> > condition in the current implementation which leads to lost goal-handles
> > when cancelling from client-side through abort-goal.
> >
> > I'm not sure how to fix the issue right-away but it is also __not__
> > screwing up the behavior of my robot. So, I guess I will sketch a
> > simplistic example (using the fibonacci-tutorial) and open up an issue
> > for actionlib_lisp. We'll see more then, I guess.
> >
> > Cheers,
> > Georg.
> >
> >
> > On 12/04/2013 10:24 AM, Lorenz Mösenlechner wrote:
> >> Hi Georg,
> >>
> >> the problems you are facing are not normal. I've been using
> actionlib_lisp
> >> quite a lot. Sometimes I got connection losses but they didn't happen
> too
> >> often and were mostly caused by a flaky network connection.
> >>
> >> You should call wait-for-server before you send the first goal but you
> >> shouldn't require it before each goal. Btw. the call to it should never
> >> take 2 seconds given your action server is correct. Basically,
> >> wait-for-server waits for a message on the action server's status topic
> and
> >> then returns. Not sure if something changed in the past but when I
> >> implemented the action client, action servers continuously sent a
> heartbeat
> >> on the status topic that contained the number of goals that were
> processed
> >> currently. The rate was at least 5Hz or so, definitely not 2 seconds.
> Can
> >> you verify that your server is still sending the status properly by
> >> subscribing to the corresponding topic. You can also use rostopic hz to
> >> find out the publish rate.
> >>
> >> I can think of three possible reasons for your problems:
> >>
> >>  - The action server protocol changed and it is not sending status
> >> continuously anymore.
> >>
> >>  - Your network connection is bad and the sockets between the server and
> >> the lisp client die sometimes. Then it takes a while until they come up
> >> again if they do at all.
> >>
> >>  - Your action server is wrong. Is it using actionlib? I remember that
> the
> >> guys at DLR were using something home-made that didn't follow the
> correct
> >> protocol. Could that be the case for you as well?
> >>
> >> I don't think that wrapping a C++ library is the best solution. Reasons:
> >> the maintenance will not be less. Changes in the server API will also
> >> require changes in the wrapper. The amount of code will also not be
> less.
> >> You either have to use a binding generator such as SWIG which is pure
> crap
> >> and will cause you a lot of problems or you will have to implement a C
> >> library that wraps the C++ actionlib library and then wrap the C library
> >> using CFFI. I did this with bullet and it is doable, but I wouldn't
> suggest
> >> to do it if it can be avoided.
> >>
> >> Lorenz
> >>
> >>
> >> On Wed, Dec 4, 2013 at 10:00 AM, Georg Bartels <
> >> georg.bartels at cs.uni-bremen.de> wrote:
> >>
> >>> Hi fellow-CRAMers,
> >>>
> >>> I'm facing difficulties using the actionlib_lisp client.
> >>>
> >>> Issue #1:
> >>> If I just send out a goal with send-goal-and-wait, I get a "Goal is
> >>> lost" warning rather often. If I add a wait-for-server before each of
> >>> those calls I do not get those warning and everything works fine. Is
> >>> this the recommended way of sending out goals? Shouldn't the connection
> >>> be established once, and then kept permanently?
> >>>
> >>> Issue #2:
> >>> I'm now using wait-for-server and send-goal-and-wait in conjunction to
> >>> avoid lost goals. However, wait-for-server takes at least 2s because
> >>> internally wait-for-server has an unconditional wait __even after a
> >>> connection has been successfully established__:
> >>>
> >>> (defmethod wait-for-server ((client action-client) &optional timeout)
> >>>   (flet ((wait ()
> >>>            (with-recursive-lock ((slot-value client 'mutex))
> >>>              (loop until (connected-to-server client) do
> >>>                (condition-wait (slot-value client 'condition)
> >>>                                (slot-value client 'mutex)))))
> >>>          (handle-timeout ()
> >>>            (return-from wait-for-server nil)))
> >>>     (if timeout
> >>>         (with-timeout-handler timeout
> >>>             #'handle-timeout
> >>>           (wait))
> >>>         (wait))
> >>>     ;; Give the sockets time to settle down.
> >>>     (sleep 2)
> >>>     t))
> >>>
> >>> For me this is an issue because I wanted to send subsequent motion
> goals
> >>> to a controller in quick succession. Does anybody see a way to avoid
> >>> this force waiting period?
> >>>
> >>> I'd be fine with waiting for 2s __once__ before starting a longer
> series
> >>> of motions but given issue #1 this is not possible.
> >>>
> >>> Issue #3:
> >>> I have been successfully sending commands to a server with
> >>> wait-for-server and send-goal-and-wait for a couple of minutes. All of
> a
> >>> sudden I start getting "Goal is lost" warnings again. Strangely, some
> of
> >>> them still cause the server to correctly perform the action, others do
> >>> not. Additionally, it feels the frequency of lost goals is increasing
> >>> over time. Shutting down the node, restarting inferior lisp, and
> >>> starting a new cram-node does not seem to solve the issue.
> >>>
> >>> Has somebody else encountered this? How did you approach the problem?
> >>>
> >>> Finally, I started comparing the cpp implementation with its lisp
> >>> counterpart. Coincidently, I discovered the python implementation which
> >>> is basically a wrapping around the cpp implementation. Would following
> >>> the same route for actionlib_lisp be an option? It'd be some work now
> >>> but the protocol-specific maintenance would be with the cpp-guys.
> >>>
> >>> I think fixing the actionlib_lisp should have a very high priority for
> >>> us as CRAM developers as a lot of low-level functionality interfaces to
> >>> us via actions. Do you agree?
> >>>
> >>> Cheers,
> >>> Georg.
> >>> _______________________________________________
> >>> cram-developers mailing list
> >>> cram-developers at informatik.uni-bremen.de
> >>>
> https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> cram-developers mailing list
> >> cram-developers at informatik.uni-bremen.de
> >>
> https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers
> >>
> >
> > _______________________________________________
> > cram-developers mailing list
> > cram-developers at informatik.uni-bremen.de
> >
> https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers
> >
> >
> >
> >
>
> _______________________________________________
> cram-developers mailing list
> cram-developers at informatik.uni-bremen.de
> https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.informatik.uni-bremen.de/pipermail/cram-developers/attachments/20131205/f82e4daf/attachment.html>

More information about the cram-developers mailing list