Hi all,
I’ve been thinking for a while that should be interesting to have an option for even easier ways to play with Arduino. I’m thinking on approximating this technology to younger people that feels comfortable with other (much more expensive) toys like Lego Mindstorms ® because it’s easier and faster to play with.
I’ve had the opportunity to have a look at this expensive toy, and is really amazing how they have simplified the process, so the kids doesn’t need to care about the connection of the sensors/actuators to the main control unit, include libraries, learn apis, ports,... I mainly like:
- All sensors/actuators have a common interface to the main control unit, so there is no need to wonder how to connect the sensor/actuator (if is I2C, direct digital input pin, direct digital output pin, analog pin, how many pins, if has clock or not…). It is just plug and play, and it auto detects the sensors/actuators connected to the control unit, so while programming you can see which elements are connected and also the values they are reporting (for testing).
- Don’t need to include libraries or learn apis. Everything is standardised. The programming language is visual, adding and connecting blocks to create the flow of the program…
- Of course, the ‘packaging’ (I mean the physical object with easy integration with toy bricks), as it can be very easily added to any object created with the playing toy.
All of this makes it a really good option for starting with kids, but it is really expensive and has its limitations (only 4 sensors and 4 actuators per control unit, a limited variety of sensors...).
My message is because I think we can do something with Arduino similar to this, and also more powerful. I’ve been thinking on this option, and my guess is that we can create a new shield for Arduino (to make it the control unit) and a new set of ‘very evolved’ sensors that can communicate with the control unit using a common interface (something similar to I2C, but with variations to allow getting a new address for any new element plugged in, keep alive messages to detect the removing of any element, normal communications initiated by the control unit, interrupts to allow the elements send unexpected data to the control unit...) with well defined apis for the interaction to allow the programming interface to transform them into blocks that can be interconnected.
Just to define a little bit, let say we call the control unit the EasyComm Arduino (ECArduino), the sensors/actuators the EasyComm devices (ECD), and the common interface the EasyComm bus (ECBus).
Of course this idea will make any sensor much more expensive, as we need to add to every one a processor to sample the data and communicate through the ECBus, but I think it deserves to pay let say around 5€ per ECD (we can add the Arduino Pro Mini to the sensor that is really cheap, and we could create some 3D printing design to be downloaded and printed by the users to use this with other construction toys), bear in mind that they are still way cheaper than the original playing toy.
The EasyComm shield for Arduino could include some basic things, like an LCD screen, basic buttons to navigate through a menu, some leds, a speaker, one or two mics (for noise reduction) and of course the ECBus (if we start with I2C with variations, this bus should have 4 pins: +5V, Gnd, clock and data; and the cables should be a T, to connect to the ECArduino, connect to the ECD, and an extension of the ECBus to allow any other ECD to connect to this cable. This way we won’t run out of connections), for example.
The ECBus should be implemented to allow new ECDs plugged into it to send a message (lets name it NIN: New In the Neighbourhood) so the ECArduino will answer giving an address to this new ECD. The ECArduino can initiate any communication to read/write on any ECD. The ECD can initiate any communication as an IRQ for the ECArduino if some condition is met. And also we need to think of a keep alive messaging system to detect any element removal from the ECBus. I have a pretty developed idea of this ECBus, if this interests to someone I can create a document describing it.
For the ECD we can think on a lot of different devices, but as an example I have two:
- Color Sensor: using some LDR and RGB LEDs, we can create an ECD that detects the color of something. It can have 3 different modes of operation: in the first one it will detect the color emitting light with the LEDs, reading the reflexion on the LDR and processing it to detect the color. In the second mode, it can detect reflexion turning on the three leds simultaneously and reading the value of the reflexion in the LDR. In the third mode it can read illumination by turning off the LEDs and reading the ambient light. We can define functions to answer to the ECArduino for some concrete values (on any mode), but also the ECArduino can define IRQs to be warned if the color changes, if some color is met, if the illumination or reflexion goes above or below a threshold, etc. The ECD could have two color sensors for example, so with one ECD we can control two sensors independently.
- Touch Sensor: with one Arduino Pro Mini (one ECD) we can attach multiple (lets say 10) touch sensors (the ECD could have some INPUT_PULLUP pinout to plug a 2-wire switch or any other touch sensor), but also we can plug a 4x4 switch pad (the typical switch pad used to create a number pad). The ECD should detect if there is a 4x4 pad connected or not (maybe we can use an INPUT_PULLUP pin for this: if is open (HIGH) means the pad is not connected, so it understands that there are switches connected to the other inputs; and if is connected to GND it means there is a pad in the rest of the input pins). This ECD sends the configuration to the ECArduino (if it changes for example plugging in a pad, it updates the configuration to the ECArduino). We can define functions to answer to the ECArduino for some concrete switch states (or button pressed on the pad), but also the ECArduino can define IRQs to be warned if some concrete switches are pressed, released, or changed state; or if some button on the pad is pressed, etc.
This are just two examples, feel free to comment on any to improve them, or add any other sensor you may like to have.
One more important thing: we should define some basic program to load on the ECArduino when it connects to the programming environment (lets call it the EC firmware). This way when any new ECD is connected during the programming phase, the ECArduino will detect it and send an update information to the programming environment, so it will be shown to the user to be added on the sketch. Also it can be useful to have probes on the values of any ECD during programming, so the user can see the color that is read when the Color Sensor ECD points to some surface, and create the sketch taking this into account. On the programming environment the user should be able to change the mode of operation of any ECD, read values, act on it...
Sorry for this very long text. If you have read until here means you are interested on the idea or you have a lot of free time 
. I would like to go on with this if it interests to someone, but I would need help as I don’t feel confident enough to carry on all of the work this involve (specially with the programming environment). I can create some spec documents for the ECBus and the two sensors described above, to start with…
Thanks for reading and best regards!!