For teams using an ultrasonic sensor and sensormux with RobotC V3.54 you’ll find it behaves differently. In V3.51 (and previous versions) the ultrasonic (sonar) sensor measured distances in the range 0…254cm and returned a value of 255 if there was no reflective object in its path. With V3.54 it now returns a value of -1 (negative one) if it has nothing in its path, and measures reliably only from 0…127cm. Beyond 127cm it returns negative numbers.
With RobotC V3.51 and the corresponding drivers (3.0b) we can successfully read a LEGO US sensor through the HiTechnic sensormux. By successfully, we mean we get values in the range 0…254 and then 255 when there is nothing in range.
With the same program in V3.54, which of course comes with the latest (3.1) drivers, the numbers in the range 0…127, then at that point the distance goes negative (-128, -127, -126 etc etc. ) Additionally, with nothing in range we now get a value of negative one (-1) from the sensor driver instead of 255.
We wasted a serious amount of time today debugging code that had previously been working, so we are hopeful for a quick fix before our upcoming competition in 6 days. We’d rather not revert to V3.51 as we’re scared by the number of bugs that have been fixed in V3.54.
Additionally, we are seeing some very peculiar behavior from the HiTechnic gyro via the sensormux when using V3.54. Again this is with last year’s code that had already been working this year, but we haven’t managed to figure out exactly what’s going on with that yet so we just mention it in the hope it is related to the problem with the US sensor. Essentially, if we display the integrated gyro on the NXT screen and manually rotate the robot SLOWLY through 90 degrees everything is hunky dory. But if we rotate the robot FAST through 90 degrees we get some a really huge random number instead of 90 degrees. Is it possible that higher analog values from the fast rotation are getting wrongly interpreted as signed numbers and throwing the calculations haywire? Again, this code worked previously and when we say rotate the robot “fast” we’re not talking crazy fast, just not at a snails pace (which works).
We’ve reported the problem to RobotC - hopefully they’ll come up with a quick resolution.