Small Talk

Two years ago, I used an Emic2 module for a couple of TTS (text-to-speech) projects. Despite its flexibility (someone even made it sing Bohemian Rhapsody here), the Emic2 sounds quite ‘robotic’ when used for direct TTS conversion. Not the best choice for a Talking Alarm Clock project, unless you like to wake up next to Stephen Hawking… (no offense).

So I considered to compose full sentences out of spoken language fragments, stored in mp3 format on my VS1053 breakout’s SD card. Then I discovered this google_tts library on github. It takes a text string as input and returns a link to a correspondig mp3 file in the Google cloud. You can specify one out of 30 languages, as well as a voice (both male and female).

I tried it, and the result is fully satisfying. The sketch starts with retrieving the local time for my location, provided by a simple api on my server. Then it fills a string variable with a natural language sentence like “The current time is <hr> hour and <min> minutes” (in Dutch in my sketch). Next, this string is processed by the library and the resulting link is sent to translate.google.com. The returned mp3 data is streamed to the VS1053 chip and sent as analogue audio to the amplifier.

This project is definitely going to replace my alarm clock. From now on, a soft female voice will wake me up in the morning, reading the current time and weather forecast, before telling me to stay in bed for a while. So glad I didn’t use the Emic2…

Here’s a basic sketch (current time only). You can ignore warnings when compiling it for esp32: it’ll run just fine on esp32 boards.

Rotary Encoders

With my upcoming robot arm project in mind, I bought a couple of these cheap Keyes KY-040 rotary encoders. Guess they may come handy for manually controlling servos with greater precision than potentiometers, especially in combination with the 12 bit resolution PWM controller that will drive the arm’s servos.

First I wanted to check that all encoders were OK (they could be Chinese clones of Chinese clones…), so I grabbed some sketches from the Internet. All sketches – with or without the use of interrupts – worked fine on all encoders, but I noticed that they would only count every second click of the encoder. As my encoders have 30 clicks (‘detents’) per revolution, using the technique from these sketches would reduce the resolution to only 15 steps per revolution of the shaft.

So, in order to find out what exactly happens with each click, I wrote this simple sketch:

Rotary encoders have two switches, A and B, that will be switched on and off when you turn the shaft, resulting in binary pulses on their CLK and DT connectors. Since the pulse sequence of  the switches are 90 degrees out of phase, you can not only count the pulses, but also detect whether the shaft is being rotated clockwise (CW) or counter clockwise (CWW).

 

The output of the above sketch showed that my type of encoder will click on every blue and every red marked event within the pulse sequence, whereas all sketches I’ve seen so far will count either the blue or the red events (i.e. full pulse cycles).

Once I understood why the sketches I found on the Internet ignored every second click of my decoders, it was time to write a sketch that would count every click, and tell me the direction as well. As the picture clearly illustrates, the values of A and B will be the same after every click. The direction is defined by which of them arrived at that value first. If it was A, then rotation is CW; if it was B, then rotation is CCW.

In order to detect every click of my decoder, I decided to attach a ‘CHANGE’ interrupt to switch A (marked CLK on the encoder). Note that attaching ‘CHANGE’ interrupts to both CLK and DT is useless.

A nice bonus of the encoder is that it has a third switch (marked SW), that is pulled to GND when you push the shaft. I decided to use this feature for cycling through different incremental step sizes, offering different resolutions for sending a servo to a desired position (coarse-, medium- and fine tuning).

Time to put it to work. The following sketch controls a two-servo pan/tilt module by reading two rotary encoders. It uses a 16 channel 12 bit PWM Servo breakout to drive the servos, but the sketch can easily be simplified if you drive them directly from Arduino PWM pins. The ‘step size per encoder click’ will cycle through values 1, 5 and 10  with each push of the shaft. Parameter values for debouncing were optimized after some testing.

In the end, this setup turned out to work remarkably well for controlling my pan/tilt module with two KY-040 encoders connected to an Arduino UNO.

Note that the code within interrupt routines ProcA1 and ProcA2 has been reduced to calculating the new servo position and setting an alert flag, while the overhead of polling within loop() is limited to checking these two alert flags. In sketches where single loop sequences can take long, one could improve responsiveness to encoder events by having the interrupt routines do all the work (including the actual servo control), although in general, that’s not recommended.

This approach will be used for my robot arm project, although I will have to drop the interrupt technique for some of the decoders because the UNO only has two pins for external interrupts.

Meccanoid

Meccanoid is an advanced yet easy to use open source robotic building platform.


Forget it!

Since Meccano introduced its Meccanoid at the end of 2015, they still have to open their source. You cannot reprogram its controlling processor, called Meccabrain. All they gave away so far was a bit-bang protocol to control the smart servos and LED module, and a corresponding Arduino library for convenience.

As a toy, it may be quite impressive at first (after daddy spent at least 8 hours to build it), but my guess is that many Meccanoids will have gathered quite some dust by now.

In order to become a serious robotics platform, it will have to offer much more than just servos and LED modules that can be controlled by a microprocessor like Arduino. The included Meccabrain processor unit has 8 channels that, in theory, could control 32 Meccanoid devices (servos or LED modules that can be daisy-chained). Even if the company behind Meccanoid, Spin Master Toys, would allow the upload of custom code to the Meccabrain, I would still want to connect sensors and communication modules to it.

 

Apart from plastic parts, screws and bolts, my Meccanoid G15 KS now basically is: eight smart servos, one LED module, two DC motors and a closed source Meccabrain. Well, let’s see what a real open source platform like Arduino can do with it.

Continue reading “Meccanoid”