A little over a year ago I designed a Braille Bricks reader. I was pleased with how that came out, until I tried to demonstrate it at a show. It was struggling to accurately read the boards. After some thought it became clear that the whole structure was too flexible and the table at the show was uneven which was causing the problem. Since the bot moved over the entirety of the board, there could be variations in height of the bricks causing the misreads.
Redesign
For various reasons I didn’t tackle the issue with the misread for several months. When it came up to the next show I still hadn’t tackled it, so I decided that I’d revisit it after the show.
To make things sturdier I decided that the bot would stay in one place (whilst reading) and the board would move underneath it – in a very similar manner to my loom’s pattern scanner. This would allow the ‘bridge’ structure to be stronger as it would be anchored properly underneath and, also, a consistent support under the board. It does, however, mean the bot needs more space to operate; the original one needed ~40L horizontal space vs ~66 for the Mk2. I think that’s acceptable for the purposes or showing.
(Re)Coding
When it came to recoding, I was rather fortunate. The original design used a 1:1 gear ratio driving an 8T gear to move the board. This one, to resist gear skipping, uses a 24T gear, so I’d need to down gear 1:3. By fluke I’d decided to reduce the load on the motor by using the 12:36 gearing (visible in the pictures above), so ultimately it was still a 1:1 gear! All I needed to do was change the direction of the motor which is easy to do in Pybricks on ev3dev.
I also needed to tackle the ‘touch’ sensing code. The original design’s ‘bridge’ would sag, which meant the ‘finger tips’ were closer to the board than on the redesign. This had a knock on effect that the test for a column with no studs could fail and be detected as no brick present, i.e. a space. All that was essentially needed was to extend that range a little along with some other logic changes.
My redesign of the pattern board scanner part of my loom is basically complete. As it currently stands it’s a standalone scanner. It works ! It’s much faster than the old system and is really clean in its operation. I need to retrofit the new code into the loom controller code, which I’ll do in a few days’ time. Before that I want to deal with how the unit will sit on top of the loom, so I need to put the loom back into its operating state and get thinking.
Releasing the BIs and Code
Since this is working as a standalone device, and I’ve posted about it a couple of times on Facebook:
I’m, as usual, going to post the BIs and code for public use. I’m licensing them under the Creative Commons Attribution-NonCommercial-Sharealike 4.0 International licence CC-BY-NC-SA 4.0
There are no cables in the BIs – they’re a pain to route so I’ve left them out. The cabling ports and cable lengths are in the BIs. Routing them is left as as challenge to the builder 😉
The code will scan a board showing the dots as it goes, then clear the screen, and reshow the code from the scanned data. This can then be used as a base for something else.
Several months ago I had been thinking on building a robot that could read the Braille bricks developed by LEGO. They have had them available in a more educational context via their https://legobraillebricks.com/ website for some time now. Unfortunately, these ideas came to nought at that time, so I put the idea to bed.
Roll on a few months and the group of RobotMak3rs that I’m a member of had one of their regular remix challenges – i.e. to mix an existing set with some robotics to come up with a new idea. By then the domestic LEGO Braille Bricks set (40656 in the UK) was out, so I figured it was time to revisit my earlier ideas.
LEGO 40656 FrontLEGO 40656 Back
Initial Ideas
Right at the start I wanted the bot to read out the Braille using text-to-speech (TTS). I wanted to do this as the bricks are intended for visually impaired users so having just display of text would be inappropriate. The Spike/Robot Inventor doesn’t have the ability to generate complex sounds on the hub itself and would have relied on an external app running on a mobile or table to perform that task. Instead I decided it would be far better to use an EV3 running Pybricks micropython as that has the ability to perform TTS output. In addition to wanting the Braille read out, I wanted all the prompts that would appear on screen to have an audio equivalent.
My initial idea for the mechanics was to have three medium EV3 motors each with 3×5 L-beam attached. As the bot moved along the line of Braille it would rotate the motors such that the tip of an L-beam touched either the brick’s stud or the top of the brick. The difference in angle of the motor would indicate a dot or not. However, very quickly this idea was discarded due to the fact that the stud height is only 1.7mm. The height, and therefore angle change was not sufficient to accurately distinguish the presence of a stud or not. Also this would have required three motors, only allowing one remaining to move the bot along a row. Since I wanted to have it be able to read multiple rows of text, I’d have needed 5 motors (X, Y, +3 for touch) which is not possible with an EV3. So I discarded this approach.
My next idea was for a bot that had an arm with three touch switches mounted on it and have the arm lift up and down. This way the angle of the motor would be irrelevant. The arm would need to move up and down on to each column of studs so that it wouldn’t get snagged on the next column as it moved sideways.
I went through various arrangements of the switches, settling on something similar to below for a number of prototypes:
The principle here was that the stud would push against the pin, which in turn via rotation of the 3×3 quarter circle beam would press in the button. The motors would have had to be mounted at 90° to each other due to the width of the switches (initially) preventing them being next to each other. The big problem with all of these designs is that the springs in the switches are remarkably firm. The motor, pushing the arm down, would have to apply a significant force – akin to trying to hold out a 1kg mass at arms length. Also, it looked ugly. I tend to work on the principle that if it’s ugly then it’s likely to be wrong.
The ‘Fingertip’
After going through several iterations of the ideas above, I had a brainwave. It was possible to mount the motors in parallel and ‘dog-leg’ the pins such that they could also touch the studs. To counter the issue of the required force to press in the switches, linear actuators would be used instead. Although this would slow down the sensing action it would trade speed against accuracy. I ended up with the mechanism below:
Dog-Legged PinsLinear Actuators
This mechanism worked perfectly, with an unexpected discovery on the switches, discussed further on.
Bridge, Switches, and Calibration
The Braille sensing mechanism (the ‘lift’ as I think of it) needed to move in both X axis and Y axis, so that the several rows of bricks could be placed on the baseboards supplied with the kit. The lift would be mounted on a bridge, allowing for Y-axis movement, and the bridge itself would move in the X-axis. The bridge took a few attempts to get right. Due to a combination of the mass of the lift and the force required to press in the switches resulted in flexing of the bridge, so this required a few revisions to get it rigid enough but not too bulky
One thing I had never realised about the EV3’s switches is that they trigger at the start of their travel, i.e. they don’t need to be pushed all the way in to trigger. Had they needed to be depressed all the way, it’s quite possible this model would never have worked. Due to LEGO being plastic, the parts are never perfectly aligned. This could have meant that one of the switches may have reached the end of its travel before either/both of the other switches had triggered. No amount of extra downward force could have pressed the other two as this switch would have blocked any more movement. Thankfully they trigger at the start, so it’s still possible to push down, thus enabling the neighbouring switches to also trigger.
Due to slight flex in the model, it’s not possible to have the motor wind the linear actuators to the same place per row of Braille. The middle two rows can require a little more force. To solve this the bot requires calibration on first use, and offers to calibrate on start up as well. Calibration requires that an L (⠇) brick is placed at the start of each row, then the bot tests each of those bricks. For each row the motor position for the last switch to activate is stored on disk, for repeat use, then when in use it drives the motor to just beyond the motor angle to ensure that all switches could be activated.
Accessibility
As I said at the start, I wanted this model to be accessible to the target users, so all instructions are read out as well as displayed on screen. All button operations have a small click to provide audio feedback, along with a relevant audio prompt, e.g. saying which row has been selected to read. To aid in placing the Braille bricks on the baseboard there are tiles on the first column. Subsequent bricks are simply placed next to the previous bricks. The EV3 has been oriented so that the speaker is facing the user so that it can be heard.
Video
As part of our group’s remix challenge we have to produce a video relating to our build. I opted to have the video show parts of the robot and it in operation. Since the bot converts the Braille to speech, I figured I’d have the voice-over performed by the bot as well (I’m never a fan of speaking on camera, and being a Brit I always feel that I sound sarcastic 😆). I also thought that it would be a fun little feature to have the subtitles show in Braille first and the wipe over to the actual text. The resulting video is below:
On first ever run of the program, it will pre-generate all the pre-coded speech prompts. This is so that the program doesn’t have to perform the TTS step every time a common speech prompt is needed. It will only do this the once.
On first run of the program it will insist on a calibration step. It will offer to perform a calibration on every other run, but it defaults to ‘no’. To calibrate perform the following:
Put an L brick at the start of each of the 4 rows
Press the centre button. This will then test each of the sensors and motor and store for future use
Lay out the Braille as wanted. There are 4 rows that can be used. Select the row to be read with the left and right buttons, centre to read. Spaces between words can be either one or two columns of studs wide. Three or more empty columns will end the row of text.
Over the past few weeks I’ve been working on a robotic bobbin winder for my Weav3r loom. Previously, at shows, I’ve had a simple motorised mechanism for winding them but it required my attention to wind. After regular suggestions from Martyn Boogaarts about making a bot to do it, I finally pulled my finger out and got on with designing one:
My intention is to ultimately release the BIs for the loom, but it is taking some time to construct the 3D models for it. One of the issues with the loom is that I’ll need to dismantle significant portions of it to find out how I built it 🙂
I mainly model things for my own benefit so should I have a need to rebuild, I can. For this model, I figured I’d actually produce a proper BI PDF and release that and the code for those that wish to have a go at building it. I should note that I have been a little lazy with the BIs and not run any cables. Instead I have inserted the cable ends and colour-coded them. You will need 1x 50cm, 1x 35cm, and 4x 25cm cables – I’ll leave the routing of them to the builder.
This model will probably need an instruction manual, although I’m hopeful that it ought to be relatively clear how it works. The video above shows how the yarn is threaded through but that ought to be obvious. The code has a menu system which also ought to be clear. If there’s enough feedback/demand for operation instructions, I’ll write up a blog article/document to do that.
Over the past few days I’ve been rather nerd-sniped in to thinking about a system for passing two concentric drives through a turntable.
I’m starting to think on ideas for a bot that I plan to build later this year. This bot will need an “arm” attached to a turntable, with two motorised functions attached to it. There will be driven functions on either side of the turntable and it must be able to rotate an indefinite number of degrees, so passing cables through the turntable is not an option. This leads to the only conclusion that the two driven functions on the arm must be driven by axles passing through the middle of the turntable.
Two parallel axles don’t work, as when the turntable rotates, how does one keep the gears attached? The answer is to use concentric drive shafts. This can be done either using driving rings, or a 16T/24T empty differential. The former is no good for my bot due to the ~90° backlash in a driving ring, and thankfully I had one of the latter!
Maintaining Alignment – Unity
The next issue is what I’m mainly blogging about – when the turntable rotates, the concentric shafts need to rotate in unison. I could achieve that, to pretty good success, by driving all three motors at the same time at appropriate ratios – but where’s the fun in that? Instead I’ve opted for using two additional differentials as adder/subtractors on the input shafts for the concentric drive. So, as the turntable rotates the two differentials add/subtract a proportional amount from the other two inputs, so it all rotates together. It’s hard to describe, but it does work.
For this all to work, for each rotation of the turntable I need to have a half turn of the differentials – that results in a full rotation of the output side of the diffs. That turned out the be easier said than done. The turntable has 60 teeth, and the diffs have 28 teeth. So I needed a 60:14 ratio. Thankfully I have a SPIKE Prime, which has two of the new 28 teeth gears 😀 This works out to be: 60 *28/36 * 12/20 * 16/24 * 12/16 = 14. My resultant mechanism looks like below:
The two input shaft, red axles, at the bottom drive the two 16T gear outputs above the turntable. The red input axle on the left drives the turntable. This is as compact as I could make it.
Gearing Issues
One thing to note is the 1/2 offset 20T bevel gear that drives the turntable, as an idler gear. Normally a 12T bevel gear at normal spacing would be used. Originally I did have that but it was incredibly noisy and “crunchy”. After lots of inspection under various lights, even trying a bit of silicone lubricant I realised the issue – the 12T gear was binding up against the teeth of the 60T turntable due the the teeths’ angle of contact. As a “new” tooth from the 12T gear approaches one of the teeth on the 60T gear, the angle is too steep, resulting in the 12T gear pushing the 60T gear up rather than across. This would explain issues I’ve had with my loom clicking loudly at times – the front cloth winding roller is also a 12T/60T combination. The same must be happening there. The answer here was to use a 20T gear, but that required a 1/2 offset which was an interesting challenge to fit it, but it now works a treat.
Build Instructions
I’m a few months away from actually implementing my ideas – I have lots of things for the loom to do first – but at least I have got my nerd sniped brain over this problem. I’ve made an LDraw model of it, but haven’t got the time to turn it into full build instructions. This is being released under the Creative Commons Attribution-ShareAlike 4.0 International License and is available from:
