To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.handyboardOpen lugnet.robotics.handyboard in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / Handy Board / 3327
3326  |  3328
Subject: 
Re: Sonar questions (technical ones!)
Newsgroups: 
lugnet.robotics.handyboard
Date: 
Thu, 26 Feb 1998 21:55:30 GMT
Original-From: 
Fred G. Martin <FREDM@MEDIA.avoidspamMIT.EDU>
Viewed: 
1468 times
  
Good questions!!

1: The speed of sound has been widely quoted to be 0.9 ft/ms (274m/s),
   but my Physics text lists it as 343 m/s (at 20C/70F), which is about
   1.13 ft/ms, or 25% faster.  So why the 0.9 value (or just cuz
   the Polaroid guys say so)?

The polaroid number/widely quoted number is 0.9 MILLISECONDS
PER FOOT -- or 1.11 ft/ms.  hence the conversion matches!

I think also I have this wrong on my HB sonar page!  This confused me
for a while too.

2: The sonar routines (e.g. sonar_sample()) return the distance as an
   int, meaning the greatest round-trip distance possible is 32768
   half-microsecs, or 8192 microsecs one-way.  By my math, 8.2ms is
   about 3m (10 ft).  Is this our max distance?  Any way to improve
   this?

Yes, this is correct.  The routines would have to be smarter to deal
with longer time periods/distances.

3: My sonar works well, but about 10% of the time it returns a spurious
   low value (around 2200 counts/8 inches), even if nothing has moved
   or changed in the environment.  I have written a kludge to simply
   re-pulse if it receives such a result, which works fine, but it's
   ugly and I'm just treating the symptom, not the cause.  Any ideas
   why this is?  (I'm using sonar_closeup(), BTW)

I've always chalked this up to "sonar is flaky."  i haven't
played with it enough to better characterize it.

anyone who has some more sonar experience would be welcome to
contribute observations here.

4: I'm confused by the guts of the sonar routines.  The start_time is
   read from the system TCNT register as a 16-bit integer (max 32768
   counts).  If TCNT increments 2,000,000 counts/sec, does this mean
   TCNT rolls over every 16ms?  If so, it seems quite likely that the
   counter will roll over while we're waiting for a pulse to return
   depending on when we peek it for the start_time.  However, the
   routines work fine, so can someone please clear up my
   misunderstanding?

As a 16-bit number TCNT's range is 0 to 65535, or 32.768 ms of time.
I don't think I quite understand your question here, but remember that
the actual time of TCNT when the ping returns is automatically
captured by the 6811 timer system and stored in timer 3's TIC3
register.

So while we're waiting for the return pulse, it doesn't matter how
long after it occurs that we make the calculation, b/c the value is
already captured.

Fred



Message has 1 Reply:
  Re: Sonar questions (technical ones!)
 
(...) Yes! I have been working from your sonar page, but as a sanity check I checked the Polaroid sheet again. Whoops! At least we were both tripped up by it. I'm used to seeing the "speed of sound" (ft/ms) quoted, not the "slowness of sound" (...) (27 years ago, 26-Feb-98, to lugnet.robotics.handyboard)

Message is in Reply To:
  Sonar questions (technical ones!)
 
Hello everyone, A few sonar questions (other than where to buy them): 1: The speed of sound has been widely quoted to be 0.9 ft/ms (274m/s), but my Physics text lists it as 343 m/s (at 20C/70F), which is about 1.13 ft/ms, or 25% faster. So why the (...) (27 years ago, 25-Feb-98, to lugnet.robotics.handyboard)

6 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