To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.nxtOpen lugnet.robotics.nxt in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / NXT / 920
919  |  921
Subject: 
Re: Ooops! NXT Software Comparison correction / I2C Messaging Speed
Newsgroups: 
lugnet.robotics.nxt
Date: 
Wed, 5 Sep 2007 20:40:16 GMT
Viewed: 
22298 times
  
In lugnet.robotics.nxt, <dickswan@sbcglobal.net> wrote:

I define "perfect" to mean that if the first value read was 22 cm then
all subsequent values are in range 21 to 23 cm and there were no I2C
bus errors. When I removed the 2 msec delay, then errors occurred.

The errors that occur are that the sensor does not properly report variable
distances as it is positioned at varying distances from an obstacle.  If you
slow down the read rate then it works correctly (i.e., with a wait of ~15 ms
between read transactions) but without that delay it does not accurately reflect
the varying distances as it should.  I'm not talking about getting bus errors -
just invalid distance readings from the sensor.

Can you re-run your tests and verify that you are getting accurate readings from
3cm to 255cm as the fast loop is executing and issuing read transactions faster
than once every 15 ms or so?  It's been a while since I ran into this problem
and added the wait to correct it, but my recollection is that every US sensor
and brick I tried with the standard 1.04 NXT firmware had this same issue.

If in RobotC you can get the US sensor to return valid distance readings at a
rate of once per 10 ms then the loop count limit in Steve's timing test for
RobotC is 6000.  Are you admitting to having cheated in Steve's timing test
results?  If you take the US sensor read transaction out of the loop then you
are doing something completely different than Steve's pseudo-code required - at
least, that is, if you are really interested in valid comparisons between
different development platforms.

John Hansen



Message has 3 Replies:
  Re: Ooops! NXT Software Comparison correction / I2C Messaging Speed
 
(...) I think I understand. In this case, the limiting factor is the US sensor itself, how fast it can ing and interprete a return. Or from my standpoint (a physicist), it's a fundemental limitation of the physics of sound, not a limitation that has (...) (17 years ago, 5-Sep-07, to lugnet.robotics.nxt)
  RE: Ooops! NXT Software Comparison correction / I2C Messaging Speed
 
(...) Nobody cheated or is dishonest. Everyone who writes firmware for the NXT is well-intentioned "good" people. Let's not mislabel good modern programming practice -- i.e. hardware device drivers integrated into the low-level firmware -- as (...) (17 years ago, 6-Sep-07, to lugnet.robotics.nxt)
  Ultrasonic Sensor iS "Slow"
 
Original Thread title was "Re: Ooops! NXT Software Comparison correction / I2C Messaging Speed". I've renamed as worth a separate thread. (...) You're right!! If you poll the sensor too fast, it definitely reports wrong distances. I'm doing some (...) (17 years ago, 7-Sep-07, to lugnet.robotics.nxt)

Message is in Reply To:
  RE: Ooops! NXT Software Comparison correction / I2C Messaging Speed
 
(...) I wasn't aware of this firmware limitation. I could not duplicate it when using the ROBOTC firmware. I've done three different test runs of 500K messages each with perfect results each time. Each test run used a different sensor. The delay (...) (17 years ago, 5-Sep-07, to lugnet.robotics.nxt)

13 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
    
Active threads in NXT programmable brick

 
Verified and Trusted Team of Hackers
11 hours ago
Custom Search

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