RaspberryPiFoundation / python-build-hat

Build HAT Python library
MIT License
52 stars 18 forks source link

Motor 88013 accuracy #208

Open RaccoonAhro opened 8 months ago

RaccoonAhro commented 8 months ago

I've been testing out the Build HAT and the large motors for a bit now and comparing them to the large motors of the Lego Mindstorms system and I've found that the Lego Technic motors are always quite a bit off. When using the run_for_degrees(20) command it usually ranges from 16 to 23 degrees. For the run_to_position(), its also up to 5 degrees off in either direction. Since the update the motors also seem to run a lot rougher (though I do believe it is also slightly more accurate). I've tried testing out different pwmparams and ended on 0.67, 0 being the best combination accurarcy-wise. However, compared to the Lego Mindstorms motor, which usually stay within a 4 degree range (eg. running for 19-23 degrees when asked for 20) when using brake() and being dead-on when using hold(), it just seems really inaccurate. I've tried changing up a few things such as using different motors and outputs to ensure that it wasn't just faulty hardware, changing the angle to a higher value (since the motors usually seem to struggle with correctly running for very small degree changes), or trying out different plimit and pwmparam values. And while the pwmparams do seem to have a small positive effect, it seems pretty minor.

Now my question is if anybody else has any ideas on how to increase the accuracy? Or if I'm just missing something? Specs-wise the two motors (95658 and 88013) seem to be pretty similar and should produce comparable results from what I understand. Thanks in advance :)

mutesplash commented 8 months ago

95658 is an EV3 part, so I guess when you're comparing that to 88013 (a LPF2 part) you mean as it runs on BuildHAT. Do you have a LPF2 hub like the newer Mindstorms to try 88013 with in order to compare the motor with itself?

Also, 88013 doesn't have an "encoder" (documents indicate it to be missing the APOS mode) like 95658, so this may be the source of your problem. A somewhat comparable motor to 95658 would be 88017.

Additional comparisons, if you haven't found this website already: https://www.philohome.com/motors/motorcomp.htm

RaccoonAhro commented 8 months ago

Yeah, I should've clarified but essentially I was using the 95658 on the EV3 Brick with ev3dev and the 88013 on the Raspberry Pi. I sadly do not have any of the hubs available so I can't really test the two motors on the same device, unless there's a way to use one of the two connection cable types with the other's port?

I'm just looking for a way to upgrade my Lego Mindstorms build (Brick + 2 Large Motors) to a Raspberry Pi one. For context: The robot should move an arm with a laserpointer so that it systematically goes over a specified area on the wall. So I basically need a rotation around 2 axes to get a 2-dimensional coordinate system on that wall, ideally with a small span of movement inaccuracy to better control the movement and keep it inside the specified area.

I had read that the 88013 doesn't have an encoder but it gave a position back when calling the get_aposition(), even if it was just between -180 and 180 instead of between 0 and 360 like with the ones with an encoder. So I figured that was really the only difference and didn't think much more of it. Do I assume correctly that the 88017 does have an encoder as well and works with the Raspberry Pi? Since it's not listed in the documentation for the motors.

I had found the site as well but to be honest I wasn't quite sure what to make of all the different numbers. Thank you regardless though, I will look into that again. :)

mutesplash commented 8 months ago

I really wish I had 88013 to verify so I'm re-searching about this. "tacho" and/or "rotation sensor" are present in this motor, so they will move via specifying rotations. The only motor I have that is similar is 88008.

88017 (and 45602) do have an "encoder" which I think is the thing that allows the motor to go back to zero position, making it more precise? While it is not as powerful as the EV3 motor you're using, the precision of the series of angular motors is probably the best you will get out of an LPF2 part (I suggested the largest one to match the large EV3 motor). Now, if BuildHAT can translate that into what you want, that's a different story.

The reason why I ask if you have a LPF2 hub is that the newer parts are definitely different and may not be able to do what you're trying to do. Also I know others have had difficultly getting the motors on BuildHAT working to their liking. It would be hard to tell if the problem is that the motor is not capable of your request or the problem is BuildHAT driving it.

The medium (88018 & 45603) and small (45607) angular motors should also be as precise like you are looking for.

Invenisso commented 1 month ago

My two cents for the discussion.

Lego 88013 motor has an encoder - here's the physical proof, someone took it apart: https://bricks.stackexchange.com/questions/16543/what-is-inside-the-lego-powered-up-l-motor

As for accuracy, I think there is still a room for improvement in the firmware/Build Hat library itself. I used Pybricks and got more precise control. For example, after executing the code below in Python Build Hat library, the final position of the shaft was very different from the initial one. The analogous code in Pybricks preserved the shaft position.

from buildhat import Motor
motor = Motor('A')
for x in range(100):
    motor.run_for_degrees(90,50,True)
    motor.run_for_degrees(-90,50,True)
mutesplash commented 1 month ago

I got a hold of 88013 and it has POS and APOS, so it should get driven as accurately as the gears will allow. Unfortunately without the source to verify, @grega , can't really tell what the BuildHAT firmware is doing to compare to Pybricks.

Invenisso commented 5 days ago

I wonder what secrets the firmware has that its code is not public? Maybe some unique algorithms that took years to develop and can't be revealed for free?