Strange behavior with 51515

[Glaysche]

I just upgraded to the Mindstorms iOS app v10.1.0 that came out yesterday.  First, a major thing was fixed.  The PoweredUp linear motors (L and XL) now work properly and I can read relative and absolute position.  This unblocks me quite a bit.  Now I am seeing some strange behavior.  To replicate this behavior, I have a very simple program:

Motors 'F' and 'B' are hard coupled together in opposite directions to power the tilt axis on my robot:

The code under test is the 'Elevate_move' function.  The goal of the function is to move the motor a relative amount as fast as possible.  Passing in '1000' will move one motor 1000 degrees in one direction and the other 1000 degrees in the other.  Passing in '-1000' will move them in the opposite directions.  As a test, I call Elevate_move(-1000), Elevate_move(1000) right at the start of the program.  I expect it to move both directions when the program starts.  The actual result is that it moves quickly in one direction and very slowly in the other.  Neither direction is as fast as moving the slider which calls the 'Elevate()' function.

Here's a video of the test (11 seconds long, embedding videos doesn't seem to work from Flickr):

https://www.flickr.com/photos/188456966@N07/51176059769/in/dateposted-public/

Has anyone else seen this?  Anyone know any work-arounds?

Edited May 13, 2021 by Glaysche
Update video to show the problem more clearly.

[Mr Jos]

Hey, I know what it is, it's called gravity :D

When 'falling' down the motors can move fast and without much torque needed.

When moving up it needs a lot of torque to be able to lift up the arm. This will even go slower if you extend the upper arm more outwards, and go faster when the upper arm is moved closer to the center.

 

The motors will try to reach the desired speed, but if the load is to heavy it will not reach that speed. This is the reason you can not make time based movements with these robots, and you can not say lower arm joint has to go same amount of degrees as upper arm joint, and just both send them max speed and expect them to arrive at the same time, as the 'stressed' lower arm will always be later, and the arm will not stay flat.

These robots are fun, but they require a lot of programming if you want to do it good, you need to build in some control systems to check angles etc.

Edited May 13, 2021 by Mr Jos

[Mr Jos]

I did just look at your other video's on flickr and saw it could move faster up before without this new code, I think maybe the "acceleration = smooth' might be the problem. Try to set it on most aggresive acceleration for elevate_move. Now it starts with low torque trying to smoothly ramp up, but the low torque is not enough to quickly move the arm up. I set all my accelerations to maximum for highest available torque.

[Glaysche]

If I manually use the slider, it goes fast both directions.  This is using the “set speed” rather than “set relative position” block.  Sure gravity does matter but it’s a much smaller difference than I’m seeing here.  A couple of the videos in the photo stream are using set speed and a couple are using set relative position.  I didn’t mark which was which there.

Also, I don’t know if you saw the first video I posted or the one after I updated my post. The second one (11 seconds long) shows the effect more dramatically.

[Glaysche]

Oh yeah, I have tried it at the highest acceleration with the same effect.

[ord]

I'm not too familiar with Scratch but do the motor commands in the 'Elevate_move' function run sequentially, i.e. F motor runs then B motor runs? 

Also, are the relative positions of F and B both zero when the program starts? 

[Glaysche]

The relative positions of both are zero when the program starts.

Not running simultaneously might be the problem.  I’ll run some experiments to see what the behavior is here.

 

What I really want is to run a single move command that goes to both motors.  In Scratch, you can select multiple motors for the same command.  The problem for me is that these motors need to go in opposite directions which I haven’t found a way to express.

[Glaysche]

@ord, you were right.  That is what was happening.  I modified the program to look like:

I send out a message when I want to move and have two separate message receivers, one for each motor.  This requires a global variable to record the desired tilt. This certainly is a bit sloppy.  It would definitely be nicer if I could send one command to two motors directly.

[hollielucas]

21 hours ago, Glaysche said:

Motors 'F' and 'B' are hard coupled together in opposite directions to power the tilt axis on my robot:

This is great stuff, but bear in mind these are toy motors. There is no certainty that any two motors will consume the same power and rotate at the same speed. Simple visual observation has shown me that a motor runs faster in one direction than the other, hard coupling can amplify the inconsistances of both motors. Also, however good a rotary encoder is, the electronics will "move" far faster than the mechanical encoder and motor can.

Lego robots are great fun but, unfortunately, for industrial quality you need engineered components driven by industrial quality programming.

[Glaysche]

1 hour ago, hollielucas said:

This is great stuff, but bear in mind these are toy motors. There is no certainty that any two motors will consume the same power and rotate at the same speed. Simple visual observation has shown me that a motor runs faster in one direction than the other, hard coupling can amplify the inconsistances of both motors. Also, however good a rotary encoder is, the electronics will "move" far faster than the mechanical encoder and motor can.

Lego robots are great fun but, unfortunately, for industrial quality you need engineered components driven by industrial quality programming.

Yes, indeed.  My goal has not been to make a high precision, high performance robot for a private assembly line.  My goal has simply been to push Lego as far as it can go.  Before I started on this project, I didn't understand the limitations of plastic parts.  I didn't understand that long axles act as rotational springs and can cause strange jitters in the output.  I didn't understand just how flexible plastic beams are and how everything needs careful bracing in multiple directions to create a rigid structure.  I didn't understand much about backlash in gears and how to mitigate it.  This project has taught me all those things and more.  Having the limitations inherent in Lego has been a great learning experience.  Oh, and I have already destroyed a good number of Lego parts.  I have improved the design to reduce the stress on those critical parts. If I happen to destroy a motor or two, that would be a bit of a bummer but I'm sure I will learn from it and figure out how not to destroy the next one.

The software half of it is different.  I actually have written software my entire career but at a much lower level than what is offered by Lego Mindstorms.  I would feel much more comfortable writing C and assembly directly on the hardware.  So my challenge to myself here is to do as much as I can with the tools provided by Lego and see what limitations I run in to.  If I'm really lucky, I may be able to make some suggestions that can improve the Lego software roadmap.  Even if not, it's still fun to challenge yourself to build something with constraints you have to work around.