[cram-developers] issues with actionlib_lisp

Georg Bartels georg.bartels at cs.uni-bremen.de
Thu Dec 5 08:56:24 CET 2013


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
> 
> 
> 
> 



More information about the cram-developers mailing list