Affiliate disclosure: I sometimes use vendor & product links that can pay me a small monetary commission if you click them and/or make a purchase. Learn more about this. As an Amazon Associate I earn from qualifying purchases.

Wednesday, October 4, 2017

First reveal of my LEGO Boost MOC project


Some months ago, LEGO sent me a couple early production samples of their newest robotics system, Boost, and let me go to town with them.  I told them I wouldn't review the thing, but would instead focus on an original robot or gadget of my own design, form & function to be determined.  Here's the very first video footage of what I came up with:
To learn more about Boost, check out the official site and Brickset's first impressions. Having used the system extensively before and after its release, I can confirm that most of the full reviews on the 'web & YouTube were using the pre-production beta software (whether they made this clear like they were supposed to or not).  I can also happily report that many of the early reported issues of extremely limited device compatibility, glitches, and crashes have been addressed and the product that consumers can actually buy seems very stable.

Boost is an introductory robotics education platform aimed at kids as young as 7, a market that's generally not fully ready for something like Mindstorms.  Most Boost building is brick-based, with limited Technic parts usage as required for gears & axles & such.  The strictly tablet-borne programming interface (you supply the tablet) is mostly drag & drop and uses no words, just symbols and very deliberate and thorough tutorials that guide the first-time user through discovery and initial inspiration.  The core electronic component that you put batteries in & build upon has little to no "intelligence" within it.  Instead, your programs are actually run on your tablet, with only raw motor & sensor data being transmitted back & forth to your 'bot.


I'll show my little autonomous tank-bot in detail soon, but the basic concept is that it's sweeping the distance-sensing unit from the kit left & right to look for obstacles.  When it gets too close to something, it makes a decision, and turns to avoid a collision.  I used some of my own parts like narrow tank treads to keep the form factor as small as reasonably possible.  The code I'm currently running is pretty simple, though the amount of experimentation, hair-tearing & re-scoping I did along the way was a bit disproportionate.  Boost seems absolutely fantastic for its target audience, but if you try to extract much in the way of precision or multi-tasking from it, you will quickly encounter quite a number of... quirks.

Your programs are interpreted in real time, which introduces a non-trivial amount of latency, and the sense/interpret/command loop can be slow enough that you can watch it with your bare eyes.  You can create callable functions that can accept arguments, but they can't seem to return any information, and all variables are "local" -- inaccessible outside of the function where they're created.  The system is inconsistent about waiting for tasks to complete before moving to the next command.  All three motors (two in the main hub brick and one separate) are "encoded" so they can report their output shaft position (sort of), but they almost always over- or under-shoot when asked to turn to a specific orientation.  There's also play in the internal gearboxes and the position sensors sometimes hang a bit between degree ticks, taking up to several seconds to decide whether to round up or down.  Oh, and the thing won't drive straight.  It just won't.  It'll go a little to the left or a little to the right, and it's especially bad at low speed. My tank-bot's program tries to make some pretty drastic brute force corrections, depending upon which way it remembers most recently turning.  Even that's not enough, though.

Given the many limitations of this simplistic system designed for young kids, I'm actually quite happy with how well it works, even though I grew a lot more gray hair getting it to this point than I would have ever imagined.  I'll show the details of the physical design of the tank-bot in a future post, and probably demonstrate some of the code that survived the countless re-writes.

10 comments:

  1. Do you think a 12 year old beginner to "robotics" would also get frustrated with these limitations, or would say they were more born out of an adult's desire for more complexity?

    ReplyDelete
    Replies
    1. I don't think anyone before their mid-teens would even notice these issues and probably a lot of adults wouldn't either. I've worked in coding professionally for quite many years in the past and that really spoiled & tainted my perspective. Also this project was pushing the limits of precision with this system with such a small build working in fairly tight quarters. I'm not a good example of a user :)

      Delete
    2. I agree; most kids with little experience with robotics would not mind the limitations too much. After all, Lego Boost is a simpler, less expensive (not counting the tablet) alternative to Mindstorms.

      Delete
  2. Boost looks pretty cool, can't wait to get a few sets for myself and my kids to build!

    ReplyDelete
  3. When are you going to put out the insructions

    ReplyDelete
  4. I would also love to see/buy the instructions.

    ReplyDelete
  5. I bought my son a boost kit for birthday. I do developing in python for living but I was not able to do an programme which drives around and uses the distance sensor to avoid walls. Maybe I did not got into the think ing of boost. Thought it would be easy as driving until distance less 10 and then turning. But the action s are canceling each other's or interfere. Best was drive a second look for wall etc. But that sucks...

    ReplyDelete
    Replies
    1. I am a bit further now. I found that quite often the Hub needs to be resetet. It *seems* to work properly with the most sequential things but then asyncronous things don't work. Trapping in this pit I redid and try hours without success. Then my batteries went low and suddenly It worked. I replaced them... Not more...

      I now use a state machine to toggle between Idle/Init Driving and avoid collision. That works some time but then after some testing the LED on the hub blinks yellow a few times and the robot runs into walls. After that I have to reset the hub. Mostly even restart the app. This sucks. I wonder if this is normal, I read many complaints about loosing BT etc. Or if my hub is not 100% ok?

      Here is my "Code": https://photos.app.goo.gl/TBgY1XvoV6nPDASbA

      Modell is Vernie. I did not found any lively forum or discussion board, so any pointers are welcome

      Delete
    2. Why could not you just use https://github.com/JorgePe/pyb00st for it?

      Delete
  6. I'd like to know how the scanning of the sensor is coded so it turns the corect way

    ReplyDelete