To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 25984
25983  |  25985
Subject: 
Re: Ultrasonic sensor interactions
Newsgroups: 
lugnet.robotics
Date: 
Sun, 21 May 2006 09:31:58 GMT
Viewed: 
2469 times
  
The problem here is the management of a single shared resource, i.e. the air through which the ultrasonic signals travel. The lack of a Bluetooth broadcast mechanism makes the implementation of a conventional resource locking system difficult, but not impossible.

A similar situation exists in Ethernet communication where a set of communication channels must be implemented over a single physical cable, optical fibre etc. This is achieved without using a separate communication mechanism to achieve locking.

When an Ethernet interface wishes to transmit a packet, it first listens to see if the “Ether” is in use. If it is, it continues to listen until the “Ether” is quiet. If the “Ether” is not in use it transmits the packet but listens to see if the packet is corrupted by a “collision” with a another packet from a different interface that has started to transmit at the same time. If there is a collision, it waits for a randomly selected interval and then repeats the whole procedure until the packet is transmitted successfully. All packets are transmitted in full weather or not a collision occurs to ensure that all senders detect collisions. In this environment “collisions” are a normal part of network operation. This is called “carrier sense multiple access with collision detection” (CSMA/CD).

I wonder is the characteristics of the ultrasonic sensor might permit something similar. It must be able to listen to see if the “Ether” (the air) is quiet, but could it detect “collisions”? If this is possible, the next problem concerns the relatively low bandwidth of the ultrasonic channel compared to even the slowest Ethernet. It might be that, in order to avoid deadlock, the collision back-off times would need to be quite long, e.g. several seconds. If this is the case, the rate at which an individual robot could sample its ultrasonic sensor data might be too low to be useful for navigation purposes. I suspect that this last problem may be the limiting factor for any implementation of a suitable locking mechanism.

Perhaps someone with access to a detailed sensor spec, or the real thing, could investigate.

Arthur Clarke



Message has 1 Reply:
  Re: Ultrasonic sensor interactions
 
(...) The 'Aloha' protocol was the predecessor of this. (...) Someone earlier told us that the thing runs all the time and can't even be shut off. That being the case, I think we're pretty much doomed. (...) Yes - but the relatively low frequency at (...) (18 years ago, 21-May-06, to lugnet.robotics)

Message is in Reply To:
  Re: Ultrasonic sensor interactions
 
(...) This is a great idea except for one very important item: there is no such thing as a broadcast message (ie: a message sent to everyone) using Bluetooth. So for any such system to work, each robot has to know about every other robot, and send (...) (18 years ago, 21-May-06, to lugnet.robotics)

27 Messages in This Thread:










Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR