 | | RE: Ooops! NXT Software Comparison correction
|
|
(...) After tuning, NBC achieved 73K test cycles. It achieved these great results by setting the task "priority" to 200. Unfortunately, unless the NXT-G task scheduler has been rewritten, these results might be a little too high. A NXT-G task (or (...) (17 years ago, 6-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)
|
| |
| | 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: US-Sensor I2C-address
|
|
(...) To my knowledge the LEGO Ultrasonic sensor does not support changing its I2C address. IIRC it is hard-coded to 0x02. I do not think it is ADPA-compliant. John Hansen (17 years ago, 5-Sep-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Ooops! NXT Software Comparison correction / I2C Messaging Speed
|
|
(...) 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 (...) (17 years ago, 5-Sep-07, to lugnet.robotics.nxt)
|
