|Ultrasonic Reading of -1?
|Page 1 of 1|
|Author:||sifu [ Sun Jul 28, 2013 12:42 pm ]|
|Post subject:||Ultrasonic Reading of -1?|
While doing trying to run my robot for Sentry Simulation II, after clearing the first obstacle, the ultrasonic sensor will read -1 and stop the robot(as it runs in while loop whenever the reading is above 25). The ultrasonic sensor, I think, shouldn't even be able to read -1, only 0-255. So I think this might be a bug? And just in case, I attached my code.
Edit: Used google, and found another poston this forum on the same problem that said a reading of -1, indicated nothing to detect, but the RobotC wiki here:http://www.robotc.net/wiki/NXT_Sensors_Overview
states that a reading of 255 indicates out of range/no detectable objects. Do the sensors function differently in physical form compared to RVW? Or am I just understanding it wrong :p?
|Author:||rcahoon [ Sun Jul 28, 2013 6:27 pm ]|
|Post subject:||Re: Ultrasonic Reading of -1?|
I believe the sonar sensor code was originally written based off of the VEX Sonar Sensor, which returns -1 when no object is detected. I believe we've left it that way for NXT, despite being not quite the same behavior as on the physical hardware, because it makes it easier to distinguish between the "no object" and "object very far away" cases. Due to technical reasons (I've included an explanation below, if you're curious), there's a fairly simple fix for this: simply prepend (ubyte) onto the front of your SensorValue expression, like this:
This shouldn't change the behavior of the code on the physical hardware, but will make the virtual sensor readings match the physical readings
Computers represent negative numbers using something called Two's Complement Notation. There's plenty of good articles and YouTube videos on the subject (as well as binary numbers, if you aren't familiar with them), so I won't explain it here, but I encourage you to look into it more if you're curious. The critical part of this is you can get the Two's Complement Notation of a negative number by writing out the binary for the positive version of the number, then flip all the bits (change 0s to 1s and vice versa), then add 1.
The other necessary piece of information is that NXTs use 8-bit numbers to represent sensor values.
Let's try writing the 8-bit, Two's Complement Notation for -1:
We write the positive version in binary: 00000001
We flip all the bits: 11111110 - which is 254 in decimal
Then we add 1: 255 - or 11111111 in binary
So using 8-bit numbers, -1 and 255 have the same representation in memory.
So the only real difference between the VEX values and NXT values is that NXT uses 8-bit numbers and VEX uses 16-bit numbers, so VEX has enough bits that it's able to distinguish between -1 and 255. Putting the (ubyte) in front of the sensor value forces ROBOTC to treat the sensor value as an 8-bit number.
|Page 1 of 1||All times are UTC - 5 hours [ DST ]|
|Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group