Ro-Bot-X

11 years 11 months ago

Quote form GroG:

 

You might want to consider how internet hang-outs & chats work, while thinking of how you want the game to behave.  For example, people have a tendency to get sidetracked while at the computer (possibly playing the game) .. and an inactive player might be fun for a little bit, but it would be a drag if someone decided to do laundry while they were supposed to be controlling a bot.  Maybe an inactivity time to throw them off and reconnect with a new online player?

Also, what about queuing?  Should there be a main queue of spectators, should they be informed where they are in the queue?  Should the spectators be allowed to swap into position of a player after a certain amount of time?  How should all this conside with the game's time?  How long should a game be?

I have not thought about all this. I am more a mechanical person, so my first thought is to make the robots ready to play. I need to know what does it take to control them. What commands are needed, etc. Then Greg can add those into MRL.

Having a player queue is a good idea. If one player looses his internet connection or something else happens, the next player in line can get the control of the robot. Anyone who wants to play has to enrol to the queue. Then they wil be announced when they have the control of a robot. At the beginning of a match, there should be something like in a game of StarCraft where people choose which team they want to play into and chose a robot number. The player's name will be shown next to the robot number in the list of players. The screen can be a large video immage with a small control and info zone where the list of players is displayed, the remaining game time, the score, the control buttons, etc. It would be nice if the players could also talk during the game. If not, there needs to be a chat box with announcemets from the referee, the other players, etc.

Oh, and the game should have 2 halves of 15-30 minutes each, with a short break between the halves, when the teams exchange fields positions. The lenght of the match will be decided by how long can the robots work with a fresh charge (probably an hour). At the moment I do not have spare batteries to swap so other people can play. Plus, after one hour game, I will need a break, since I will need to be the referee and attend the robots of they fall, etc. I will also need to comment and troubleshoot and lots of stuff, so I will definitely need a break. The batteries take about 2 hours to recharge from a USB port, but probably less if I fast charge them. I'll try to build fast chargers for them and buy spares that can charge during the game. then we can have something like a championship tournament (OMG, I have a life!!!). So, we probably need the software to be able to keep track of teams, scores, etc for the championship... Let's not get ahead of ourselves, shall we?

 

Do you have a logo you want to use? Or should I just grab something I think might be appropriate?
Here is what I mean...

This is the current possible Service selection in MRL - pre 15 release

uBipedino would be another one - with some 48x48 png

admin

11 years 11 months ago

For quick updates can you set up a computer your going to use in the game like you did the Chumby? (ie accessable from the internet with a login?)

Ro-Bot-X

11 years 11 months ago

Greg, I was thinking, can you create a simple user interface to play the game? A stripped down MRL of sorts that has just the needed parts to function. Just a single window that opens full screen, has a large video area, a chat area and control buttons. Also Connect, select the robot, team, what ever will be necessary. I think setting up the required links in MRL will be overwhelming for some users that will just want to play with the robots.

Did you saw the Magabots on LMR? I think the guy used Skype to offer remote control over the robot and you could talk and hear what was around the robot and see the video from the robot. You also had the control commands by pressing keys on the keyboard. Can you make something like that or just using Skype would be easier? I have no idea how this could be done.

Thanks again,

Gabriel.

Sure,
There is a DevKit for Skype - I'll download it.  I "think" the magabots use a SkypeCom library which only works on windows.  I believe the Devkit will work on other OS's.

There would be no "links",  I have not used links for ages - for development I use Python scripts, but a Player should not need anything but a URL & a login.

Skype is about as far from open source as you can get ...  

"You are required to and agree to obtain additional licenses from MPEG LA and any other applicable rights holders prior to using (in any manner whatsoever) the H.264 component in connection with any SkypeKit Product. See the SkypeKit license agreement and the audio video documentation for full details."

admin

11 years 11 months ago

Since you are not interested in processing the Audio or Video, maybe we should use MRL just for the controller (a minimal little app or applet) .  

I'll continue to look at some possible video/audio solutions with integration into MRL, but in the iterim lets use one of the established video apps.  

Google hangout has an API.  To begin with, why not start a hangout on one of the boxes which will be hosting a soccer camera? 

Here is my idea of a Game User Interface. When you open it, you get a window with a chat area and a zone where you can chose which team you're gonna play and which robot. I think it will be nice for the users to name their team instead of using the generic Red Team and Blue Team. Also, when they choose a robot, their user name is associated with the robot number, so the commentator can use their name instead of Robot #3. When all robots are chosen, the match can begin, every user must click on the Join button to get to the game window. In the game window, the main area is the video feed from the bird view camera, there is a small chat window where they get messages from the referee and each team should have it's own audio channel for making the strategy of the game. Of course, there should be the robot control area with the proper buttons. Oh, I almost forgot, there needs to be a Display area where the score is displayed next to the team name and the game clock.

The MRL server should be able to allocate a separate audio channel fro each team and send out a video stream from the bird view webcam. Also, it needs to get input from the referee (it wil be from the keyboard of the computer the game is running) and it needs to relay the user commands to the robots through Bluetooth.  Also, it needs to keep a clock that is started/stopped by the referee by pressing a key on the keyboard. Another thing, the referee needs to have a wistle button to signal a fault, goal etc.

A second computer will have a Panning webcam that will stream audio and video on uStream for the spectators. The audio will be from the commentator. I don't think this will be MRL related.

Now the GUI (game user interface) can be anything that works, can be a stripped down MRL or anything you can think of. Keep in mind, we will want to use the GUI for other games too. I already have another game idea, perhaps you saw it on LMR.

Thank you so much!

Gabriel.

Sounds good,

I'm working on it now.

A couple questions :

  • what is your up/down speed - you can find out at speedtest.com among other sites
  • is the xp machine in place?

admin

11 years 11 months ago

Start of UI design :
This is what I have so far.
The technologies to be employed are :
HTML & Ajax + JSON for the user's GUI.  Commands and selections will be posted through Ajax calls with JSON encoding.  There will be a single MRL instance running on one of your boxes "the server".  It will accept and decode the JSON messages into MRL messages.

There will be a login & session management, both will be controlled by MRL.

The video feed (hopefully) will be a google+ hangout embedded into the HTML of the user's gui through an iFrame.

Here are the initial pages.

Login

You choose your player by selecting one of the <available> Bots - you can also
see who is playing and what team they are currently on along with how much
time is left in the game.

Wow! This is awesome! I love it!

Perfect for the Soccer game. I guess for the RoboCraft game you'll design another interface, just the graphics? Yeah, personalized interfaces is better, even though the engine is the same, makes sense.

Thanks!

Gabriel.

admin

11 years 11 months ago

I've got most of the AJAX/JSON javascript framework done.

It seems like it has a lot of potential.  The javascript uses a Message which is the same format MRL uses to communicate between services.  So "the browser" has now become a service of MRL.

On the video streaming side, initially I thought of Google hangout API as being a solution to distribute video. The API is rather strange (at best).. although I appreciate Google creating a free API (unlike Skype).  After looking at it, I was rather disappointed about the lack of control a developer has.  Basically its like writing a little web widget - and you have to go through some hoops to publish it "inside" the hangout (ie. your app will not contain a Google hangout, the Google hangout will only contain your app)

I looked at Red5 a long while back as a streaming video/audio solution and it was just getting started.  OMG, has it gotten better !  Or initially it looks like it...  I'm almost definately going with it for our video/audio/streaming solution - It looks really impressive and ITS OPEN SOURCE !  

Downloading it now

admin

11 years 11 months ago

Here you can see a debug table.  It dynamically grows as messages go back and forth with AJAX.  You can see msg #1 going to the MRL server with a login request.
msgs #2 & 3 are responses from the MRL server saying it can not connect to the authentication mechanism, and a status lights up with useful info !  The difference between previous screenshots is this one is actually sending messages back and forth to MRL :) .

admin

11 years 11 months ago

Here is the Server side GUI which show's the

  • the MRL Runtime service
  • the Web Server service
  • the Soccer Game service - which will have all the rules, game time, manage & coordinate players, etc.
  • and the 6 Arduinos ready to accept player commands

Just have a little more piping to hook up...

oh, and the Red5 video/audio streaming service...

Hi guys, I am following up on the original idea from here. I wrote a post about this here. To recap, here are the details:

This is a game of Football (soccer only for the north american continent) where people can take control remotely of a micro biped robot through internet and move it around in the field and kick the ball trying to score. There will be 3 robots in a team, the players will see a bird view of the field to be able to control their robots. The players will also be able to control the robot's speaker and the color of their eyes to express their feelings during the game.

 

Proposed rules:

Kick Off. The referee throws a coin in the field to chose which team gets the kick off. Each team will have one robot positioned on the middle of the semi-circle on his half of the field, one robot as a goal keeper placed in the middle of the goal area and the other robot on one of the corners of the penalty box (the large rectangle). After the game start signal, the robot that has the kick off will start to move towards the ball to kick it. All other robots are not allowed to move until the ball has been kicked.

Corner. Since the field has sides, the game will be paused in the situation where the ball gets stuck in the corner, the player that touches to the ball first will have the kick. If the ball was in the player's corner, the player will be placed towards the oposing team goal and the ball will be palced in the front of it for the kick. If the ball was in the oposing team's corner, the player will be placed facing the middle of the penalty area and the ball will be placed in the front of it for the kick. All players can move their robots in the desired place waiting for the kick. The referee will wait for all robots to stop in their possitions. After the referee signal, the player can kick the ball.

Faults. If a robot throws another robot on the ground, the game gets paused and the robot on the ground is set back on it's feet and gets the ball for an indirect kick. If such a fault happened in the Penalty area, there will be a penalty kick from the penalty spot, with the goal keeper placed in the middle of the goal line. 

The goal keeper is not allowed to get out of the penalty box. There is no Off Side or Out in this game. The ball is allowed to bounce off the wall and enter the goal and it is considered a valid goal. A goal is considered valid if the ball passes completely the goal line. After the break, the teams exchange filed halfs.

These are the basic rules of the game. Other stuff that affects the game play should be discussed here so that Greg can add that functionality to his MRL.
 
At the moment I am using a TV remote control to refine the robot's movement so it is easy controlable to get to the ball and kick it. I'll post a video as soon as I have that done.
 
Thank you Greg for your efforts in making this game happening!
 
Gabriel, a.k.a. Ro-Bot-X