A common use case is to have multiple ultrasonic sensors on the same robot - eg to detect things to front, sides and rear. Given the backpack is mostly running idle and the range of the sensor is 3m this means that a respectable timeout can be assumed to be 20ms:
Speed of sound in air = 340m/s
Takes 0.0029s to travel 1m
3m travel takes 0.0088s
Round trip max (6m) is 0.0176s
Current pulsein timeout is set to 1000ms which is a huge overkill given the sensitivity of the sensor and expected time of flight on the pulse (with a bit of buffer in there too).
Given the backpack version uses an interrupt based approach to detect a pin change on a port, the plan would be:
Use pins on Port B (pins 8 - 13) giving up to 6 HC-SR04s that can be used on the backpack.
Port B is used because Port D has Pin 0 & 1 (TX/RX) on it and Port C is used for the I2C pins - if you need more than 6 then just add another backpack with up to another 6 on it and chain them (what are you making a digital Argus or something?!).
The backpack will round robin the sensors at about a 20ms frequency. Allowing for a little bit of slop in execution, ISRs firing and responses to read requests from the I2C handler we can assume each pin would take about 25ms average, thus 150ms for the whole port to run giving approx 6 RPS on all sensors.
This should be fast enough to detect things like approaching people, obstacles etc.
Data will go back as simply the register values where each pin is a 16 bit duration value in pin order 8->13 (12 bytes)
The johnny-five controller will need to be updated to return an array of distances when .cm and .in are called.
For simplicity and backwards compatibility, add an option called multi to the J5 controller constructor which defaults to false. If multi: true then an array of results is return for .cm and .in instead of the absolute value.
A common use case is to have multiple ultrasonic sensors on the same robot - eg to detect things to front, sides and rear. Given the backpack is mostly running idle and the range of the sensor is 3m this means that a respectable timeout can be assumed to be 20ms:
Speed of sound in air = 340m/s Takes 0.0029s to travel 1m 3m travel takes 0.0088s Round trip max (6m) is 0.0176s
Current pulsein timeout is set to 1000ms which is a huge overkill given the sensitivity of the sensor and expected time of flight on the pulse (with a bit of buffer in there too).
Given the backpack version uses an interrupt based approach to detect a pin change on a port, the plan would be:
Use pins on Port B (pins 8 - 13) giving up to 6 HC-SR04s that can be used on the backpack.
Port B is used because Port D has Pin 0 & 1 (TX/RX) on it and Port C is used for the I2C pins - if you need more than 6 then just add another backpack with up to another 6 on it and chain them (what are you making a digital Argus or something?!).
The backpack will round robin the sensors at about a 20ms frequency. Allowing for a little bit of slop in execution, ISRs firing and responses to read requests from the I2C handler we can assume each pin would take about 25ms average, thus 150ms for the whole port to run giving approx 6 RPS on all sensors.
This should be fast enough to detect things like approaching people, obstacles etc.
Data will go back as simply the register values where each pin is a 16 bit duration value in pin order 8->13 (12 bytes)
The johnny-five controller will need to be updated to return an array of distances when
.cm
and.in
are called.For simplicity and backwards compatibility, add an option called
multi
to the J5 controller constructor which defaults tofalse
. Ifmulti: true
then an array of results is return for.cm
and.in
instead of the absolute value.