Jander's LEGO® Stuff

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:

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.

The Joy of Making Changes – aka “Having to Redesign Stuff … Again”

So, I’m currently in the process of developing my latest project: WEAV3R. This is to be a fully programmable “Jacquard” loom, i.e. apart from doing plain weave, it can do twills and, even more importantly, damask patterned weaves. Here’s a teaser of the heddles going through a twill pattern:

But, that’s not what this post is about 🙂 What I’m commenting on is the joy of redesigning a model, or part thereof, to make it right. Where I’m up to with the WEAV3R is the pattern input scanner. This is so that people can create a pattern on a 16 x 32 baseboard and for it to be woven into the cloth (well, most probably scarf as it’s only 32 warps wide). An example of a baseboard pattern is below:

This board is then placed in a holder, and then that in to a scanner:

Now, I was happy with my design on the whole, but I started to see a snag/annoyance. The scanner underneath, looked like the image below, along with a zoom in on the drive gearing:

The frame that holds the baseboard for scanning has two rows of 1 x 4 racks underneath, which are driven by the pairs of 24T grey gears either side of the scanner. I use two pairs as I have a need to scan beyond the ends of the board for calibration purposes, and they both need to be driven hence the “gear box”. It’s this gearbox that started to annoy. There is a medium motor at the back driving the first of the 20T beige gears. Due to the other 20T gears in between the second 24T gear has a reasonable amount of backlash. Thus when the racks roll from one joined pair of gears to the other there is a slight mismatch in the orientation of the teeth, causing a clunk noise, and a small judder.

Okay, time for a redesign. Rather than use a gear box I’ll mount the medium motor between the paired gears, and drive them centrally. This has the benefit that both rack drive gears will always be in the same driven orientation. The new motor and gear arrangement is as below:

Brilliant! It’s all nice and neat, rigid enough and no mismatched backlash. That’ll work perfectly … oh no it won’t! 🙁 The scanning frame is now catching on the top of the motor – D’oh. The frame looked like below:

This shows the top view. The central frame and 45° bent lift arms are to make it more rigid. The issue I now had hit is that the frame, when sitting in its slot, is riding very slightly low due to the 7mm / 8mm beam dimensions along with a very slight droop in the lift arms due to the weight. The lift arms needed to be removed or raised up by one beam’s height. Due to the location of holes this just couldn’t happen in the space allowed. Some pondering and some tinkering this morning I came up with:

So overall the same level of rigidity without too much extra mass to worry about [It’s been slightly altered since then, but only cosmetic].

So, as usual, redesigning one section has a knock-on to other areas 🙂 This is all part of the fun of building things to me. The Jacquard selector mechanism for the loom is on revision 8 at least, as I’ve built that up and had to go back on sections. The worst of course is where one has to dismantle almost the whole thing to change a small inner part 😉 I think that happened on revisions 5-7 of the Jacquard!

Over the next couple of weeks, as I get time, I’ll get on and code the scanner up and post a video of it at work. That in itself will be an interesting challenge, especially as I want it to send the resultant scan, via Bluetooth Mailbox messages to the 2nd EV3 that’ll be driving the Jacquard.

Watch this space …

Project “Ripl3y” – Part 1

So, I’ve started work on my next project. I’ve had plans for this since around May, but haven’t had the opportunity to start on it until now – this will keep me occupied during the long Autumn/Winter evenings 🙂

I want to get a bit further with my build before I discuss what it will ultimately do, so for the moment it is codenamed “Ripl3y”. Here are a few pictures of what I have so far:

This gives me an X-Y mechanism for the core function of the project. It’s interesting using a mix of the stud-less and studded beams. It’s been quite a number of years (decades) since I’ve used studded beams, so I’d forgotten that they are essentially 1/2 a beam out of alignment with the stud-less versions. Thankfully that’s not caused me any issues. The build will ultimately have another four long linear functions that use the rack pieces, so this has been a good learning exercise.

Here’s a video of it initialising itself and going through a simple test routine to check that I’d got my degrees of rotation calculations correct:

I’ve got a lot more building, and I mean a lot more, so I’ll be posting more about it soon I hope.

EV3 Mailbox Messaging

So, I’ve carried on with my work on writing an AI2 app to send Mailbox messages via bluetooth to an EV3. I now have a platform I can work with for my particular needs.

Before I discuss my results, I figure it’s worth covering the path that’s lead me to this point. Back in July I was showing off my Plott3r at the Manchester Bricktastic event. One thing the children often asked was could it write their name. The answer to this was ‘no’ since there was no way of getting user-defined text in to the Plott3r (irrespective of no ‘font’ being defined). So since then I have been looking at how to do this. My options have been:

LEGO keyboard – very complex, but I’m still considering mechanisms.
“Pantograph” style pen mechanism – too much backlash in my prototypes to be accurate.
Ultrasonic triangulating system – this would work out where a stylus was over a keyboard layout. This proved too jittery and inaccurate.
Using an old mobile phone to send a text message to the EV3.

The last one of sending a text message seemed to be the simplest. Many kinds are used to using a touchscreen keyboard, so would be easiest to use. So the next challenge was to work out how write an App to send text to the EV3. After some searching and chatting I came across MIT’s App Inventor 2 which looked perfect for the job, especially as it has EV3 support for some things. So that’s what I’ve been working on.

Unfortunately for me AI2 doesn’t (yet) have support for Mailbox messages with the EV3. Since it has a SendBytes method for the bluetooth client I could look at how to send a ‘raw’ Mailbox message. Thankfully there are quite a few good resources out there; two of which I found useful are:

They had enough information in there for me to construct a simple message that I blogged about previously (My First BT Message). Since then I have expanded on that to produce a procedure that can take variable input text messages.

I’ve had to go down the path of implementing IEEE 754 so that I can send floating point numbers to the EV3. These are the reasons why:

I want to send a string of text to the EV3 to be plotted.
That text has to be sent as a Mailbox message.
EV3g, the default language, has poor text manipulation capabilities so I’d have to send one Mailbox message per-letter.
I implemented the text Mailbox method that can take any length message even though I’d only send one letter at a time – getting the Android device to do the text string manipulation.
My original concept of taking each letter and looking up, using a huge switch statement, the stroke paths needed for that letter won’t work. It’s not (apparently) possible to have a switch statement case that can match a double quote “, or a newline \n. Oh dear.
Since the app is already converting the text into ASCII values I could just send them over instead. That way I can match numerically on ASCII 10 and 34. This has the added advantage that I can then use array lookups instead – look up in one array for the offsets in to the stroke data.
I can’t just send raw byte values. The EV3 uses IEEE 754 floating point for numbers, so I have to send that in a Mailbox message.
Oh dear – AI2 doesn’t have a native IEEE 754 implementation. Oh well, let’s write my own!

So here I am. I’ve now written an IEEE 754 implementation. It’s incomplete as it doesn’t handle underflow at all, but does do the number range that I need, zero, and NaN. I only need to send 0-255 over, but it does do most of the numbers that the EV3 will realistically need to deal with.

The value entered was 314159.26 but was sent/received as 314159.25. This is correct for a 32 bit float, and is confirmed via Perl scripts and an online converter.

The AI2 code is available from:

http://jander.me.uk/LEGO/resources/Testing_Ideas.aia

and as usual is published under the Creative Commons Attribution-ShareAlike 4.0 International License.

I still have a lot of work to do:

I need to split the text into individual letters to send the ASCII value.
I need to program the Plott3r to accept a stream of values and special codes to plot.
I need to work out some form of ‘font’ to be plotted.
The final app needs to be written to make it easy to use.
A LEGO® ‘holster’ needs to be made to hold the phone 🙂

They’ll take a while, but I’m a good way there, I already have ideas for how to do points 1-3, especially 2-3, so we’ll see how they pan out. Updates to come.

Update on my Bluetooth EV3 Mailbox testing.

I managed to focus some more time on tidying up my AI2 app for sending Mailbox messages via Bluetooth from my Android phone to an EV3. The EV3 code is really simple and looks like this:

The AI2 code provides two BT related buttons, Connect & Disconnect, a text box and a Go button to send the text:

Screenshot_20160825-211129

When the text is entered and Go pressed it is sent as a Mailbox message with the name “beep” to the EV3, and displayed on its screen. The code to send it has to construct a message in the form:

MLenL, MLenH, 0x01, 0x00, 0x81, 0x9E, NLen, NameBytes, 0x00, TLenL, TLenH, TextBytes, 0x00

Which breakdown as:

MLenL, MLenH = 16 bit little endian length of the rest of the message
0x0001 = Message counter
0x81 = System command, no reply
0x9E = Mailbox message
NLen = 8 bit name length, including 0x00 termination
NameBytes + 0x00 = The Mailbox name
TLenL, TLenH = 16 bit little endian length of the text
TextBytes + 0x00 = The Mailbox text

This in terms of code looks like:

If you would like to play with the code it’s available from my resources site at:

The code is released under the Creative Commons Attribution-ShareAlike 4.0 International License

My First BT Message !

The code above may not look much, but I’m very pleased with it 🙂 I’ve been working with MIT’s App Inventor 2 in an effort to build an app that can send text (in some form) to the EV3 for further processing – that code has managed it!

I’d extended the EV3 tilt-to-drive tutorial from the AI2 site to add in an extra button, that when pressed runs that code. It’s fixed at the moment but it encapsulates (little endian) 0x0018, 0x0001, 0x81, 0x9e, 0x5, beep\0, 0x0006, Beep!\0. All this info has been derived from the LEGO® Communications Developer Kit docs.

To test this I had a simple program, as below, running on the brick:

Press the button on the app, and the EV3 beeps – superb!

It also shows an interesting behaviour which I may well exploit in an upcoming model – I had one program running on the EV3, solely to beep, but was still able to drive the bot from my phone. Being able to externally control an EV3 whilst it is running its own program has a lot of merit.

Developing an Android App for EV3

At the Bricktastic event back in July I showed off my Plott3r as part of the Mindstorms exhibits. It was programmed to do the Hilbert and Dragon curves, several plot “files” and some other bits.

One of the questions that the kids kept asking was something along the lines of “can it write my name?” Unfortunately it wasn’t, and isn’t, capable of writing ad-hoc text. So since then I’ve been pondering ways of supplying user-provided text. I did consider an ultrasonic triangulated “keyboard”, but the US sensors got confused with each other’s signals – so for the moment I’ve put that idea to bed to be revisited in the future. My original thought, however, was “can I do this with a mobile phone?”

Since that original thought I’ve been looking at how to write an Android app that has a simple text box and “send” button. Kids are used to mobiles these days, so it seems to me to be the perfect UI. So far I seem to have settled on using MIT’s App Inventor 2. It does support EV3 to some extent, but I’m going to have to get down and dirty with the EV3 byte code to send mailbox messages via bluetooth 🙂

So, now I need to get learning how this AI2 system works. Thankfully they have tutorials, so I’ll be building the tilt/move tutorial soon to get to grips with communicating with the EV3. Tinkering with bytecode won’t be too daunting as I’m used to getting down to that level of bit twiddling via my current and previous jobs.

Nothing to show yet, but watch this space!

DuckToppl3r BIs are now complete!

DuckToppl3r

I have now completed the BIs and commented the code to the RobotRemix3 DuckToppl3r! The announcement of the MCP RR3 challenge can be found at: http://www.thenxtstep.com/2016/07/robot-remix-3.html

My guest blogger post can also be found at: http://www.thenxtstep.com/2016/07/duck-toppl3r-robotremix3.html

The BIs and code are available from:

BIs PDF: http://jander.me.uk/LEGO/resources/DuckToppl3r.pdf
Low(er) res BIs: http://jander.me.uk/LEGO/resources/DuckToppl3r-lr.pdf
Code: http://jander.me.uk/LEGO/resources/DuckToppl3r.ev3

Enjoy – I did doing this 🙂

Text per-page for LPub4

LPub4 offers a way to add text to a page, but no option for text to appear on every page. Whilst working on the BIs for the DuckToppl3r I had a need to put a disclaimer on each page. I am lead to believe that LPub3D can do this, but that is currently a Windows-only program. Since LDraw and LPub4 use text and I’m no stranger to Perl I figured a quick script would come to my rescue 🙂

LPub4 produces a new page on each STEP or ROTSTEP statement when not in a multi-step page, or on a “MULTI_STEP END” statement. So, all I needed to was to output the same “INSERT TEXT” statement above one of those three where relevant. The code used is as below if this proves to be useful to anyone:

#!/usr/bin/perl

use Getopt::Long;

$first = 'The MINDSTORMS® Community Partners present ROBOTREMIX3 [31313 + 42050] Community Challenge 2016. DUCK TOPPL3R Design & Building Instructions by Jerry Nicholls.';
$second = 'MINDSTORMS is a registered trademark of The LEGO Group. This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License. August 2016';

GetOptions( 'first=s' => \$first, 'second=s' => \$second );

$multi = 0;
while(<>) {
 $multi = 1 if /MULTI_STEP\s+BEGIN/;

 if ((!$multi && /^0\s+(?:ROT)?STEP\s/) ||
     (/MULTI_STEP\s+END/)) {
     $multi = 0;
     print <<"TEXT";
0 !LPUB INSERT TEXT "$first" "Helvetica,18,-1,5,75,0,0,0,0,0" "Black" OFFSET 0.06 0.935
0 !LPUB INSERT TEXT "$second" "Helvetica,18,-1,5,75,0,0,0,0,0" "Black" OFFSET 0.06 0.95
TEXT
  }
 print;
}

Attempting to start blogging about my LEGO® models.

DuckToppl3r

I’m going to try to start to blog about the models I’ve built, those I’m pondering on, and those that are in progress.

Some weeks back I started on the RobotRemix3 DuckToppl3r project (http://www.thenxtstep.com/2016/07/robot-remix-3.html) and am very close to releasing the BIs (Build Instructions) and the .EV3 code file to the public. When that happens, I’ll blog on here again. In the meantime here’s a link to TNS’s article on it: http://www.thenxtstep.com/2016/07/duck-toppl3r-robotremix3.html

For simplicity I’ll probably keep my BIs and code on my original site to save lots of copying around.