[ros-users] Simple action client - querying its status

[Daniel Stonier]

A day later and I'm getting more familiar it.

I've been rebuilding an old arm control engine of ours into an ros
environment, pulling apart the components very similarly to (but much
simpler) than ros' move_arm and got a bit confused when running through the
code that move_arm uses. It maintains its own state engine for the
controller (server) status and I couldn't work out why you wouldn't just
contact the server directly to query if its idle. Which is where getState
came in, and I misinterpreted that as being the server state, not the state
of whatever goal the client is managing.

I've since put alot more decision logic into the pre-emption parts and as
Vijay mentioned, the code which contains your client can quite easily (when
structured ok - aka move arm's internal controller status state) know
whether a goal has or hasn't been sent for the SimpleActionClient/Server
pair. I guess having this front-end state logic will, of course, only work
if your server is serving only a single client, otherwise you'd have to
address it in the pre-emption code/callback.

As for a usage scenario, what happens if you're low on computational power,
and your goal preparation is pretty costly? You might want to periodically
check while preparing that some other client hasn't dumped a goal on the
server, at which point you could terminate the preparation and simply abort
whatever you wanted to do a little bit earlier in the pipeline. In this sort
of situation, it might be useful to know if the server is idle or not. This
may be rare enough not to worry about though - whoever is writing the server
could just add their own custom topic to do the job.

Cheers,
Daniel.

On 23 October 2010 00:53, Blaise Gassend <blaise at willowgarage.com> wrote:

> Hi Daniel,
>
> getState() is telling you the state of the client's current goal, not
> the state of the server. Hence, if there is no goal, getState is
> meaningless. This makes sense because a server could have the ability
> to handle multiple goals in parallel. Hence, there isn't a single
> state for the server that you can query.
>
> I imagine that what you are trying to do is determine if a server that
> can only handle a single goal is currently busy. I don't think that
> there is a general answer to that question. Some servers might reject
> your goal if they are already busy. Others might interrupt the
> existing goal. Let's see what others have to reply.
>
> Blaise
>
> On Fri, Oct 22, 2010 at 12:51 AM, Daniel Stonier <d.stonier at gmail.com>
> wrote:
> >
> > Just a quick question with regards to the simple action client - why is
> > using the getState() method considered improper when there is no goal
> > (action client outputs an ROS_ERROR when you do so). Is there another
> means
> > of querying the server to know whether it is currently handling a goal or
> > not?
> > Or perhaps, am I mistaken in thinking that I should be needing to?
> > Regards,
> > Daniel Stonier.
> > --
> > Phone : +82-10-5400-3296 (010-5400-3296)
> > Home: http://snorriheim.dnsdojo.com/
> > Yujin Robot: http://www.yujinrobot.com/
> > Eros: 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 Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101023/41443221/attachment-0003.html>