Inter-robot communcation

Apparentally we get to have the robots cooperate.

Friendly interaction between machines is acceptable, if all teams are willing.

Judging from the response I got on, I don’t think it will be through the robot radio this year.

What about the IR boards from 2008?

That has been in the last couple manuals just like the quote from your other thread.

I believe it also is there to cover all interactions between machines during practice matches including defense.

Okay, I’ll do that this year.

Yeah, I think this is more for games like Rack 'n Roll where you’d have to have the robots work together to get teammates lifted off the ground for the bonus points.

“Friendly interaction” refers to physical contact in this context.

As much as I would love to see robots able to communicate with each other (hive mind autonomous, anybody?), I don’t think that it’s what that bit refers to.

I believe you are right about that not being what they are refering to, but it would be really cool to see autonomous robots communicating and interacting with each other … now to work on a common protocol … :stuck_out_tongue:

HELO t1729
Hello t166, I am glad to meet you
>> POSITION t166 0 0

That could be…interesting.

Well, I was assuming everyone would just chat in this thread.

But since you’re interested:
I’m planning on using ultrasonic to transmit team numbers, perhaps encoded with DTMF or morse code.
From that, other robots can use sensors and triangulation to tell where all the robots are, and the LabVIEW waveform processing to tell what number they are.

As I said earlier, this phrase has been in the manual several times, and primarily refers to practicing defense during practice rounds. If the teams are willing, the robots can practice defending each other, provided that they keep it to a reasonable amount of contact.

If you want to try to communicate with another robot, fine. But I don’t think they’ll have sensors in your sending range that will be able to detect your signal. It’s just as unlikely that they have transmitters for their info that you’ll be able to detect. Unless, of course, there’s been a game change and we have to, but I don’t think the GDC’s going to hit us with that for a couple of years yet.

While I agree that I don’t think the GDC will hit us with this, we already have a way to communicate between robots … it’s called WiFi (802.11N to be exact), and it comes prebuilt into the system :smiley:

… now back to that protocol :stuck_out_tongue:

Seriously though, I doubt they’d let us use WiFi

This is not about getting a tactical advantage.
This is a step towards fully-autonomous robots.

In a comprehensive application of military robots, you have land, air, and underwater robots, which need to be able to communicate with eachother. The most basic information you would transfer is where each robot is.

It has been a hope (for some folks in First) to be able to use wireless to communicate between robots for a few years now. I remember it being discussed in a few different venues and with a few different methods. Modulated IR jumps to mind as one possibility. Certainly the wireless networking could be used, but a data storm from an errant robot could bring down a match. Under controlled conditions it could prove very cool during auto.

If FIRST were to provide a server implementations and simple API for each of the cRIOs (with plenty of checks in place to limit maximum messaging rates), there would be some intriguing possibilities. Ultimately, though, I doubt that wireless inter-robot communications will ever be a part of the game because it would put teams who can’t afford to build multiple robots (or who can’t practice with many other teams during build) at an enormous disadvantage - they wouldn’t be able to even experiment robot communication until their practice day.

Not necessarily true.
With a common query / report protocol, a ‘dummy’ robot program could be set up in a PC. This would give all teams a chance to test their inter-robot communications without having a second robot.

The biggest hurdle that I see is limiting each teams bandwidth so as to not saturate the available bandwidth. This should be able to be accomplished through the FPGA and FCS.

The GDC would have to design a game around the robot-robot communication though … when I think about it, I can’t really come up with a way it would have given a team an advantage in any other year than 2008. In 2008 alliances could have used it to determine which bot left the gate first so there wasn’t a big crash-up down the stretch.

Things like opening a gate and signalling to the alliance that it’s open would be a perfect autonomous task.

Let me restate my intent:
Teams transmit a 6-digit number in the format #XXXX#, where XXXX represents their team number (using zeros to pad if necessary)
If we chose 1-1.5 khz for the lower frequency band, and made each character use 4 cycles as a minimum, then it would take 24 ms to transmit a message, and we could expect fairly infrequent collisions if robots transmit about every 100ms.

Using multiple receivers, other teams can determine where a message is coming from with phase data.
Actually, since I’m using sound, it would take 1/700th of a second for the signal to travel half a meter - less than the width of the robot. I know I can reasonably sample at 10khz with the analog inputs, so I could have 14 samples during the time it takes for the sound to cross the robot.

Rules aside, in order to pull this off, you’ll need a substantial number of teams to do the following:

  1. Have a transmitter or several to send out their number.
  2. Place said transmitter in a common zone, if the transmitter needs one.
  3. Have multiple receivers on their robot, again in a common zone if one is needed.
  4. Program the robot so that the transmitter and receivers communicate properly in automode.
  5. Have a robot (with or without an automode) in the first place, which too many teams struggle with already.

To get that number of teams, you’d need to a) convince them that this benefits them or b) get it required or c) get the GDC to have something in automode involving wireless inter-robot communication. There are simpler ways of detecting other robot positions in automode, like a rangefinder array around the base.

In addition, the following rules from last year would probably need to be tweaked:
<R03> (not technically a violation, but could be interpreted either way)
<R57>–you’re using wireless communication other than the modem to communicate from the robot. Could you argue that this isn’t a violation of the intent? Possibly. But I don’t think you’d get very far.

If you go back to 2008, <R64> is the same as 2009’s <R57>.

So, if you’re going to do this, you have to get the GDC to change the rules about communicating other than by the provided method to include an exception.

I now quote the 2009 manual, section

Friendly interaction between machines is acceptable if all teams are willing.
The full context reads: Courtesy
In order to make the most of practice time, there will be specified teams on a field during an assigned practice slot. Each team must be respectful of the other teams sharing the field. Friendly interaction between machines is acceptable if all teams are willing. Unsportsman-like conduct on the part of a team during practice could result in loss of practice time.
I can point to that exact quote in the 2008 manual as well.

In other words, you made an assumption based on a passage in the manual that has been around for years. We haven’t had robot-robot communication yet. As a matter of fact, the first few manual sections don’t change very much–maybe editing here and there, to allow for the new policies on things like the filler line.

It’s an interesting idea, like the ideaback in 2007 to have a “standard” hook and eye “crane” system to get bonus points. I’ll let you read the discussion to see how far that went.

Sounds like an interesting idea. There are a couple of problems you need to consider in the implementation though. As far as using phase to determine direction, one must remember that humans do that due in part to the shape of their head and the external ear or pina. We have spent a lifetime learning the relationship and a million years or so of evolution to get this far. On the field there are other problems that make it difficult for robots. The sound level in an arena and the reflections of the sound from objects and boundaries on the field are quite confusing. Multiple reflections will confound the best auto location. To make matters worse, robots that use Jaguars will have some output in the 15kHz switching range plus harmonic and sub harmonic energy in addition to all the mechanical noise in band. An ultrasonic transducer might prove to be a better choice to cancel out the noise environment but phase issues will still abound. Compensation will also need to take place for altitude. Although the speed of sound is roughly 1100 ft./sec at sea level, 70 degrees and 20% humidity, it changes as these variables change. Chicago is at 500 ft. and Denver at 5000 ft making the speed of sound quite different. Any judgment on speed and direction will need to compensate for these factors.

Eric, I can tell you put some thought and time into that post.

However, I have my justifications.
In the WPI Technical FAQ, I found this:

What are some of the benefits of the new controller?
Teams will have the ability to build more sophisticated autonomous robots, perform advanced control during the tele-operated tasks and a whole new realm of possibilities in future years including:

  • Object avoidance based on vision feedback
  • Communication among robots on the playing field
  • More precise robotic control

As for reliability and ease of implementation, testing will tell. I’m almost in Winter Break.