Soccer-bots
Those that he programmed were little differential drive soccer players, not humanoid types. They were pretty quick and cute too. But a lot of the bipeds do have pre-programmed sequences to get up. Sadly they run into a bit of cash though. The cheapest humanoid to try would probably be the I-sobot, but not sure how much access we could get to make one web controllable. Or self charging. But who knows?
Hey why not binding the two
Hey why not binding the two ideas? Web controlled soccer bots! So anyone can join in and play a soccer match on the net. It might be nice because:
- soccer robots won’t have to be too expensive and hard to make, you just need an MCU, motor driver, and RF receiver
- someone has already done the “controlling the bots via web” so we might ask for help if we don’t know how to
- it’s definetly something innovative!
OH and…if we all have MR Basic we might consider using it
PS: i have a doubt…were you already talking about it? If yes please excuse me!
Latency
Soccerbots would probably require a pretty short feedback loop on what was going on, as well as a quick way of getting commands to the robot. I think internet latency and maybe bandwidth might be a problem there. In other words, a player sees the ball and directs the robot to turn and head towards it. A 1/2 second later the turn is executed (time for command to bounce through ip addresses) and the robot then heads forward, only to see the soccer ball is gone (from the other robot that was already aimed at it). It appears the ball just disappeared as the video frame rate hit just right to allow the other robot to pass in between frames, so there is no apparent direction the ball went. Now this may be worst case, but I wouldn’t be surprised to see both the latency (commands getting through slow) and low video frames (bandwidth) become frustrating.
True if we use video we have
True if we use video we have to assume latency and less than 30FPS which means it will have delays between frame refreshes.
it looks like i forgot all
it looks like i forgot all the latency problems i had when trying (without good results) to make a multiplayer game… you are right, don’t know why but i didn’t think about it.
**I liek the paintball bot **
But i think IR sensors would be easier to do and also would cut out the need for reloading. We could have two with two modes, one would be for people to control them over a web page and the other would be where they fight each other. There would still be latency issues to deal with but this could be gotten round by either having the user click on a map to move the vehicle and then having a barrel cam where they can target thing, like modern tanks have. The challenger 2 can assign 6 targets and drop them in quick succession with one click of a button. It wouldn’t have to be as complicated as that system, we could then use this as the basis for a freeplay mode when there is no one around. There could be different game modes such as: Attack & defend:
one bot attacks the other defends, easy
Sniping: shots over three meters only(depending on scale) hide and seek: One hides one seeks.
We could even set up a static targets using something similar to ctc’s rf beacons.
Versus
I think that in a situation that is time/place sensitive for the user, such as paintball or soccer, the latency issues would be crippling. Maybe we should concentrate on a single-user concept to start?
real-time vs.
Or…
What if you made a sort of turn-based thing, where the web users can enter, say, 6 commands each (from a list), and all the robot then execute their commands simultaneously. This would take care of latency problem …
I like it, we could get over
I like it, we could get over the latency problem. You have to keep in mind though, that IR light bounces off walls and this would mean having a “HIT” even if you get the wrong aim.
This may be solved with low power LEDs, maybe with a low duty cycle. One other thing, would polarizing the IR work? I mean, what happens to a polarized beam once it bounces off a wall? Does it still remain polarized or it gets screwed up because of the unevenness of the surface? If it doesn’t remain polarized this could also be a solution.
I think it’s what Edgee
I think it’s what Edgee said, and the only solution if we want two bots to “fight” each other.
PS: Skype forum?
yeah …
guess i mis-read that …
From the above discussion it
From the above discussion it sounds like we want to start off with a project that includes 1 robot and isn’t overly affected by some latency due to the internet connection. The question now is what do we want out one bot to do? I would like it to be as self sufficient as possible. My idea is that once we build it and switch it on it cleans up after itself (if it shoots anythign it picks up the ammo and reloads), it feeds itself (charges when batteries get low), and can keep itself out of trouble (using walls or a line to give it boundries). We also need to think of how it could be abused (run into a wall forward or reverse, etc) and code it so it doesn’t hurt itself.
So Ideas? What do we want it to do? Perhaps after we finish we can tweak it to have a friend that is also controlled via the intertubes and built from there. I like the soccer (futbol) idea but without a friend it would be a little boring and really requires zero latency. Do we want it to be able to pick up stuff, rearrange its environment, play music, etc?
Play pen
This bot absolutely needs some sort of play pen. Visitors (robot operators) should not get control over its exact moves. All they can order the bot to do, is higher level functions. Like “pick up red block”, “place item on cube”, “find wall”, “put your arms in the air, like you just don’t care”.
Of course, it would be super boring if you were only to give highest level orders like “do something really cool”. The operators want to have some creative fun themselves. That’s why the play pen needs to be challenging and rich in interactive features.
So our bot needs to be pretty self dependant. Autonomous in the way it executes sub-tasks. And it definitely would not “have a plan”.
**I agree on the **
Level of control the user has, the robot to be a true robot and not just a fancy rc car is autonomy.
Agreed, we now have to think
Agreed, we now have to think what to put in the play pen… a plant that needs watering for example? A fire to be put out? A barbarian that needs to be sent home?
Ok i been thinking…
How about a wall with the LMR logo on it made up of wooden blocks, the robot has to assemble the wall so that the logo is complete, when the logo is complete a user can then fire balls or some form of missile at the wll to destroy it, the bot then collects all the ammo and rebuilds the wall.
That pretty much includes everything that everyone wants out of this project i think.
BIG GIANT HAMMER
That’s all I have to say.
No ammo to re-collect, just spots in the pen to slam.
lol
Thats an awesome idea 
Only reason i suggested the balls is so it has something else to do other than build and destroy.
In the playpen
The playing music idea stuck for a second. The “driver” could have the robot hit a button to play some tune and once the tune is going, the robot could do some sort of dance on it’s own.
Picking up stuff/ throwing stuff would be cool. I wouldn’t want the robot to pick up after itself, but have the “driver” do that, maybe picking up things to throw. The charging would need to be autonomous, but I think any environment manipulation should be “driven”.
The BP Explorer robot had little hidden messages that showed up in the camera view when driving the robot different places in their diorama. Note they had a camera view from the robot, as well as a couple overhead views of the box.
So there could be “hit a button” for music or whatever, “pick up something”, “throw something”, “find message” tasks that a driver could do, and a “recharge” task the robot could do. Maybe a"get unstuck" task and a “right side up” task for the robot too.
Hmm, what about a “draw or write” task? Might require too much fine control.