TeslaIaint:
Hi Tim,
What object do you use to for your ultrasonic sensors to sense? Could you describe the conditions? I'm gonna try your library soon on my maxbotix sensor soon. It's wired the same way, so hopefully it works.
Objects can be named whatever you want, and you can use any number of objects. I use "sonar" for the object name in the Example Sketch. But, in the Two Ping Sensors Example Sketch I use "sonar1" and "sonar2" for the object names. I would imagine that most people would use "ping", "radar", "sonar", "ultrasonic" or something like that for the object name. But, you could have the object named "maxbotix" and have any number of objects defined, think "look_left", "look_right", "look_ahead".
The only condition is NO_ECHO, which is defined to 0 (false) meaning there was either no ping, or the ping was outside the set range. Basically, the NO_ECHO (false) condition is that there wasn't a ping. Other than that, it returns the distance or the ping time (depending on what method you used).
With the next release, there will also be at least one type of interrupt-based ping. The event-driven methods won't have a NO_ECHO condition. Because, as it's event-driven, there will only be an event when there's a ping echo within the range specified (the only condition will be that there's something in range). Basically, the goal of the event-driven methods is that you set a range to say 100cm and then you're off to the rest of your sketch, doing whatever the real goal of your sketch is. When the ping condition is met (something within 100cm let's say) you then do whatever action is needed in your sketch. You may have different things you need the sketch to do depending on what the ping distance was. That's up to your sketch to figure out.
Basically, there's two conditions, NO_ECHO (false) and echo (the distance to the object). For the interrupt methods, there's only "alarm" conditions, that something is in range, and obviously what that range is.
Tim