Reflectance Array Support and "Shields"

[BrianGenisio]

I'm thinking of adding support for Reflectance Arrays. Specifically, I am looking at the Pololu QTR devides, but I think it should be generic. I'll probably send a PR based on a port of the Arduino Driver.

Since it acts more like a shield (takes up to 7 pins and is a composite device), I wonder if it makes sense to bring this into the five.Shield() abstraction in lib/definitions/shields like the AdaFruit shields we are talking about.

But these devices aren't really "Shields". And "Shields" aren't always the right word. BeagleBone uses "Capes", for example. I wonder if five.Shield() should be five.Expansion() to support any type of attachable "shields" as well as composite devices like these Reflectance Arrays.

Or, a generic five.ReflectanceArray() is more prudent.

Thoughts?

[rwaldron]

So, my Zumo and Reflectance Sensor Array arrived the other day and I was trying to find the discussion about it but came up with nothing. Glad you filed this :)

Since it acts more like a shield (takes up to 7 pins and is a composite device), I wonder if it makes sense to bring this into the five.Shield() abstraction in lib/definitions/shields like the AdaFruit shields we are talking about.

But these devices aren't really "Shields". And "Shields" aren't always the right word. BeagleBone uses "Capes", for example. I wonder if five.Shield() should be five.Expansion() to support any type of attachable "shields" as well as composite devices like these Reflectance Arrays.

@dtex has a good sense about organizational stuff like this, let's see what he thinks :)

Or, a generic five.ReflectanceArray() is more prudent.

Is it possible to observe one sensor at a time? If so, then IR.Reflect should be updated and then we can create IR.Reflect.Array that initializes each of the sensors via pin number array. This is a shot in the dark idea though, I haven't looked too deeply at the sensor itself yet.

[BrianGenisio]

Now we are getting into implementation details for the hardware again. :)

Because IR.Reflect is currently an I2C device where this Pololu array are individual sensors. I'm currently reading them using Sensor and for this device, yes, they can be individually read.

This particular device that I am working with (Analog 8x array) lets you use up to 8 individual analog pins as well as 1 "emitter" pin to turn on/off the IR LEDs so I am currently using the LED class for that.

They make a digital version of this hardware where you need to set the pin as OUTPUT/HIGH and then time the INPUT response. It will be a more complicated driver to write, and will likely require the "Ping" modification to Firmata to support. As far as I understand, the Zumo reflectance array that you (@rwaldron) have is a digital variant, so you will likely run into this issue if I am correct. I think it uses the same Arduino driver as linked above, so the difference in code between the two isn't huge (except for the whole timing thing, of course!)

I don't have a digital version in my possession (and I don't plan to), so I was only going to work the analog version of this hardware with an opening in the code for when someone wants to get the digital version working.

[dtex]

But these devices aren't really "Shields". And "Shields" aren't always the right word. BeagleBone uses "Capes", for example. I wonder if five.Shield() should be five.Expansion() to support any type of attachable "shields" as well as composite devices like these Reflectance Arrays.

Excellent point! Now is the time to get the language right and I wasn't being inclusive of other micro controllers.

I propose that we open a new issue/discussion dedicated to the new Shield/Expansion class dialogue. I'll migrate the conversation to date from this issue and Brian's PR.

[rwaldron]

Because IR.Reflect is currently an I2C device where this Pololu array are individual sensors. I'm currently reading them using Sensor and for this device, yes, they can be individually read.

That's fine. We'll need to refactor IR.Reflect to a device/controller pattern.

They make a digital version of this hardware where you need to set the pin as OUTPUT/HIGH and then time the INPUT response. It will be a more complicated driver to write, and will likely require the "Ping" modification to Firmata to support.

Uh oh. That "Ping" support was written specifically for the Ping device (despite protest). Devices that require arbitrary pulseIn/Out sequences break a fundamental aspect of hardware programming with Node.js: they're process blocking by nature (b/c: pulse, delay, pulse, delay, measure, etc)

I will purchase the analog version.

[markwest1972]

Hello!

This is a very interesting discussion for me as I was hoping to use Johnny-Five with my Pololu Zumo, which includes a QTR Reflectance Sensor.

Based on your discussion, it would seem that the chances of johnny-five supporting this are low, due to the blocking nature of this sensor. I just wanted to confirm this before I start looking into the alternatives.

Thanks for all the work you guys are doing with this by the way - you are enabling people like me to achieve a great deal!

Edit : @rwaldron is this the analog version of the array you mentioned?

Regards Mark

[rwaldron]

@markwest1972 the good news is that we can support the analog version as soon as I land @briangenisio's patch here: https://github.com/rwaldron/johnny-five/pull/497

[markwest1972]

@rwaldron @BrianGenisio Nice work! That'll certainly help me out! All I need to do is replace the digital Reflectance Sensor Array.

Thanks for your help!

[BrianGenisio]

Regarding the digital array, this is now the third device I've wanted to use (in addition to Ping) that uses pulse-length encoding (IR, RC Reciever, and Digital Reflectance Array).

I understand the problem... that it is not possible without a modified Firmata. I WAS able to get the RC receiver working with the Ping Firmata. I haven't tried IR or the Digital Array this way, but it is pretty clear that the Ping Firmata is geared especially towards Ping sensors who need a pin made writable for a short amount of time.

Is there any path forward? Is there a process that we can be a part of that will allow us support this? It would be awesome if StandardFirmata had the ability to measure pulse lengths... I just don't know much about who maintains Firmata, or what the blockers are.

[BrianGenisio]

@markwest1972 That IS the analog array I used to test #497 with. I just purchased 20 of them!

[markwest1972]

@BrianGenisio yep I saw that when I took a look at #497. Did you use a Zumo as well?

EDIT : Now I see that you built your own robot. Cool!

[rwaldron]

Is there any path forward? Is there a process that we can be a part of that will allow us support this? It would be awesome if StandardFirmata had the ability to measure pulse lengths... I just don't know much about who maintains Firmata, or what the blockers are.

We're (which includes you) are already part of this process :) https://github.com/firmata/arduino/issues Right now @soundanalogous is our main man and he can better explain the big picture issues with supporting pulse-centric devices.

[rwaldron]

We did this! Hooray!