Lego PoweredUp bugs/missing features

Lego Powered Up is a mixed bag of features. There are some great ideas and many not that great. I sometimes wonder, if the app gets any sort of testing before being released to the public. It gives me the impression of something quickly nailed together and shoved out of the door without any QA.

Quirk #1: The absolute motor position

If you go to https://www.lego.com/en-de/product/technic-large-motor-88013 you will read under ‘Specifications’

Breathe life into LEGOÂŽ Technic™ creations with the LEGO Powered Up Technic Large Motor (88013). Whether it’s powering a steering mechanism or system of gears, this motor gets the job done.

Features an integrated rotation sensor and absolute positioning for accurate speed and position control.

Well, sounds great, doesn’t it? Finally a proper steering servo. I bought two of these only to find out, that while the motors DO have an absolute position sensor (within one revolution, not a multiturn one), the LEGO Powered Up App in version as of 13.DEC.2020 does not give you access to it. You can go for PyBricks and get use it, but that loses the remote controller support. No workaround known.

How about false advertising, LEGO? A feature advertised but not accessible to end user shoud qualify, or?

Quirk #2: Input and display ranges of the Powered Up App

The next annoying thing is that the programming blocks’ input fields don’t let you type in anything above 9999. That would be likely a non-issue, but the positioning blocks (i.e. “motor A, please turn to this-or-that position”) take only degrees as an input. You can’t specify “two turns”, you have to put in “720 degrees” in. While it sounds like much, 9999° is only just shy of 28 turns, not much if you have any sort of gearing and, say, a crane or a lift application.

There’s a funny inconsistence in there, using the ‘spinning wheel’ input you can go well beyond 28 turns and the block will take it and process it properly, in the example below the motor has turned the specified 40 turns and stopped at target, just the displayed numbers will still be 9999.99 instead of the actual values:

As you can see, this ‘9999’ limit is not really any internal limitation, the input ports will take much higher numbers without a hitch, it’s just a GUI issue, you just can’t type in more than four digits, the actual number range is much, much higher, which leads me to a workable work-around:

You can use the math block to make a more reasonable input form for applications where you think in terms of multiple revolutions – just add a “_×_” block and put 360° as one input. Since the ‘9999’ thing is only input limitation, you can now go up to 9999 turns.

As you can see, the motor position sensor will also report the proper value way beyond 9999.99 degrees, you just can’t see it directly – but you can feed it through math blocks and it will process properly. In the picture above I work around the four-digit display input by calculating the number of thousands as round_down(position/1000) and separately get the remaining digits by taking (position mod 1000). So in the image above the actual position is 14413 degrees or 40.04 turns.

I tested it up to 200’000 degrees and it worked without an issue. I don’t think you can hit any sort of an actual data range limit in a realistic scenario, it’s just the data entry/output GUI problem.

Quirk #3: The issue of negative distances

A go-to-relative-position block takes two inputs: speed and distance to turn. Both numbers can be positive or negative. The common logic would be, that if both numbers are positive, motor turns one way, say, clockwise. If one of these is negative, the motor should turn the other way – you either move positive number of degrees in a negative direction (speed<0; distance>0), or you move a negative number of degrees in a positive direction (speed>0; distance<0). This is the way it worked in Mindstorms EV3, this is the way it works in industrial servo applications, this is the way you want it to be for, i.e. position tracking applications (where you can easily substract actual position from setpoint position and know how many degrees you need to move, which can be a negative number).

But not so in Powered Up App:

First motor behaves as expected: moves one turn in positive direction.

Third motor too, negative speed, positive degree count, moves one turn in negative direction.

But the middle motor doesn’t move as expected. It should move negative number of degrees, but instead it turns in the positive direction. WTF?

I got bitten by this when I wanted to make a motor to track position to sit exactly in the middle between other motors, which were controlled independently. In one approach I was using a differential move to catch up and it wasn’t working as expected – the motor would always move in the same direction, even if the correction was negative.

Just for the sake of completeness: if both numbers were negative, the motor should turn in positive direction. It doesn’t.

Quirk #4: Not so logical logic

Last, but not least: we have logic operators “and” and “or”. But there’s no negation! In many cases you can work around this by using other operators, like turning comparison around, but when you want to react to releasing a button in the “remote panel” interface, you need a negation. Luckily, there’s a workaround:

It’s not obvious, because it seems that the port formats (pointy triangle for logic and rounded for other data) would be incompatible, but you can use compare-to-zero as “NOT”.