positioning issue...

[MichaelVerschaeve]

Has anything been changed to the motor control since last friday morning?
My angles seem to be off by at least 10% today when using run_target...

I'm using Pybricks beta with the rebased firmware for hub to hub communication...
Also using the Icons stuff but not in a tight (or loose) loop...

[laurensvalk]

Can you share an example that reproduces this problem? The smaller your program, the better.

It would be great if you want to try it with the firmware at code.pybricks.com as well to see if there is any difference. Thanks!

[MichaelVerschaeve]

Hi Laurens,

My setup is rather complex so it's difficult to isolate a single program that reproduces the issue.
What I want to do is scan with the color sensor a field where the user can place a 9x9 mosaic of 2x2 tiles, then show that mosaic on a screen where the screen is a 3x3 array of the spike essential led matrices...
I'm using a pantograph linkage to position the sensor where the lower arms of the pantograph are controlled by two motors

Hence I need the following functionallity:

• similtaneously moving motors, did that with starting run_target with Wait=false and then checking in a tight (wait(10)) loop with the done() function...
• the gearing option on one of the motors, one arm is attached to a turntable while the other arm is directly on a motor where the drive axle runs through the center of the turntable. Turntable is 28 tooth, driving gear is 12
• the math (umath) to do the (easy) calculations from grid positions to motor angles...
• since I have two motors, one sensor and 9 led matrices, I need 12 ports, hence two hubs and hub to hub communication, I use the advertising way of communication through the experimental Broadcast class...
• I need to control 9 led-matrices
• I also preferred to use the Icons library to communicate the various steps of the program (straight lines when calibrating the arms of the pantograph, an arrow pointing at the field when the user should place the mosaic, a happy face when he's done scanning...

I had a proof of concept ready last friday (10-03) shortly before noon, positioning the sensor was imprecise, probably because I need to gear down at least the second motor, also the color recognisition was off but was planning to adress that with a custom scannable colors list... any way the general idea was demonstratable and I was quite content with my MOC and pybricks.
This weekend I was entirely occupied with a lego exposition in Belgium (Putte). I tried the program again yesterday evening (13/03) but unfortunately, positioning was now way off, while not having altered anything significant since friday to either the firmware or code... other simple tests like trying to position the arms at 90 degrees fail as well (the resulting angle is more like 70 to 80 degrees.

Also difficult to exclude if it's a mechanical issue or coding, but I can't detect anything stalling...

I'm willing to share code or pictures if you wish, but not publicly on this forum as I feel the MOC is not quite yet ready for sharing with the general public.

[laurensvalk]

Thanks for the additional info. If you see the issue again, and if you are able to reproduce it on something small, feel free to let us know.

Glad to hear you're happy with Pybricks in your MOC :)

[MichaelVerschaeve]

I can report that the issue was indeed mechanical and entirely on my side, A sensor cable apparently got caught between two hinging liftarms. Noticed this while deconstructing the mechanism in order to replace it with one that is much more downgeared to increase accuracy... I apologize for any undue worries I might have caused.

[laurensvalk]

So I eliminated the mechanical issue (I hope), and downgeared (12 bevel gear to a 36 bevel gear). The arms seem to position correctly, however the following code does not seem to work (the loop never exits):

Instead of:

while not upperArm.done() or lowerArm.done():
    wait(100)

Should it be something like this?

while not upperArm.done() or not lowerArm.done():
    wait(100)

Otherwise, if the lower arm completes before the upper arm, it never exits.

[MichaelVerschaeve]

Yes, thank you, noticed it myself a couple of minutes after posting -> I had deleted the message already.
For some reason I thought the OR operator had greater precedence than the NOT...