Ultrasonic linking?

So here is my thought… The college teams make their own partner robot and in gateway i would assume more than once in autonomous you would want both of your robots lined up nicely so one robot can give the other scoring objects. My thought is, could this be done with ultrasonic sensors? By having one sensor on each robot. Once the sensors are lined up their reading will suddenly change because they are reading the sound waves from the other sensor. Could this be even remotely possible? Or am i unaware of some property in the sensors that would prevent this?

Maybe you could use something as RFID. I dont think the ultrasonic sensor strategy is a good one.

Possible? Certainly.

However, as far as I know, nothing like that is built into the software libraries that come with the current commercial offerings on the Vex web site. You would almost certainly need to write your own sensor interface software that would bypass or complement the routines you get with EasyC and RobotC.

I believe the current off-the-shelf software only reports an echo that arrives shortly after the local sensor emits a ping. For that reason I think it would ignore any other pulses that the sensor detects.


Im not entirely sure if its a good strategy either :o, but i would at least like to experiment with them.

And as for the ping action you described, thats what im saying you would theoretically use. If the sensors were not lined up, the ping would come back after so long and you would get a reading of lets say 3 feet. But then the other robot moves its sensor across from the original one, and now when the original sensor emits its ping, it recieves the ping from the sensor across from it before its own ping can echo back. This gives it the minimum possible reading. Which I believe is 3cm. So you would tell your robot to wait until that happens to initiate whatever action you had in mind.

This is all in theory of course and as stated may not be the best strategy. However, if it is true that the ultrasonic sensors will read pings from other ultrasonics, could this be used as a defensive tactic? You send some ultrasonic waves in your opponents direction to trick their ultrasonic sensors and mess up their autonomous.

On the old PIC based controllers we have access to the source code in Microchip C. It was (and is?) a competition-legal programming technique for the high school competitions, and was very similar to programming an FRC robot. Which makes sense, after all, given that IFI had designed the VEX platform as a training platform for their FRC robot control system. VEX may have taken on a life of its own, but it was an awesome training platform for the FRC bots!

It would almost certainly be possible to program an ultrasonic sensor to send out a series of pings with defined timing between pings, and for another robot to measure the timing between the pings using Microchip C as you had interrupt level access to the controller. Actually, I don’t know why I’m talking in the past tense… you still do. I just don’t know how “low level” you can get on the new Cortex units… yet.


And the timing between the pings would get faster due to doppler shift as the robots approach at high rates of speed?

I think the OP has skipped over a few steps in the thought process.

Take one step back, assume communication is required between autonomous robots; discussion of methods:

  • quantum entanglement, too bulky
  • Radioactive particles, fails safety check, causes increased soft-error rate
  • E/M in the radio spectrum, not allowed
  • E/M in the near visible (IR) spectrum, OK
  • E/M in the visible spectrum, OK to use Vex flashlight or LED and light sensors, or semaphores and cameras
  • tactile senses, somewhat bulky, already lined up if robots can touch
  • Sound: ultrasound, OK, need some details worked out/
  • Sound: audible, May not be allowed as distraction
    But perhaps I misunderstood, and ultrasound is not being proposed as a communication method between autonomous robots.

Take two steps back, assume no communication is required between robots to line up; brainstorm of methods:

  • Synchronized timed driving : “Meet at the corner of the OK corral every 20 seconds”
  • closed loop Ultrasound: Cruise back and forth along the gate, with US looking through the gate, until near object (other robot) is sensed.
  • Tactile: reach through gate with docking alignment guide

Take three steps back, Robots pass Gobs between Zones; brainstorm of methods:

  • Robots communicate when and where to pass Gobs (Game Objects)
  • Robots line up to pass Gobs from hand to hand, synchronously
  • Robots move Gobs over the gate to floor, Asynchronously vs actions of other robot

One framework for evaluating methods is to consider Gobs as message packets in transit between sender and receiver, and consider: flow control, latency, throughput, efficiency of sender, efficiency of receiver, buffer sizes, buffer overflow.
These performance metrics are in addition to the usual robot project evaluations of Cost, complexity, reliability, robustness, motor/sensor/control ports required, and ease of use.

Looks like my work life is bleeding through to my Vex life…

I dont think the timing would be affected because the doppler shift doesnt affect the speed of the wave, just the frequency.

The Doppler shift up’s the frequency when the robots are moving towards each other. Because of this the time between waves arriving will go down because the waves are pushed closer together and so your timing would need to compensate for this.
However you could probably get by on quit a low frequency system as you don’t need to transmit lots of data, if you could get the frequency in a low enough range you wouldn’t have to worry about Doppler shift.


When the robots move towards each other the frequency of the wave gets higher, but the speed of the sound is the same so the mic will receive more waves at the same amount of time than when the robots don’t move, yet, i don’t see how this would affect a calculation of distance, since these calculations are not affected by the frequency of the sound.

Distance of a sonar = (Speed of sound)*(Time for the sound to get back)]/2

Yes but were not trying to detect distance here right, were trying to transmit data between to robots, I’m not exactly sure how this is done for things such as WiFi but if you were to try and do it with vex and ultrasonic waves and sensors I imagine you would encode data in different wavelengths hence frequencies so to robots moving robots could alter it enough to make it kinda hard to transmit data depending on required frequency.

also I said a low frequency system might be good however I think it might be better to have a high frequency system to avoid the affects of Doppler however that would be harder to code I guess


Find a very good escorts and courtesans in Geneva, Zurich and Dubai. The finest in Switzerland and the United Arab Emirates.
Dubai escorts
Geneva escorts
Zurich escorts