In this article I will finish discussing placing treads manually using Bricksmith. In Part 2 I referred to sprockets with the notch a the top:
Notch at the top.
These are much better in terms of placing the first tread as it will sit properly in the notch as it’s on an integer grid, unlike the 90˚ rotated version which is very slightly off that grid.
Technique
The technique is almost identical to that discussed in Part 2, but the first tread needs to be rotated by 18˚ after its initial placement:
Initial placement.First tread rotated 18˚.
A point of interest is that the tread was rotated around a Y coordinate value of -48, i.e. a radius of 48 from the centre of the sprocket. This is different to the 50 used by LSynth as discussed in my previous post about my investigations in to LSynth:
Sprocket Radii as defined by lsynth.mpd: 50 & 25.
Once that first tread is in place and aligned, it is now a simple case of copying, pasting, and rotating as shown in part 2:
Second tread in place.Final tread in place.
All done. One thing to note is that treads 2-5 have undergone two rotations each, but don’t appear to suffer any level of cumulative error. This is probably due to the first tread being rotated about its origin only. This results in the treads 2-5 only having one orientation rotation, and one position translation, thus reducing the errors.
This does look a lot of effort to do manually, but I’m used to it now and find it quick enough to do, and the results look good.
After posting my “tutorial” articles on the LEGO MINDSTORMS EV3 Facebook group I started to look in to how LSynth does its magic, and now have a greater understanding of what the issue with treads is. I’ve worked through how the lsynth.mpd file works, including reading the source code. I’ll attempt to describe what I’m seeing.
Constraint Radii
The lsynth.mpd file is used to describe the parameters around the various elements, in this case Bands, and Band Constraints. Each constraint is defined by its type, radius, orientation etc. The two sprocket types I’m interested are listed as:
This states that the small sprocket has a radius of 25 LDU, and the large 50. This is incorrect, since the large sprocket is 1.6x that of the small, not 2x. It is in fact the small sprocket that is wrong, it ought to be 32 LDU. The sizes as per the LSynth file can be seen in the image below:
Sprocket Radii as defined by lsynth.mpd.
Band Scaling
The loop of treads is defined in the lsynth.mpd file as a band of fixed size elements. Two parts are defined: one for going between, and the other for wrapping around, the constraints – i.e. the sprockets. The band definition includes a scaling value which is used for working out how many elements will be needed between constraints, i.e. the straight line segments. For the large treads this is defined as:
The scale value here is 0.03571. This should be 1/N where N is the LDU length of the segment unit, i.e. tread, in LDU. The value of 0.03571 gives N=28 LDU. This is also wrong. The distance between the centre of the hooks and pin on the treads is 30 LDU, so the scale value ought to be 0.03333. This incorrect scaling value is what leads to the “compressed links” I referred to in the previous blog. The original value, and one of 0.03333 can be seen in the image below:
Top = 0.03571 (original), Bottom = 0.03333 (corrected).
An additional benefit is that the parts around the sprocket are also now the correct number.
Numerical Accuracy
Unfortunately it appears that numerical accuracy has a noticeable influence on the appearance. With the corrected scaling value for the treads, wrapped around a single sprocket the result looks like below:
Numerical accuracy.
As can be seen, the tread pins don’t sit quite in to the sprocket’s notches. I would put this down to rounding errors.
There is another issue in the code which doesn’t actually affect things, but I will comment on it. The code works out how many treads are needed on an arc, i.e. to go around the sprocket, as the length of the arc divided by the length of the tread (as deduced from 1/scale value):
n = type->scale * 2 * pi * k->radius + 0.5;
This is making the assumption that the tread would be “bent” around the circumference of the sprocket, when in fact it is a chord between two notches. In reality this difference between arc length and chord length doesn’t have an effect.
Final Thoughts
Again, I’m not knocking LSynth – I’d be lost without it for making up cables. I just thought I’d investigate why I never seemed to get bands of treads right with it. My “fixed” lsynth.mpd file has made a difference as things are now better, but the perfectionist in me would prefer that the treads sit in the notches, so I’ll continue doing them manually.
When building up a model in Bricksmith it’s important to consider the orientation of the sprockets. You’ll want them rotated such that the treads sit in the notches correctly. Generally the sprockets are going to end up in one of two orientations, 90˚ rotation between them:
Notch at the top.Notch at the side.
The notch at the top is better as the treads will sit in the notch easily, whereas the notch at the side will require fine-grained movement to get the initial tread in place. For this particular post I will focus on the latter, i.e. notch at the side. Although this requires more initial set up the rotation of the treads is simpler. I will cover the other variant in a third post.
Rotation Controls
Since we’re wanting to place treads on the large sprocket, in my example, we’re going to want to rotate by 36˚. This is because there are 10 notches in the sprocket, so 360˚/10 = 36˚. The rotation controls are reachable from the Edit menu, and give a control box as below:
Edit Menu – note “Rotate…” a third of the way up.Rotation Controls.
All of our rotations will be around a fixed point.
Initial Tread Placement
The first thing to do is align a single tread with the sprocket. This is relatively easy, but in this orientation will require the fine grid for movement. The first tread ought to look like:
Initial Tread Placement.
How I Used to Do Treads – aka “Introducing Cumulative Error”
When I first started to model treads manually I’d start with a line of treads which I’d “bend” in to place:
A line of treads.
I would then select the first tread and rotate it about its pin. The coordinates of this pin can be found by moving the pointer around over the pin and observing the coordinates shown at the bottom of the Bricksmith window:
Coordinate information.
You’ll notice that two of these values change as the pointer moves but the third, in this example the x value, doesn’t. The two that change are the coordinates of the line passing through the tread’s pin.
Rotation about: 0, -45, -225First tread rotated by 36˚.
Next I select the the tread I have just rotated and its neighbour. I need to rotate both of them around the second tread’s pin. I know that the pins are 30 units apart, so I already know that the coordinates will be 0,-45,-195 without needing to check:
Two treads selected.
I now simply work my way back along the treads rotating around x=0,y=-45, and z=: -165 and -135. The result of this is:
Final result of a line of treads.
This all used to make sense to me as the simplest way of doing this. However I started to notice small errors in placement. This can be seen in that the first tread doesn’t quite sit in its notches, a close up is below:
Cumulative Error.
This is due to cumulative errors appearing. The first rotation is okay, but subsequent rotations slowly add errors to the placement. This first link has undergone 4 rotations around 4 different fixed points resulting in a small drift.
Being the perfectionist I am, this wasn’t acceptable, so back to the drawing board.
Individual Treads – aka “Doing it Right”
This time around we’ll only perform one rotation per tread, thus removing the cumulative errors. To achieve this copies of the top tread will be made, and placed in exactly the same spot, i.e. select tread, then cmd-C and cmd-V. This can just be seen in the image below with the wireframe inside the other tread:
Copy and Pasted Tread.
This tread will now be rotated 36˚around the centre of the sprocket, not its pin:
One rotated tread.
This will now be repeated, copying and pasting that top link, then rotating by 72˚, 108˚, and finally 144˚:
Second tread rotated.
Treads with Rubber Feet.
One of the comments I made in Part 1 was that LSynth didn’t support treads with rubber feet. To do this the first tread will need a rubber foot located with it, and then those two together can be copied and rotated as above:
Tread and Rubber Foot.Five Treads with Feet.
Completed Treads
Once the sprocket treads are in place, the top/bottom treads can be placed between the sprockets. For simplicity I copy and paste the initial tread placed on the sprocket:
Completed Treads.
LPub4 Parts List
Another comment I made in Part 1 is that the LSynth structure doesn’t show up in the parts list. Since the treads placed via the methods above are normal elements there will be a valid parts list shown both on the page and in any Bill of Materials:
I hope this makes sense. Feel free to leave comments if I need to make anything clearer.
Bricksmith and Treads – Why they aren’t quite right.
When it comes to making my building instructions (BIs) I use Bricksmith for OSX. It’s a brilliant package for making models and even better it comes with LSynth integrated in to it. LSynth is excellent at doing flexible objects – most specifically the EV3 cables. It, however, doesn’t handle treads at all well; which is what this post is about. I’m not knocking LSynth in any way, but want to focus on how to get treads correct in Bricksmith, which unfortunately will be a manual process.
I figure that I ought to start by showing why I don’t use LSynth for my treads. Here’s a model with some treads:
This all looks good; I’ve used “trans black” and “trans clear” for parts so that we can see through them. This model ought to have 26 treads in it, however if one counts what’s in this model LSynth has put in 30 of them. This leads to the following issues:
Overlapping Treads
If you look at the picture below you can see that two of the treads are overlapping, and occupying most of the same space. This happens twice in the model, top left and bottom right:
Compressed Treads
In the next picture it can be seen that the treads are far too close to each other. They are butted next to each other, but this results in the treads not joining at the pin / hooks which should be clear:
Misaligned Treads
The next picture shows that the treads don’t align with the sprocket correctly. The bottom most tread almost has its pin in the sprocket’s indent, but not quite. As the links carry on around they progressively get further and further out of alignment. This is probably related to the earlier observation about the compressed treads.
No Rubber Feet
This isn’t really an LSynth problem as such, but there is no option for a band of treads with the red rubber feet, as below:
No Parts List
Again, this isn’t the fault of LSynth, but when an LSynth element is presented to LPub4 it doesn’t see it as a list of parts, so no list is shown. See the image below; there are parts for the beams and axles, but none for the sprockets or treads:
Conclusions
Again, I will state that LSynth is brilliant for EV3 cables, but from my experience it isn’t the right tool for putting treads in to BIs. I much prefer to do those manually, which I’ll cover in Part 2 of this series.
I’ll be making another blog post soon covering how to use Bricksmith and LSynth to put together EV3 cables, including coloured ends.
