Further Investigations into LSynth and Treads

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:

0 // Technic Sprocket Wheel 25.4
1 25 0 0 0 1 0 0 0 1 0 0 0 1 57520.dat
0 // Technic Sprocket Wheel 40.4
1 50 0 0 0 1 0 0 0 1 0 0 0 1 57519.dat

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.
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:

0 FILE TECHNIC_CHAIN_TREAD_38.ldr
0 TECHNIC_CHAIN_TREAD_38 SYNTHESIS DEFINITION
0 Name: TECHNIC_CHAIN_TREAD_38.ldr
0 Author: Willy Tschager
0 Unofficial Model
0 SYNTH BEGIN DEFINE TECHNIC_CHAIN_TREAD_38 BAND FIXED 0.03571 8
0 // Technic Chain Tread 38
1 0 0 0 0 0 1 0 0 0 -1 -1 0 0 57518.dat
0 // Technic Chain Tread 38
1 0 0 0 -32 0 -1 0 0 0 1 -1 0 0 57518.dat
0 SYNTH END

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.
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.

Bricksmith and Treads – Part 2

Sprocket Orientation

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-top
Notch at the top.
notch-at-side
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.
Edit Menu – note “Rotate…” a third of the way up.
Rotation Controls.
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
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:

line-of-treads
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.
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:
Rotation about: 0, -45, -225
First tread rotated.
First 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.
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.
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
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:

Cut and Pasted Tread.
Copy and Pasted Tread.

This tread will now be rotated 36˚around the centre of the sprocket, not its pin:

One rotated tread.
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.
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.
Tread and Rubber Foot.
Five Treads with Feet.
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.
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:

lpub4-parts-list

I hope this makes sense. Feel free to leave comments if I need to make anything clearer.

Bricksmith and Treads – Part 1 “Not Using LSynth”

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:

lsynth-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:

overlapping-treads

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:

bad-tread-spacing

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.

misaligned-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:

tread-with-rubber-foot

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:

lpub-no-tread-plist

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.