I've been holding off on an official component list until I can stabilize the build a bit more, but I wanted to mention a few things that have occurred since the original plan was hatched, and some of the design decisions involved.

Without delving too much into the history, I will just say that at one point I was coding a very simple speech recognizer to run on the ATMega328P, and I was able to create some code that was about 85% effective at recognizing a handful of carefully selected keywords that were pretty distinct in their pronunciation. That was the true positive rate. There was also a high-enough-to-be-annoying false positive rate, which would trigger my “initializer” (more on that at a later time). Anyway, I was getting sucked into the details of speech recognition and optimizing for a tiny processor, and this is really not the area where I can add the most value. So, I moved to R.Pi, to try to implement open-source speech recognition using Pocketsphinx, like many other builds. It meant having to use an SBC w/ Linux in addition to the ATMega328P based board, but for this usage I was not so space-constrained so that was OK, even with the added cost and power usage. Also, moving to Linux enabled speech synthesis as well, using festival. Before, I was playing out pre-defined sound files containing sounds and canned speech responses. But I wanted a more general interface, one that could recognize more than a handful of pre-defined keywords, and trigger more than a handful of pre-defined sounds. Ultimately I moved on to BeagleBone Black as the SBC for performance and I/O, but this is just for these Integron units. Other Reactrons that don’t require all this library support are fine on R.Pi, or just stand-alone ATMega328P, or even stand-alone Android devices, based on the specific application.

A Reactron is defined by its communications protocol and internal data structure, not by its specific hardware complement. I wanted to mention that while my header image shows a panel of ATMega328P boards (based on the Moteino by Low Power Lab), Reactrons are not Arduino clones, though their hardware complement may contain one, several, or none. I chose the image because to me, it evoked “many small computers working together”, which is what the Reactron network is all about. In my other images, you will see a multiplicity of BBBs and R.Pis and other hardware, as the mix of hardware for a generalized Reactron completely depends on its purpose. For instance, some existing Collector units are purely BBB boards with attached sensors, and the software to support the Reactron interface. Some Recognizers are just BBBs running statistical calculations on inputs from Collectors - without any directly attached auxiliary hardware. I haven't had a chance yet to write much about Recognizers, but that is coming soon.

Moving on to some of the changes, specific to the Integron unit:

One excellent thing that has changed since I started this project is that the Moteino has been upgraded. [Felix] at Low Power Lab has informed me that all new R4 Moteinos are now shipping with the MCP1703 voltage regulator. This is good news for me, because now I am able to just add “Moteino” to the components list, instead of a board "based on the Moteino", where I would have to do have a separate BOM and so forth. Now, you can just use a stock R4 Moteino (with HopeRF radio and a 4Mbit flash chip) for any of my projects that require an RF enabled ATMega328P-based solution. At the time I started this project, the Moteino was shipping with the MCP1702 voltage regulator, and that meant that using a then-stock Moteino in my 12+V projects (like the Reactron water pump or the newer Automobile Integron) might have resulted in a puff of smoke and little else.

I would also like to direct your attention to the fact that [Felix] has entered THP with the Moteino Framework, and you should go there and give him a skull. [Felix] is simply amazing and creates an enabling technology for many, many cool projects, including mine, and you should visit his site and forum to check them all out. I'm so happy to have the RF/ATMega portion of my network running on this robust design!

Another big change is that the BeagleBone Black went from Rev B to Rev C, and in doing so changed their onboard eMMC chip from 2GB to a faster 4GB one, and this means that it can just run Debian without having to boot it from a larger SD card on the Rev B, which was a minor hassle.

Other hardware changes involve the audio components. Mostly it has been involving testing out different microphones for response, since it appears that sensitivity specifications are merely suggestions on what might be. I do not have final components on this yet, still experimenting to find the best one (at a good price).

One of the components is essentially optional, that being a USB hub. The Integron unit uses an inexpensive USB sound card to play sounds and listen for speech. The BBB has a single USB port, and that is sufficient for this usage. However, I realize that not everyone might want to use the wired Ethernet connection, which means that a USB hub would be necessary in order to have ports for a USB WiFi adapter as well as the required USB sound card. So I have been experimenting with what USB hub to use, and it comes down mostly to shape factor, since this all needs to fit within a certain envelope. There isn’t really room to plug a bunch of stuff into the USB port with their relatively enormous connectors, so it comes down to soldering jumpers from the BBB board itself to a protocape, and splitting USB out from there, locally on the proto board.

The BBB I am sourcing from Adafruit, along with the BBB protocape and other components. I have decided to try to standardize on NeoPixels as much as possible, just because of the flexibility. This statement is valid only for Reactron projects that include an Arduino clone, because of the timing constraints with the execution of commands to those modules. Details will be forthcoming as soon as more of this gets locked down and stabilized.

Some of the design considerations are as follows:

In addition to the NeoPixel timing constraints, any of the timing-sensitive requirements will require an Arduino clone, which I will standardize now on the newer R4 Moteino. (From a standardization standpoint, in my opinion, and in this specific case, it is preferable to add a Moteino and maintain one library, than to port things to run on the BBB PRU and maintain a second library.  I have many more nodes with just a Moteino and no BBB, than I do with a BBB and no Moteino.  And generally, the standalone BBBs tend not to require auxiliary, timing-sensitive components. I do not mind re-evaluating this decision if a special case arises and it makes sense to do so.) 

For the Integron unit, in addition to the data processing, audio, and RF comm modules, we have NeoPixels, PIR sensors, an HC-SR04 sensor, and a small screen (still working on the specific model, but either TFT or OLED, likely sourced from Adafruit). As discussed, the NeoPixels will need to run off Moteino due to tight timing requirements, but the PIR sensors are just for human interaction (slow) so can probably run right on the BBB ADCs. The screen can be run via SPI, so that can run on BBB as well, though other implementations with no BBB may use screens on SPI using Arduino compatible libraries. The HC-SR04 sensor is timing-sensitive so will also run from the ATMega328P. Many libraries are provided by Adafruit, and I'm very happy to integrate with their robust designs.

After a lot of research on a totally separate project, I am considering replacing or at least augmenting the gesture sensing with vision, using camera-based sensing, and stereo audio. Ultimately the Integron unit should be made available in several form factors. The one I am describing here is a desktop unit (movable), but there will be others, such as wall-mount, ceiling mount, and the entirely separate Automobile Integron, among others. I’d like to have as much modular overlap as possible, so each thing is not unique, but rather draws from a common design. At minimum, there is a common design philosophy, even if there are differences in execution due to practical concerns.

More details will be posted soon, in the system design document.