View Full Version : Inter-robot communcation
Apparentally we get to have the robots cooperate.
Friendly interaction between machines is acceptable, if all teams are willing. (http://usfirst.org/uploadedFiles/Community/FRC/Game_and_Season__Info/2010_Assets/03_At%20the%20Events.pdf)
Judging from the response I got on ni.com/first (http://decibel.ni.com/content/thread/4953?tstart=0), I don't think it will be through the robot radio this year.
What about the IR boards from 2008?
Vikesrock
06-12-2009, 19:13
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.
1986titans
06-12-2009, 19:42
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.
demosthenes2k8
07-12-2009, 15:38
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.
Daniel_LaFleur
07-12-2009, 16:50
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 ... :P
demosthenes2k8
07-12-2009, 16:53
HELO t1729
Hello t166, I am glad to meet you
>> POSITION t166 0 0
...*shudder*
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.
Daniel_LaFleur
07-12-2009, 21:47
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 :D
... now back to that protocol :p
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.
Al Skierkiewicz
08-12-2009, 08:02
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.
Jared Russell
08-12-2009, 08:23
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.
Daniel_LaFleur
08-12-2009, 09:00
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 3.6.1.3:
Friendly interaction between machines is acceptable if all teams are willing. The full context reads:
3.6.1.3 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 idea (http://www.chiefdelphi.com/forums/showthread.php?t=51043)back 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.
Al Skierkiewicz
10-12-2009, 07:44
Marshall,
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 (http://first.wpi.edu/Images/CMS/First/2009FRC_CS_FAQ_Technical_Rev4.pdf), 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.
Eric, I can tell you put some thought and time into that post.
However, I have my justifications.
In the WPI Technical FAQ (http://first.wpi.edu/Images/CMS/First/2009FRC_CS_FAQ_Technical_Rev4.pdf), I found this:
Yes. And when you asked NI, they said that capability wasn't in the cRIO. So you have to go the sensor route (or over the supplied network). I doubt the network will work, so sensors and transmitters are the only way. And now you have to edit rules, as I said before.
Unless:
Picture the following scene: 6 robots are on a wide-open field. All have Axis cameras on turrets. All have a spec number board in a specified area. (Spec board: Use part XXXX --a reflective number panel--from Home Depot.) Code has been previously released to identify and locate numbers. The match begins with a X-second ID period--cameras turn, looking for numbers. Then automode begins, and the robots get moving, targeting opponents and avoiding allies.
To sweeten the deal for teams, the number board is one of the four required team numbers. Or you use a color panel, red or blue.
If I did use a transmitter, I'd probably avoid ultrasonic (see Al's post above) and IR (see the 2008 discussions--cameras in the audience can mess with the signals). A laser might work, but would need a special clearance from the GDC (aka rules tweaking). LED array, maybe?
What I'm trying to say is, you'll need to think carefully about the technical aspects, all of them, both rules and otherwise, before you go with this.
Al Skierkiewicz
10-12-2009, 21:21
Eric,
I can speak to the use of lasers. They have been prohibited in the past regardless of their visible or invisible radiation. From 2009 Rev J of the robot rules...
<R02> ROBOT parts shall not be made from hazardous materials, be unsafe, or cause an unsafe
condition. Items specifically PROHIBITED from use on the ROBOT include:
B. Speakers, sirens, air horns, or other audio devices that generate sound at a level sufficient
to be a distraction or hindrance affecting the outcome of a MATCH
C. Any devices or decorations specifically intended to jam or interfere with the remote sensing
capabilities (including vision systems, acoustic range finders, sonars, infra-red proximity
detectors, etc.) of another robot (i.e. changing ROBOT color to confuse opponent’s vision
system)
D. Lasers of any type
I left in certain references to this discussion for your enjoyment/frustration.
BTW, how is the weather at school? It was 1 degree F overnight here. Very unusual for this time of year.
Eric,
I can speak to the use of lasers. They have been prohibited in the past regardless of their visible or invisible radiation. From 2009 Rev J of the robot rules...
<R02> ROBOT parts shall not be made from hazardous materials, be unsafe, or cause an unsafe
condition. Items specifically PROHIBITED from use on the ROBOT include:
B. Speakers, sirens, air horns, or other audio devices that generate sound at a level sufficient
to be a distraction or hindrance affecting the outcome of a MATCH
C. Any devices or decorations specifically intended to jam or interfere with the remote sensing
capabilities (including vision systems, acoustic range finders, sonars, infra-red proximity
detectors, etc.) of another robot (i.e. changing ROBOT color to confuse opponent’s vision
system)
D. Lasers of any type
I left in certain references to this discussion for your enjoyment/frustration.
BTW, how is the weather at school? It was 1 degree F overnight here. Very unusual for this time of year.
I did mention that it would take a special clearance, AKA rules tweaking (specifically the quoted rule).
As for weather, it was nice and warm, last month. As soon as Aero got a prototype flyable, though, it went cold and snowy. We haven't been above freezing for over a week. (right now: +3F. Expected: 0F, without the windchill. It's thawing out a little bit.) More like what we're used to than November was.
Tom Line
11-12-2009, 09:02
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.
There are other easy ways for robots to communicate. We have a vision system that is VERY good at picking out self-lit objects. So... if a scheme were worked out by FRC and released for a couple LED lights where each LED meant you were performing a certain task, and these were placed in an easily-seen portion of the robot, it would be fairly simple to use the camera to monitor which robot is performing what task.
I think my last post was inadequate, so i'm elaborating, and trying to be as clear as possible.
I'm 16 years old and a Certified LabVIEW Associate Developer. FIRST has given me the opportunity to learn things with robotics that I couldn't learn anywhere else. I competed in Atlanta. I've been mentored by an industrial controls engineer. I'm now a programming mentor for a rookie FRC team. I'm very grateful to FIRST for these opportunities.
However, I feel that we're not realizing the full potential of our Programmable Automation Controller, or the urgency of our situation.
Around us military robots are growing in popularity and sophistication, and yet it feels like we're standing still.
Future military robots will have redundant communication systems so they can make actions based on the position, objectives, and status of other robots. Robots needn't be stuck with the same weapons or tools all the time; they will have standard tool changers to switch tools or weapons when needed. These robots will evaluate situations faster than soldiers and travel faster than soldiers. They will be able to stay dormant for long periods of time, or be embedded into the terrain. They will recognize individuals through both vision and sound. They will compile data on a target, perhaps even simultaneously – data on position, objectives, offense, defense, and support – in order to determine how to deal with the target.
Some think this is science fiction.
However, there's clear evidence that this is where the country is moving. The DARPA grand challenges showed huge development in autonomous navigation in just three years. Boeing recently dove into military robotics. National Instruments has now created sales packages specifically for robotics development. Northrop Grumman and Rafael aren't the only ones with a stake in the field.
Many will think using unmanned drones on soldiers to be inhumane. We should all know we can't trust warring countries to be humane. We must create military robots to protect our soldiers from their drones.
Last year's competition, Lunacy, focussed on target detection, ranging, and firing on moving targets.
Yet we had human players that undermined the importance of any autonomous more advanced than "move away from the edge of the field". The autonomous section was 15 seconds long, and served more as an advantage to human players than a push towards technical prowess of teams. (it was easier to score on autonomous robots because they travelled in simple and predictable patterns, and weren't very field-aware) Due to the height of the trailer "flags", the camera could not view trailers both close and far without a yaw tilt or a fisheye lens, and so seeing the trailer in the first place became a challenge.
Teleop, in comparison, was given two full minutes, in which the robots were controlled almost exclusively by the drivers. When the effectiveness of our robot is gauged by the skill of our drivers, we know we don't have much more than a large RC car.
Unfortunately, we don't need a generation of engineers that are excellent at building RC cars.
My generation is the generation of programmers and engineers that will create the technology for swarm autonomous military robots that outperform humans on land, at sea, and in the air.
I understand that in six weeks, it's not usually possible to make an autonomous more effective than a human operator. However, every year the game should necessitate autonomous, and every year the autonomous should improve. The primary way for that to happen with is through the sharing code and ideas each year. I strive to "level the playing field" between rookies and veterans not by making innovation insignificant, but by helping teams get started and giving everyone the resources they need to build upon what has already done. Innovation and new development should be the norm.
This year I expect to move forward. I'm encouraging innovation and creativity on the team level, taking advantage of opportunities that may not have been considered, and were not specifically excluded. Having a good robot at regionals is not an end in itself. Lets push for robot autonomy, whether this means
developing methods of communication between robots,
or publishing code that will track a robot's location and tell it when it is in a predefined region (or a carrot routine to tell it which direction the next region is in),
or getting local teams together to agree on signage on a robot to make it easily identifiable by camera,
or by agreeing upon an IO spec so that features developed by different teams can easily be integrated into your own robot.
I applaude people like Daniel LaFleur who are are looking forward and trying new ideas, searching for more effective methods.
Through this we can find the full potential of our control system, both as a programmable automation system, and as a tool for developing effective and collaborative engineers.
To the end of furthering inter-robot communication, within the 2009 rules (and 2010 as soon as they come out), we need to define:
1) what we have to work with, outside of the cRIO;
2) Given what we've found in 1), what options we have for communicating;
3) What the best option(s) found in 2) are;
4) What we need to get those option(s) working.
We have a large number of sensor types, experienced programmers, inexperienced programmers (who would presumably need quite a bit of help to understand what's going on), a large allowed materials list, and the most helpful of all, ingenuity. In other words, it's simpler to define what we don't have:
Access to the field wireless. It's safest just to assume that, partly because that simulates a break in normal communication with X military drone, which must be reestablished by other means.
Use of lasers or other hazardous materials.
Knowledge of the field, to figure out lines of sight if those are needed. (We will have that, come January 9. We can also figure out how to avoid need of that knowledge.)Now, the various options that have already been posted, given the sensors and such like available:
Ultrasonic receivers/transmitters.
Camera looking for a panel.
Light sensor array or camera looking for Morse code, paired with, say, cold cathode tubes. (LEDs would have to be carefully aimed--they're pretty bright.)
[insert your own ideas here]Of course, any list developed here is subject to change.
On a practical note, think of the advantages that could be gained from all the robots on the same alliance coordinating autonomously the last few years:
2006: Three robots go to different points, or play defense, depending on what a standard code says, without running into each other.
2007: Would be nice to not go for the same spider leg with keepers...
2008: Run different routes at different times, blocking opponents as needed.
2009: Anyone for a three-robot track, pin, fill sequence on one trailer?
2010: ???????????
The location of other robots and who's where is just the first step. Given a year or two or three, we could be setting up a mini-network that communicates what each will do to their partners but not their opponents, and then does it allowing for all partners to play a big role.
Al Skierkiewicz
16-12-2009, 08:33
Marshall,
I applaud your desire to improve and you certainly sound very intelligent and advanced for your age. You do need to consider, though, the entire group. Auto mode is not something for the faint of heart and the use of a fully auto robot competition will lock out some of the teams that need the challenge FRC currently supplies. If you look at the data, I think you will find that number of teams that actually run auto code is not as large as you would hope. Teams with no access to programmers of your magnitude or drive will be unable to compete, which is contrary to our founder's stated desire to bring this competition to all high schools in the US and then the world. Further, it is extremely important to maintain a public presence. In a fully auto mode competition, there will be little to draw in the public. We are still part of a society that desires human challenges. All of us want to see our teams compete with humans controlling the beast and someone winning. When a NASCAR event takes place, there is little fanfare for the car and some for the pit crew, but a huge ceremony for the driver.
Yes we are in a competition to develop auto mode robots for industry and military, that will be superior to our enemies. To that end, we need to inspire students like yourself, to learn and train in science and technology. Given the excitement of students involved in building a robot and students driving a robot, I think we are doing a great job in preparing our youth to take on the challenge of building auto mode robots.
DavidGitz
16-12-2009, 10:32
Eric and Marshal - I think this is a GREAT idea. Here are some of the issues that we would have to overcome:
-Physical detection of other robots, using sensors.
-Programming on each robot that is capable of performing a useful task but is basic enough for rookie teams to implement.
-Perform the detection, decision and action items accurately and quickly but still allow for human intervention (during the teleop mode) .
As any good engineer, when we see a problem we try to solve it! If we could implement this it would be a great tool for rookie and veteran teams alike.
Jon Stratis
18-12-2009, 15:23
kamocat - That was a nice, impassioned post. I certainly hope you won't lose that passion, as it will help drive you towards what will most likely be some great accomplishments.
However, FIRST is not a race towards designing the biggest, baddest robot on the planet. It's about teaching and mentoring, about inspiring and recognizing talent.
Many students come into the program with little to no experience - They've never programmed before. They've never held a soldering iron or a wrench. They've never done calculations on moment or center of gravity or turn radius or torque. They're interested, and it's our jobs as mentors to give them the tools they need to be successful, not push them into hysterics.
As a program, FIRST drives towards presenting challenges that can engage the best, most experienced teams, while still allowing anyone else with a will or passion to succeed. Robot to robot communication and cooperation is, simply put, complicated. Sure, the best x% of teams (i would guess 5%) could probably figure it out and get it working reliably... but then the rest (95%) wouldn't succeed. They would meet with frustration and disappointment.
I don't want to discourage you here - It's great that you want to pursue this type of stuff. But in order for it to make it into a FIRST game, you need to first figure out how a team with no programming experience and no programming mentors could succeed with it. Because there are teams like that out there, and with todays setup they are able to succeed, although it is very difficult.
eovnu87435ds
10-01-2010, 16:47
This sort of thing could prove to be something really cool. I don't see it going into effect this year, but the best way to do this is to start the movement yourself. Create the code to do it, even if it break's FIRST's rules. at that point, do not use it in the competitions, but demonstrate it where and whenever you can. Post the source code online, and some sort of list of teams who have gotten it working with their robot as well. Get in touch with teams who will be going to the same regionals, and show them how to make a copy of the code that will work with robot-to-robot communication.
I can see that if a large number of teams show that they can do it, FIRST may adopt it. I doubt it will be used for something like the IR was used for in overdrive, but it would be standardized and available to teams to communicate/coordinate between robots.
This is For Inspiration and Recognition of Science and Technology. You became inspired, now create it and get recognized, and the best way to do that is with strength in numbers.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.