Let's Make Robots!

LMR Global Project - Idea Phase

This thread will allow the build team of Jklug80, rik, Calculon320, slick, Edgee, CaptainTune and robologist to start working on the project and figure out what it is, what it will do and how to build it.

Currently the goal is to decide what the project is (what jklug80 proposed or something else), then we need a name for the robot, then we need a name for the group of 7 who are working on the project. We need a list of desired features, a list of REQUIRED features, and who will do what. LETS GET STARTED!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

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!  

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 to assume latency and less than 30FPS which means it will have delays between frame refreshes.

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. 

Definitely ask Semicton about your webby stuff. He's really into that kind of computer-web-robot interface kinda thing. :)

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.

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 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?

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 ...