[Fedora Robotics] p/s/g demo client program

[John McLean]

On Tue, 5 Aug 2008, Tim Niemueller wrote:

> Jeff Spaleta schrieb:
>> On Tue, Aug 5, 2008 at 5:29 AM,  <jesusfreak91 at gmail.com> wrote:
>>> I realize the above sounds pretty similar to playerv, but I can't think of
>>> what else to do that would meet our needs as I understand them.  Any
>>> suggestions/comments/critiques would be greatly appreciated.
>>
>> I think the goal is to provide a simple, constrained demo that someone
>> can start up via a desktop icon, interact with, and not get lost in
>> even if they haven't used player before.  Is the playerv interface
>> robust enough for that?
>
> Agreed!
>
The playerv interface is pretty easy to use, and given some time I should 
be able to expand it to meet our needs.

>> Here's what I'd like to see in a 2-D demo:
>> a simple robot with a range finding ability, and marker identification
>> a somewhat simple but randomizable 2-d maze environment for it to move in.
>> a goal for it to achieve... "get from here to there"... or "find a
>> specific marker"
>
This sounds great.  I *think* I'll be able to implement these within the 
framework of playerv.  It'll take a few days to know fully, though.

> For the beginning I would even implement just a manual motor control.
> Like "drive forward". This depends on the robot type and it's type of
> movement (omni, synchro, differential). So I would postpone the
> autonomous part for now. This is the more interesting thing, that we can
> do once the infrastructure is in place. Yet for users manual interaction
> is more exciting for the beginning anyway.

As far as I can tell, the libplayerc library and the player drivers take 
care of the details of how the robot moves, so the programmer writing the 
client program doesn't have to.  libplayerc is written so it is portable 
accross many different robots, so many of the specifics such as the 
robot's drive type are taken care of.

>
> For all the robots that I got my hands on up to now the first thing was
> to use or implement a manual control to get a feeling for the robot.
> Then the autonomous behavior was developed.
>
>> the ability to turn the whole map on or off so its either visible or
>> invisible to the user.
>> with the map on the user just drives around the little robot like its an rc car.
>> with the map off the user has to interpret the robots actual data
>> inputs and figure out where to go...so its sort of a game...be the
>> robot's brain.
>
> Yes, that is a good idea. Is playerv modular, so that we can re-use its
> widgets for our application?
>

Agreed.  Being able to turn a map on/off is already a feature of 
playerv, I think.  And yes, playerv should be modular.  I had planned on
either using code from it or build off of it as a base.

>> An interface with a crap load of tool-tipping concerning the controls
>> and data-streams that help introduce player concepts to demo users.
>
> Yes, that is a really good idea. We could also integrate links to say
> Wikipedia.
>

Agreed. Tooltips would definitely make things easier and more 
user-friendly.

> Here is another thing: I've been working on a robot control software
> over the last two years that we use on all of our robots. We are going
> to release the trunk as Open Source software some time this year. It
> should be easy to integrate it with player. It provides a Lua scripting
> environment for behavior control. So we could provide on-the-fly
> scripting of the behavior later on, once a set of basic abilities has
> been implemented. This way you can program "missions" for the robot to
> accomplish quite easy.
>
> 	Tim
>
>