Finally, whenever I tried to connect my 4 Pixycam for realtime coloured object tracking for the Teddy Robot, I experienced trouble wheter connecting them via USB (saturating the USB Host adapter bandwidth, or colliding due to a previously non-existing Pixycam Device enumeration), connecting them via serial or I2C to my micropython boards (bandwidth problem, not enough serial lines for 4 cameras), connecting them via SPI (previously no slave selection support on pixies).
Now with the NodeMCU board and SPI SS support in the latest Pixycam firmware, I managed to run the color object tracking code on only one microcontroller querying 4 cameras via SPI on one bus in full speed and even transmitting all the block data via Wifi to a websocket server.
With slower arduino or even maple or micropython STM32 boards this would have never been possible.
The websocket server has a low enough latency of 2ms, which is great via WiFi. When trying to relay the same data via MQTT I got a lot of stack traces again. One day I need to directly embed ROSserial via WiFi to see if the websocket translation into ROS can be omitted.
Another microcontroller finally found its way into my hands.
The ESP8266 based NodeMCU is running at 80Mhz (or even 160MHz) and has WiFi built in for a ridiculous pricetag of only 10 Euro.
Initially they come with an embedded LUA interpreter preinstalled, to allow some easy scripting of event based code rather than writing and compiling C code. As LUA is not completly reentrant after Wifi events and also consumes a lot of processing power, my projects will be further written in C, so I evacuated the LUA bootloader.
Compared to Spark Cores and their always connected to the cloud behaviour, they can be configured within the standard Arduini IDE (using the ESP8266 plugin). Code can even be flashed over the air and/or served from a webserver. And if neccessary they can provide an Accesspoint of their own.
Some drawbacks that I’ve already found is that Wifi disconnects when using the only analog pin on the board, and I’ve seen lots of stack traces and crashs whenever the Wifi background timing gets disturbed to much by local code. Otherwise for short codepaths the NodeMCU can instantaneously turn every small arduino project into a more capable Internet of Things project, without much effort and/or changing of lots of code.
I’m even thinking about replacing my 5 Spark Cores which are monitoring temperature, humidity, windows, doors, light and motion at my home. Only the analog thing loosing Wifi connectivity is a showstopper for me.
For more digital projects and lots of serial communication, this is the way for me to go, so I am ordering another 2 NodeMCUs.
Reflashed Arduino with newest hydro ros_lib, and also converted some stuff from TF to TF2.
Experimenting with the ATtiny2313 to get my 4 HC-SR04 sonic range finders queried from my bigger Arduino via I2C.
Got ir running using evry single byte in the FLASH of the TINY, but couldn’t implement a on/off control due to this memory limit.