Further AI2/EV3 Bluetooth Coding

As my recent posts, Receiving BT Mailboxes from EV3 by an AI2 App & Updated BT comms between EV3 and AI2, have indicated, I’ve been working on getting AI2 app sending and receiving EV3 Mailbox messages via Bluetooth.

One of the annoyances I’d had is that the EV3 needs to know the name of the AI2 device in order to send messages to it. Up until now that name has had to be entered in to the AI2 app by the user. This of course is prone to error in different ways. There wasn’t a way of getting this information via the available AI2 components. So, I’ve added to my EV3Mailbox extension. It now has a GetDeviceName call which will extract that information to be used however one wishes. In my code I use this name to send a message to the EV3 on connection, for it to use in return messages. Example AI2 code is as below:

AI2 BT Test Code


As usual, I am making my code available for use under the Creative Commons Attribution-ShareAlike 4.0 International License

The sample .aia file should include the extension .aix file, but I am also making that specifically available for use in other people’s projects.

  1. Run the EV3 code first.
  2. Start the AI2 app.
  3. Press “Connect EV3”. This will give the list of BT devices known the the Android device. Choose the correct EV3.
  4. Once the App is connected to the EV3, the EV3 will say “detected”.
  5. Pressing the top, middle, or bottom buttons on the EV3 will send a BT message to the App:
    • A string for the top button
    • A number for the middle button
    • A boolean for the bottom button.
  6. The App will then display the message name and contents in the top two boxes.
  7. You can send string, number or boolean values back to the EV3 via the relevant boxes and buttons.

Updated BT comms between EV3 and AI2

Recently I posted about sending Bluetooth messages from and EV3 to an AI2 app. I decided at the time not to bother considering handling receiving IEEE754 floats as strings would work. Since then I have been thinking about how cluttered the code was, and that AI2 doesn’t easily support libraries of AI2 code. So, I started investigating writing a simple EV3Mailbox extension for AI2. After a bit of learning Java (I’m a Perl programmer at heart) I now have an extension:

EV3Mailbox Extension

The extension is still quite simple, solely handling the packing and unpacking of the message bytes. The Bluetooth comms part will still need to be performed by AI2 code. An example of using this to send/receive messages is as below:

Sample send/recv AI2 code.


As usual, I am making my code available for use under the Creative Commons Attribution-ShareAlike 4.0 International License

The sample .aia file should include the extension .aix file, but I am also making that specifically available for use in other people’s projects.

  1. Run the EV3 code first.
  2. Start the AI2 app.
  3. Long-press the BT button. This will bring up a settings box.
  4. Enter the App device’s Bluetooth name in the settings – and press ‘save’. This will be stored, and sent to the EV3. This is so that the EV3 knows where to send its messages to. This must be the same name as shown in the BT connections list on the EV3.
  5. Press “Connect EV3”. This will give the list of BT devices known the the Android device. Choose the correct EV3.
  6. Once the App is connected to the EV3, the EV3 will say “detected”.
  7. Pressing the top, middle, or bottom buttons on the EV3 will send a BT message to the App:
    • A string for the top button
    • A number for the middle button
    • A boolean for the bottom button.
  8. The App will then display the message name and contents in the top two boxes.
  9. You can send string, number or boolean values back to the EV3 via the relevant boxes and buttons.

Receiving BT Mailboxes from EV3 by an AI2 App

Recently, on the MINDSTORMS Facebook group, the question was posed about is it possible to receive Bluetooth mailbox messages in an AI2 app from an EV3. This is something I’ve been meaning to do for a while. I’d written AI2 code to send BT messages to an EV3, but hadn’t focused on receiving messages. This was the spur to actually get this code written.

It wasn’t too tricky. Receiving the message was simple, but parsing it was the harder part. The format of a message from the EV3, as covered in my update to BT messaging is:

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

This is received as a string of bytes, so has to be parsed as a list. Add in that there doesn’t appear to be a chr(x) type function in AI2 to convert from a number to its equivalent ASCII character, I have to do some array/list lookups. Thankfully I had that code in place for sending to the EV3.


I’ve got the code to a position that it can hopefully be used for other purposes. I’m releasing what I’ve done so far as a baseline for others to work from. To make the code, linked below, work do the following:

  1. Run the EV3 code first.
  2. Start the AI2 app.
  3. Long-press the BT button. This will bring up a settings box.
  4. Enter the App device’s Bluetooth name in the settings. This will be stored, and sent to the EV3. This is so that the EV3 knows where to send its messages to. This must be the same name as shown in the BT connections list on the EV3.
  5. Press “Connect EV3”. This will give the list of BT devices known the the Android device. Choose the correct EV3.
  6. Once the App is connected to the EV3, the EV3 will say “detected”.
  7. Pressing the top, middle, or bottom buttons on the EV3 will send a BT message to the App.
  8. The App will then display the message name in the top text box, and the message text contents in the bottom box.

The code only handles text message. I have no plans to develop code to handle numbers or booleans. The EV3 code will coerce those data types to strings if sent as a text message. AI2 will coerce strings to numbers if they look correct, so if the EV3 needs to send a number, simply send it as a string, and the AI2 App will still do the Right Thing™.

Images and Code

AI2 Code Image

The AI2 code and Ev3 code may be obtained from:

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

Producing Complex Structures on the EV3DPrinter

So, for the past few weeks I’ve been working on my build of the EV3DPrinter. I’ve had it printing various geometric shapes, “College” letters, and more recently I’ve been working on a complex shape – namely a castle:

A Small Castle
A Small Castle


Since I’ve been programming my instance of the EV3DPrinter in EV3G I couldn’t realistically use G-Code as the string handling in EV3G isn’t up to the task. Instead I would do it some other way.

For years I’ve been using a very old X11 drawing package Tgif; this has the great advantage that its file format is text based, and object oriented – a perfect source of drawing data. I used this package to draw out my letters:

Letters in Tgif
Letters in Tgif

This worked perfectly as it was easy to convert the polygon path of each letter in to a simple set of coordinates for use in my code on the printer. I was however accidentally fortunate in that I’d aligned the letters to a grid, so could work out which one was which based on rows and then position along that row.

When it came to making the castle I figured I’d use the same program to develop each layer, and just write a new Perl program to parse the file into plot data. It was rather more complex than I’d thought. I had to design each and every layer of PLA, bar those layers that repeated, i.e. the first 5. So, first, I started off with just the base of the windows:

Base of the castle’s windows

This took two goes as the first time I had the slope at the bottom at too shallow an angle, so they sagged badly. Next I worked my way up the walls:

Working out the walls

Eventually after some trial I got to the final castle.

Process – First Version

The luck I’d had with the letters couldn’t work with a complex object. I needed to be able to define a layer’s polygon, its position relative to the layer below and some form of order. The simple answer, for me, in Tgif was to have a bounding box, a text object with a number, and a polygon inside the bounding box, as below:

Layer 27 of the castle

Layer 27, above, is closing up the tops of all the windows and the doorway, along with producing buttresses for the crenelations at the front. So here, there is the box, the number “27” and a polygon – the just visible arrow on the inside bottom left defines the end point of the path for that layer. The line width of the polygon defines how many layers are to be repeated for this path – 1 in this case.

This was a time consuming process, which did work, but resulted in 42 layers. The final Tgif image looked as below:

Final Tgif file for the castle

Process – Second Version

Although the Tgif images, so far worked well, it was a lot of effort. Discussing with a colleague, he asked why I couldn’t define a start and an end and layer-by-layer go from one to the other. A bit of thinking and a new plan came to mind.

The same system of box, text, and polygon would be used by a way of linking a start and an end would be used – a simple dotted box would group two layers together. The layer numbers would define the start and end, and all layers between would be interpolated between the two polygons. Of course both polygons would need the same number of points, but that’s fine.

Some new coding, along with spotting a mistake in my first castle, and I get the new Tgif image of:

13 layers to define the castle
Close up on layers 22 – 27

This is so much easier to manage. I’m now thinking on what to make next. I’ll be writing another program that will be able to read in multiple complex models and give a menu to select what to make. Once that’s done, I think I’ll be ready to publish my code – watch this space.

New Plott3r Pen Holder

Whilst preparing for Bricktastic I developed a new, and hopefully better, pen holder for my Plott3r. This holder is a little heavier than the original, and somewhat more solid. This ought to remove some of the small erratic movements from the plots.The PDF for the building instructions can be found at:


The LDR file if you wish to load it in to an LDraw package is as below:

Plott3r Pen Holder LDR file

It should be noted that the pen holder will need to be built on to the tracked section, it cannot be clipped on like the original. Build the base, attach it to the tracks, then clip the front and back sections on to it.

EV3 Text Plotting

Okay, so I’ve been rather quiet on the blogging front for a few weeks – that’s because I’ve been working on getting my Plott3r to write out text:


Here’s a video of it taken a little while ago (prior to some of the improvements I’ve made):

This has been rather a journey of discovery. I’ve blogged previously about getting a bluetooth message to the EV3 and how I needed to work out a font.


The font itself didn’t prove to be that tricky to work out; it’s mainly been planned out on 5mm graph paper and simply converted into coordinates. I’ve tried to have it write the letters as a Left->Right writer would, so starting on the left side of each character and probably ending on the right. This way moving the the next letter doesn’t involve a lot of travelling.

Backlash Correction

One thing my Plott3r has, is an effort to manage backlash. Since the paper and pen change direction regularly I have a system that pre-moves the paper/pen a little prior to any change in direction. One thing I hadn’t realised before is that if I want to move a really small amount I could overshoot where I wanted to be just in my backlash correction. This would cause some oscillation around the correct location in some cases. For example, look at the centre of the spiral below:

Backlash over-compensation

The centre of the spiral is crooked due to the pen “seeking” around the correct location. My solution to this was to measure where I was before the backlash correction, and after. If I had overshot, then I did not move that particular axis. The results of this improvement on the spiral are below:

Overshoot corrected backlash

Android App

I wanted to be able to send a message from a spare Android phone to the EV3. Here’s where App Inventor 2 came in. I had to learn how it worked, along with learning its Scratch-like language, and implementing some fundamental routines, such as storing an IEE754 float. The current instance of the application looks like:

EV3 Messenger

The user can simply choose between 3 text sizes, and then write their message and press “Print”. The BT button is used to set up the Bluetooth connection and the name of the sending device; this is needed so that the EV3 can acknowledge message it receives. I found that if I didn’t ACK the messages there was a race condition whereby I’d get duplicate values with the second “overwriting” what the first should have been. The core code of the messaging app is below:

AI2 Core Code

At the start of the block you can see it send its name, and towards the end of the block it waiting for a bluetooth message. It doesn’t care about the contents of the message, simply that it got one. The EV3G side of the code is as below:

EV3G Messenger

What’s not shown is the plotting code as that’s quite complex. It keeps a tally of the location of the last plotted character and works out if the next one will fit; performing <cr><nl> if needed. The font is variable width, and has a small amount of “kerning”, so that letters such as ‘j’ and ‘q’ can overlap the inter-character space.

Letter Sizes

I originally was only going to have one letter size, but this would allow for only around 11 characters per line, which isn’t a lot. Shrinking the letters will result in more artefacts, which I’ll come on to later, but I think it has a certain “hand writing” charm:

Three letter sizes


There are a few artefacts that I’ve tried and tried to remove. I now think I’m simply fighting with the simple fact that it’s made from LEGO bricks and I can only realistically get a certain level of accuracy in the way I’ve built it. The main artefact left is as below:

Artefacts on 0, G, Q et al

If you look at the top and bottom of the 0 (zero), G and Q, there are small overshoots on one side of the diagonal. I think this is down to using Tank Move and the Y axis motor overshooting the target before moving back a little – a result of the internal PID controller.

Signing Off

I’ll be showing this off again at Bricktastic this year, hence all this work. I’m pleased that, due to my desire to plot text, that the backlash control is better. I figured that I’d have the Plott3r do one more thing. It now “signs” its plots with the URL to this blog 🙂

Signing off

I now need to put this to bed for a bit whilst I check that all the other models still work. Then I need to get back on with my Loom – I need to do a little bit of programming for that ready for it to be shown off too.

LEGO World 2017

My Weav3r loom and I were invited to exhibit at the MINDSTORMS booth at LEGO World 2017 this year – what a blast!

Lots, and lots, and lots of people.

I had a deadline of the end of January to get the loom built and mainly functional in order to get it shipped out to Denmark. So, lots of hours in my attic across New Year, and coding in the last week of January to get it ready. One thing I did learn is that LEGO axles that need to slide, as opposed to rotate, do not mix well with traditional English Christmas cake! I managed to get icing on the axles which then turned into adhesive goo, preventing the heddles from setting – oops!

Set out on the night before.

I was so glad that it worked after being transported. I had packed it with a very large amount of bubblewrap, and the only thing that had dismantled was part of the heddle selector’s gear rack. Here’s a video of it working on Day 1:

This was the first time it had actually woven anything of any length, so I was still learning how the machine would actually run. You can see in the video that the wefts are quite spread out in places. That’s due to the cloth wind-up drum running at a constant angular velocity, so as the day ran on the cloth would wind faster and faster. This lead to me altering the programming before breakfast on Day 2 🙂

The first day’s scarf.

The change to the programming allowed me to alter the angular rate of the winding reel throughout the day. This meant that as the scarf got longer I could slow it down, keeping the weft spacing in good order.

Here’s a video of it running on Day 3. This is an attempt to show how the “Jacquard” part of it works. There is a selector that can move along the 32 heddles and set a pair of pins, to the front or back, to set which ones go up or stay down. The video is not as clear as I’d like so I shall shoot another soon:

Unfortunately the loom stopped working towards the end of Day 3. It ceased to be able to align correctly, resulting in the heddle lifter arm jamming up. This happened just before the Owner of LEGO turned up:

Kjeld looking at the loom – thanks to Martyn Boogaarts for the photo.

Fortunately for me he’d seen it working a few minutes before – phew!

On investigation for the rest of the afternoon, and the next morning it appears that one of the motors wasn’t functioning correctly:

Wounded in Action.

On Day 4 the loom, with a new motor, it worked wonderfully. The final scarf is as below:

This was an amazing event, and taught me lots about the loom. I have several upgrades planned for the loom, but before I start on those I need to take some better pictures and video for here and YouTube.

One of the flattering things was that a few people asked if they could buy one of the scarves. Since it was the first outing of the loom I declined that – I kept the first and last of the event, and gave two to members of the MINDSTORMS booth.

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:

IMG_20161002_210840349 IMG_20161002_210934327

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:

IMG_20161002_210858454 IMG_20161002_210858454-cropped

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:

P1060801 P1060802 P1060807

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:

  1. I want to send a string of text to the EV3 to be plotted.
  2. That text has to be sent as a Mailbox message.
  3. EV3g, the default language, has poor text manipulation capabilities so I’d have to send one Mailbox message per-letter.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.

blocks (5)Screenshot_20160904-131036Screen Shot 2016-09-04 at 12.59.45IMG_20160904_131100687

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:

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

I still have a lot of work to do:

  1. I need to split the text into individual letters to send the ASCII value.
  2. I need to program the Plott3r to accept a stream of values and special codes to plot.
  3. I need to work out some form of ‘font’ to be plotted.
  4. The final app needs to be written to make it easy to use.
  5. 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.