LEGO – Jander's LEGO® Stuff

Braill3 – An EV3-based Braille Bricks Reader

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.

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:

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:

Build Instructions and Code

Build instructions: http://jander.me.uk/LEGO/resources/Braill3-BIs.pdf

Python code: http://jander.me.uk/LEGO/resources/braille.zip

The Python code needs to be run under Pybricks micropython, under ev3dev. This requires a microSD card. The official LEGO ev3dev installation can be found at: https://education.lego.com/en-us/product-resources/mindstorms-ev3/teacher-resources/python-for-ev3/

Operating Instructions

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:
1. Put an L brick at the start of each of the 4 rows
2. 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.

Robot Olympics Remix: Eque5trian – Show Jumping

In March 2021 the members of the RobotMak3rs RLOC were challenged to come up with ideas for an Olympic Games remix involving two kits, one robotic and one non-robotic. My idea was to mix the LEGO White House (21054) kit:

and the Robot Inventor (51515) kit (plus four pulley wheels):

to create an Olympic Show Jumping model:

Model Modes

The model has two modes of operation: automaton and game. In automaton mode, the horse will go around the arena leaping over the jumps of its own accord. In game mode, there are speed and jump controls and the player attempts to get the horse’s speed right and jump at the correct time. A video showing the model in operation and some of the details about it is below:

Model Operation

What was not shown in the video is how to start the model off. The model needs to set its initial positions. It does this by rotating the jump motor to its 0° position, then repeatedly rotating the horse motor to its 0° position until the horse ends up in its start position. This is required due to the 36T:60T gearing used to drive the horse’s position. The colour sensor will detect the white 3L beam when it’s in the start position.

The steps to start the model off are:

Before starting the code, remove all the jumps – so that they don’t get knocked over during initialising.
Start the program. The horse will go through its location detection steps.
Replace all the jumps back to their positions
Tap the hub – it waits for a tap gesture before carrying on
Enjoy the model’s action.

Build Instructions and Code

I have produced build instructions which are linked to below. There are two programs, one for each mode that are also available below. The code has been written in the default block language for the 51515 hub. My BIs and code are released under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International licence:

BIs: Eque5trian BIs.pdf
Automaton Code: Eque5trian Automaton.lms
Game Code: Eque5trian Game.lms

Other Model Submissions

Other models from both the Robotmak3rs and the general community can be found at: https://www.facebook.com/hashtag/robotmak3rsolympics

Robot Inventor: Pass the Build – Charlie

Over the past week or so, several members (including me) of the RobotMak3rs RLOC have been having a lot of fun playing with LEGO’s new Robot Inventor kit (51515), which will be released on 15th October this year. Many thanks goes to LEGO and the RobotMak3rs RLOC for supporting our ideas.

My idea was for us, as world-wide community, to have fun building some of the models together. Here’s the first of the videos – Charlie:

Pass the Build of Charlie

Watch this space for the other models!

The RobotMak3rs Community Facebook page can be found here: https://www.facebook.com/robotmak3rs/

#mindstorms #robotinventor #robotmak3rs

Weav3r Cloth Winding Drum Update

A little while ago I posted about my new cloth winding drum. Up until that point a lot of it had been built, but I still didn’t have any of the 1L worm gears needed to drive the turntable ends to the drum. Only the 3D LDraw model showed that it’d work.

Since then, I’ve given in and ordered some via BrickOwl. I finally had the opportunity to test the build out and, unfortunately, it didn’t work as intended. The turntables could easily skip off the worm gears under load – loads which it’s likely to see in operation due to the tension in the warp threads. A little bit of investigation showed that the structures that were holding the worm gears in place were flexing under load. There was nothing to stop the split cross-blocks from rotating a little. Since then I’ve redesigned that section to stop that rotation:

Worm gear support. — Redesigned worm gear support

This appears to work perfectly 🙂 . Without risking breaking something, I am unable to cause the worm gears to skip on the turntables.

A few photos of the real cloth drum and its update:

Complete cloth winder, with drum in-situ.

New worm gear and its strengthened support.

Worm gear meshing with the drum’s left turntable.

The LDraw model has been updated to include the new support:

http://jander.me.uk/LEGO/resources/Cloth%20Winder.ldr

This work is released under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International licence.

Bobbin Wind3r Code & BIs

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.

The code and model are released under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International licence.

The code can be obtained from: http://jander.me.uk/LEGO/resources/Bobbin%20Wind3r.ev3

The BI PDF can be obtained from: http://jander.me.uk/LEGO/resources/Bobbin%20Wind3r.pdf

Loom Upgrades – Cloth Winding Drum

Whilst we’re all in the position that we need to reduce social contact due to COVID-19, I have taken the opportunity to work on a couple of aspects about my Weav3r loom that I felt needed attention. I have definitely solved one of them and hope, when I can buy some parts, that I have solved the other.

Clicking Gears

This is the problem I hope to have solved, but don’t yet have conclusive proof. Whilst working on the problem of the concentric drive I found that the mesh between the usual 12T gear and the 60T turntable was not particularly good. Looking at the image below it can be seen that the teeth of the 12T gear approach at quite a shallow angle to the 60T. This can be seen at the 11 and 1 o’clock positions – the teeth of the turntable appear to “dig in” to the 12T gear. This causes the mesh between these gears to sometimes be very rough.

When working on the concentric drive I found that the 20T gear is a much better mesh, but this requires a 1/2L offset which really just didn’t work for the loom. The other issue with using a bevel gear to drive the turntable is that the tension in the warp thread could feasibly be high enough that as the turntable rotated it would be pulled up and away from its drive gear which could also produce the same clicking problem.

The change to the gear chain has been to have the worm gear driving the turntable. This is a great benefit as the worm drive is a much smoother mesh and, also, it is not possible for the turntable to lift off the worm. To drive the 60T turntable with a worm gear I will need to use the newer 1L type – this is the part I don’t have, but have rebuilt with the intent to use.

The existing gear chain was: 1 • 20:12 • 1:24 • 12:60 => 1:72. This used one of the old 3L worm gears, halfway down the gear chain. To use the 1L worm at the end, with the same axle paths from the large motor, the gear chain is now: 1 • 20:12 • 24:24 • 8:16 • 1:60 => 1:72, so the same ratio. However, the additional 24:24 will have reversed the direction, so I must remember to adjust my code to reflect that.

The new turntable drive now looks like the image below:

Detachable Drum

The original build’s drum was locked in to the structure. This meant that to remove the scarf, at the end of a day’s show, the whole thing had to be run in reverse for around 3m. This would take a remarkably long time, and was just extra wear and tear on the mechanism that could be avoided. So, another design criterion for this change was to make the drum removable, but at the same time retain its strong connection to the worm gear. This has, happily, been achieved.

The drum has a 5 x 7 open centred frame at each end which locks in just above the worm gear. In the image above it’s possible to see two 4L axles with stop either side and behind the worm gear. These lock in to the bottom of the drum’s end frame preventing any misalignment. The frame is locked in to place by two bush pins inserted from behind.

The drum itself has also been altered. The original was somewhat flexible and the pins along one “side” had a gap in them. The inner “hexagons” inside now have two pulley wheels inside to support them, making the drum more rigid. The structure has also been reworked to remove the gap in the pins. An added benefit to that is that there are 33 continuous pins, which equates to 32 slots between them, one per warp thread. An intermediate render, I’ve changed things a little since I made it such as the black bush pins are in the wrong place now, is shown below:

The entire front structure that encloses the drum is removable for transportation, i.e. for DHL to take it abroad 🙂 This has had some attention at the back of it, but that is more cosmetic and tidies a few things up. One humorous thing is that when I’ve detached it recently I’ve partially dismantled a section – I’d totally forgotten I’d built it so that I pull out 4 bush pins and the whole unit lowers down and forward!

Renders of the final structure with the drum installed, and removed, are shown below.

An animated render of the structure is below:

For those that may be interested, I’m posting the LDraw model. I don’t intend producing a PDF of BIs, but this model is in steps, so should be easy to follow. This work is released under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International licence.

http://jander.me.uk/LEGO/resources/Cloth%20Winder.ldr

Concentric Drive Through a Turntable

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:

http://jander.me.uk/LEGO/resources/Concentric%20Drive.ldr

Updated EV3g Mailbox Messaging in Python

Previously I posted an article on handling EV3g binary Mailbox messages under Python3. Since then I have carried on working on this class, along with adding a handler class.

Improved Mailbox Handling

One of the things I wasn’t so keen on with my implementation was the need to specify the type of Mailbox value, i.e. BOOL, NUMBER, or TEXT. Python’s variables have their own type, so the code has been adjusted to use the value’s own type to determine the binary payload format. It is still possible to coerce the type:

from ev3mailbox import EV3Mailbox

float_msg  = EV3Mailbox("Pi", 3.1415)

# Coerce to a string
string_msg = EV3Mailbox("Pie", 3.1415, str)

These changes have made the use of this side of the code much cleaner.

Mailbox I/O Handler

Whilst working on my use case for the original code, I had been working on the principle that I’d be using it in a simple synchronous send/receive pattern. This worked well, until I started using threads at both sides of the ev3dev <-> EV3g link. Once threads were in the mix, there’s a risk that the bt_socket.recv(…) call could actually receive a message that wasn’t destined for that particular call, but for another area of the program.

The solution to the above problem was to implement a receiving thread that deals with all the socket.recv(…) calls. Each message is decoded, and then each Mailbox name has its own FIFO of message objects. It’s a deliberate choice to maintain the list of objects, rather than just their values, so that they can be forced to floats if it’s known they may be very small – see my previous post about that problem.

The new class implements a handler that will deal with all the Bluetooth and thread side of things. All that’s then required to do is call send(…), get(…), or stop() on the class instance:

from ev3messages import EV3Messages

handler = EV3Message(bt_mac_address)

handler.send("Name", value)
msg = handler.get("ANOther")
value = msg.value

handler.stop()

The calls to send(…) and get(…) should (!) be thread safe, so calls to get(…) wait on receiving a message of the requested name.

Code Repo

The repo is available from: https://gitlab.com/Jander/ev3-mailbox-python and is released under the GPLv3.

EV3 Mailboxes in Python

Recently I wanted to enter the Alexa / LEGO MINDSTORMS challenge:

https://www.hackster.io/contests/alexa-lego-voice-challenge

My idea required being able to send EV3 Mailbox messages via Bluetooth between ev3dev and a stock EV3 running the EV3g language – from Python. I’m new to Python, I’m a Perl programmer at heart, so this was somewhat of a learning curve moment. I had to get to grips with Bluetooth (not that difficult as I’m used the IP networking) and Python at the same time.

I figured that one of the major selling points of Python was its extensive library of support functions, so set to looking for something providing EV3 Mailbox handling. My research wasn’t as fruitful as I’d hoped for. I could find various chunks of code but either they were flawed in their behaviour, or much more heavyweight than I wanted. So I decided to jump in feet first and write my own library.

I’d written a library for App Inventor 2 [0] [1] [2] [3] [4] that would encode & decode EV3 Mailbox payloads before, so this wasn’t too daunting a task. One aspect of Mailbox messages is that there isn’t an identifier within the payload that identifies the content: String, Float (IEE754 32 bit), Boolean. Normally this is handled in EV3g by expecting a specific type relating to the message name – i.e. a message called “status” would be defined to always be a Boolean, but “command” would always be a String – the code forces the type to remain constant. However, the type of the payload can be deduced to some extent, so I decide that I’d implement that within the Python class:

Payload length = 1 byte => Boolean
Payload length = 4 bytes
- Last byte != NULL or NULL in the other bytes => Float
- Otherwise => String
All other payloads => String

The only issue with the logic above is that really, really, small numbers may get decoded as strings, e.g. “@@@\x00” would get seen as a string, not 5.90052e-39 which is also a valid decode of it. As such I also implemented a .force_float() method which will re-decode the payload.

The git repo for this library can be found at:

https://gitlab.com/Jander/ev3-mailbox-python

To use it do something like:

from ev3mailbox import EV3Mailbox as Mailbox

message = EV3Mailbox.encode("Name", "Message value", Mailbox.Type.TEXT)
print(message)

# Data from Bluetooth
 mailbox = EV3Mailbox.decode(payload)
 print(mailbox)

Hopefully this will prove useful to others. The code has been released under the GPLv3: https://www.gnu.org/licenses/gpl-3.0.txt

Modelling my Loom

Ever since I started to show my LEGO® loom on this blog, Facebook and YouTube, I’ve had people ask me for build instructions. I’ve always said that I’d make them, and I will stick to that … but it’s a BIG task, and will take a long time.

Recently I’ve been making changes to the loom, so have been removing old parts and making new modules to replace them. What I decided to do as I went along was to actually model the parts I was removing, and to model the new parts as I went. This way I have the old parts for reference should I ever want to look back on them in the future, and the new parts have been modelled from the start. As time goes by I intend modelling the separate “modules” of the loom, and then build up a body of work of all the sections. I’ll still need to model the main framework of it, but that will come in time.

So, without further ado, here are the parts I’ve done so far.

Warp Thread Drum

This is the original warp thread winding drum. This was used at the back of the loom and stored the warp threads for feeding in to the loom. In my original build I used to have to wind the warp threads on, en masse, by hand. This suffered from a) being tedious, and b) the threads would wind on at different rates. Since the threads didn’t lie completely flat on top of each other, the drum would end up with different “thicknesses” of threads, resulting in some threads winding on faster than others – since C = 2πr. When the loom was running it’d pull all the threads through at the same rate. Due to the different winding thicknesses, this would either result in some threads getting very slack or, more commonly, some threads getting very very tight.

The LDraw model for this can be found at: http://jander.me.uk/LEGO/loom-parts/Warp%20Drum.ldr

Warp Thread Winding Gearbox

My solution to the differential winding of the warp drum, was to build a set of pinch rollers, that the warp threads went though, and a gearbox that drove the drum.

One of two gearboxes – one either side of the loom to drive the warp thread drum.

The pinch rollers would be in use during weaving, to provide a tension control between the back of the loom and the cloth take-up drum at the front. They would ensure that all the threads passed through the loom at the same speed.

The gearbox would be engaged when loading the warp drum. When engaged, the warp thread drum would rotate at a “surface speed” ever so slightly faster than the feed rate of the pinch rollers – the white clutch gear would deal with any mismatch in speeds. When weaving the gearbox would be flipped over to a gear with a friction pin, just to stop the warp drum free-spinning.

This appeared to work well, until the last time I loaded the loom. I was struggling with the threads getting caught up in the pinch rollers as they wound on. After watching it load, and thinking on it, it was the same differential speed problem as in the original loom, but in reverse. Now, as the threads wound on, they were winding on at different speeds due to not winding on flat. This was exacerbated by the use of the clutch gear. This meant that the warp drum rotated at the slowest speed, i.e. that of the thickest wound thread. The threads winding on to the thinner areas therefore became slacker, and would get caught on the pinch rollers, ultimately winding back inside them.

The LDraw model for the gearbox can be found at: http://jander.me.uk/LEGO/loom-parts/Warp%20Gearbox.ldr

Bobbin Frame

My answer to the warp threads running at different speeds has been to make a frame that has 32 individual bobbins; one for each thread. I’ve yet to test that it actually works, but will do in the next few days. Now each thread can unwind at its own speed, and not be affected by its neighbour.

I’ve designed a frame that can hold them all, in the manner of a cartridge. This way it can be loaded up away from the loom if desired, and then clipped in to place.

Each bobbin has a black and dark grey disc, and a friction pin on one end and an axle on the other. Half of them have the friction pin on the black side, and the other half on the grey side. The friction pin is simply to stop the bobbin from free-spinning. All the bobbins will be wound in the same orientation with respect to the black/grey discs. This means that when they are all installed half will unwind clockwise, and the other half anti-clockwise. This is so that the threads don’t rub against each other (too much). The frame also has a set of long axles to act as thread separators. This is so that the threads don’t get twisted together, thus preventing them unwinding properly.

The LDraw model for the bobbin frame can be found at: http://jander.me.uk/LEGO/loom-parts/Bobbin%20Frame.ldr

Bobbin Frame Support

To support the bobbin frame and to allow it to be easily removed and installed, a simple support structure was needed.

The red pin bushes at the top are used to lock the bobbin frame down on to the support. The bobbin frame itself has axle pins underneath that locate into the angled beams on top at the back. The whole thing is supported on the long angled arms, set at a 3:4:5 Pythagorean angle.

The LDraw model for the support can be found at: http://jander.me.uk/LEGO/loom-parts/Bobbin%20Frame%20Support.ldr

Bobbin Winder

Although I expect to wind the bobbins using my main winder, used for the weft threads, I wanted a winder mounted on the loom itself.

To achieve this a small winder has been made where there are two devices, dog teeth, that engage with the six holes on “wedge wheel” discs on the bobbins. The bottom one hinges out, and the top one slides up and is driven by the same motor that powers the pinch rollers. A single speed gearbox is used to engage/disengage the motor. This allows for it to be used when the loom is empty, and not powered when the loom is in operation.

The plan is to always wind bobbins with the black disc on the bottom, held by the red dog teeth. This will ensure that all the bobbins are wound in the same orientation.

The LDraw model for the support can be found at: http://jander.me.uk/LEGO/loom-parts/Bobbin%20Winder.ldr

Weft Shuttle

Whilst I’ve been working on some of the issues, I thought I’d tackle the shuttle.

This has generally worked well, but now and again has got caught up on the threads as it’s passed through. This has been down the the “shed” (the hole inside the top and bottom warp threads being a little bit too small, and snagging the horizontal bar at the front. This bar is used to ensure that the weft comes out from the middle of the shuttle.

In my original design this bar sat 6L away from the shuttle. The supports that hold that bar in place, and the long bobbin between them, are now 5L and the bobbin sits at 2½L away. It may not make much difference; I have yet to test. If 5L is too short it is easy to modify it back to 6L.

The LDraw model for the shuttle can be found at: http://jander.me.uk/LEGO/loom-parts/Shuttle.ldr

Rendering

I build all my models in Bricksmith. I’ve used it for years, and know how to drive it. I’ve had a play with Stud.io recently, and still don’t (yet) get on with it. However, I really like the renderer that comes with it. So, I’ve been building my models in Bricksmith and using Eyesight, from Stud.io, to make the pictures seen in this article.

What’s Next?

Well, I still need to test that this all works. That’s something for this week, but I think Captain Marvel comes first 🙂