On Tue, 5 Aug 2008, Tim Niemueller wrote:
Jeff Spaleta schrieb:
On Tue, Aug 5, 2008 at 5:29 AM, <jesusfreak91@xxxxxxxxx> 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
_______________________________________________
Fedora-robotics-list mailing list
Fedora-robotics-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-robotics-list
