I’ve built something similar to your WiFi car and intended to programme it for mindless autonomy i.e.
loop
drive forward
if close to something, turn until no longer
But the output of the sensor example code is erratic (whereas the ultrasonic sensor isn’t when connected to Lego’s own controller).
Just staring into space it returns values like this;
255,255,255,127,255,255,127,255
With my hand closer (stable position) I get much smaller values, but again jumping erratically;
20,21,20,20,57,128,22,20,21,85
Is the expected sensor output range 0(close) - 255(far)?
Is their any reason why the output would be so erratic? Could it be affected by power - following 9v battery power issues I’m powering the BrickPi from a jury rigged 8x 1.5v AA pack …
The NXT ultrasonic sensor does need the 9v input in order to work correctly.
0 or 255 means that either the range is too great, the sensor signal isn’t strong enough (inadequate power supply), there was an error in the communication with the sensor, or there isn’t a sensor reading available (you’re polling it faster than it can take measurements).
A possible reason for erratic readings would be if it isn’t getting a clean sound reflection. Try pointing it strait on with a wall or other smooth, hard, flat surface. Another possibility would be interference with another device in the vicinity (e.g. another ultrasonic sensor).
Sure, I’ll share a pic over the weekend. The setup is fairly rudimentary but it was a first test project. Lego’s ultrasonic rangefinder does appear to work and I think Mattallen37 has it right - I was polling the sensor far too rapidly in my basic sensor only test script.
It’s been a lot of fun so far and the combination of RPi/Python/BrickPi knocks the NXT native experience for six. But you really need to work on the accessibility of source code, rationalising comments within, and examples (scrub the ‘old’ code branch from the public repository for a start!) if you want this thing to immediately capture the imagination of ‘newbies’ to this territory. If you do I hope (believe) you’ll sell this in the thousands to all of us who bought the NXT and then found that the software prevents it from delivering the hardwares promise.
Tim, can you just point out some specifics regarding the code accessibility, like which examples you had problems with. We’ll do our best to make more user friendly.
8x 1.5v is 12v, which is higher than the recommended top voltage of 9.6v. I don’t know if the extra voltage would contribute to errors in the ultrasonic sensor readings.
Again I’d like to point out that if you poll the NXT Ultrasonic sensor too often (faster than it can take readings), it will return either 0 or 255.
Im actually looking to do something very similar to you Tim, recently I got some experience with opencv so I bought the pi camera and hope to autonomous bot with eyes. I am curious how you are going about it Tim.
No, because almost everything else doesn’t have this limit. Some errors the user-program should take care of, so that the user has more control. For the ultrasonic sensor (and all I2C stuff for that matter), I allow access to the errors from the user-program (so that the user-program can determine what to do). If you want though, I could change it so that the ultrasonic sensor value accessible to the user-program will only be updated with a non-error value.