I've been asked to write up a demo client program for player/stage/gazebo that we might could use in a robotics livecd to show off the capabilities of player. I'm still not 100% sure what exactly we're looking for, but here's a rough description on what I'm thinking about now:
I'll design a small gui interface similar to that of playerv. Users will be able to control the robot through this interface, using either the keyboard or mouse (don't know which yet). If I have time/the ability to, I'll add in support for a gripper and things like that. I'll also write up a few small client programs that autonomously navigate the robot based on sensor data. In the gui, the user can have to option to use one of those programs to control the robot.
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.
--John
On 8/5/08, jesusfreak91@gmail.com jesusfreak91@gmail.com wrote:
I've been asked to write up a demo client program for player/stage/gazebo that we might could use in a robotics livecd to show off the capabilities of player. I'm still not 100% sure what exactly we're looking for, but here's a rough description on what I'm thinking about now:
I'll design a small gui interface similar to that of playerv. Users will be able to control the robot through this interface, using either the keyboard or mouse (don't know which yet). If I have time/the ability to, I'll add in support for a gripper and things like that. I'll also write up a few small client programs that autonomously navigate the robot based on sensor data. In the gui, the user can have to option to use one of those programs to control the robot.
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.
+1 for this....this gui (can be done by pygtk etc) is what i suggested at one of the previos meeting...go on...start with player first and then add stage part into it....it'll accomplish one of the primary goals in the p/s/g context...just tell if you need any help :)
And Tim.....i started working on gazebo and resolved some issues...yet some build problems persists which i'm looking into...
On Tue, 5 Aug 2008, Arindam Ghosh wrote:
On 8/5/08, jesusfreak91@gmail.com jesusfreak91@gmail.com wrote:
I've been asked to write up a demo client program for player/stage/gazebo that we might could use in a robotics livecd to show off the capabilities of player. I'm still not 100% sure what exactly we're looking for, but here's a rough description on what I'm thinking about now:
I'll design a small gui interface similar to that of playerv. Users will be able to control the robot through this interface, using either the keyboard or mouse (don't know which yet). If I have time/the ability to, I'll add in support for a gripper and things like that. I'll also write up a few small client programs that autonomously navigate the robot based on sensor data. In the gui, the user can have to option to use one of those programs to control the robot.
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.
+1 for this....this gui (can be done by pygtk etc) is what i suggested at one of the previos meeting...go on...start with player first and then add stage part into it....it'll accomplish one of the primary goals in the p/s/g context...just tell if you need any help :)
If you get the chance (assuming you haven't already) take some time to play around with playerv and/or playerjoy. See what parts of those meet our needs, and what parts don't. That'll help me out in designing an application. And if it turns out that those two meet our needs, then I'll move on to some other area that needs work done.
And Tim.....i started working on gazebo and resolved some issues...yet some build problems persists which i'm looking into...
When you get a working rpm/srpm let me know :) I've been wanting to play around with gazebo to get a feel for how it works, but I can't get it compiled on my system.
--John
On Tue, Aug 5, 2008 at 5:29 AM, jesusfreak91@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?
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" 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.
An interface with a crap load of tool-tipping concerning the controls and data-streams that help introduce player concepts to demo users.
-jef
Jeff Spaleta schrieb:
On Tue, Aug 5, 2008 at 5:29 AM, jesusfreak91@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!
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"
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.
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?
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.
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
On Tue, 5 Aug 2008, Tim Niemueller wrote:
Jeff Spaleta schrieb:
On Tue, Aug 5, 2008 at 5:29 AM, jesusfreak91@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
robotics@lists.fedoraproject.org
-
Arindam Ghosh -
Jef Spaleta -
John McLean -
Tim Niemueller