Hey guys,
I’m currently using the BrickPi+ and the C drivers for a project I’m trying to do. However I need almost pinpoint precision, yet I have a hard time achieving this with C.
Could anyone give me any hints as to how I should go about it ?
I should probably note that I consider switching to Python a last resort and that I am aware that such functions have been posted already (but I couldn’t find any in C).
U have to understand the type of motors that Lego use. They r DC motors with encoders to read position. For pin point accuracy you need to use stepper motors like what is used in CNC type machines.
Understand the difference between the 2:
DC motor you apply a voltage and the motor spins continuously with a power output relatively proportional to the voltage input. To get the DC motors to turn at exact speed to stop at exact position u use an encoder to read position then a complex PID control system either increases or decreases or even reverses the voltage to try to ballance the motor at correct speed and stop at exact spot. Generally not super accurate but the more you turn your PID control system to the exact application (speed needed, resistance/load in system) the better it becomes.
Stepper motors have muli poles and when a voltage is applied it moves just 1 step then stops (depending on exact stepper motor used the size of step but usually 1.8 degrees for full step and 0.9 degrees for half stepping) to get the motor to move then next signal needs to be sent to get motor to take next step. So stepper motors can be controlled to exact speed depending upon how fast you send steps and stop at exact position depending upon how many step signals you send.
I agree to Shane’s statement.
Rotary encoder motors like the Lego “Servo” motors can achieve 1° accuracy only randomly by PID control, no secure and guaranteed 1° accuracy at all times, by neither programming language. It’s just a matter how perfectly tuned the PID controller works for that task: So Python would be not better than C/C++ in that respect, because the BP3 PID controller runs locally on the SAMD cpus of either BP3 shield, for either programming language used on the Pi in Linux user space.
Is there a way you can gear-down your motors to increase accuracy?
I have found when using Lego gearing down can make the accuracy worse because then you have gear slop (back lash) and Lego gears r pretty loose.
What I found when using Lego to build your robots you have to try to design things as not to require too much accuracy, i.e when I built my Lego solving robot it had the trouble that it didn’t turn the faces perfect and I tried super hard tpo increase the accuracy of it but in the end what worked was I used a speed cube that can handle not being turned accuracy and not jam 
sorry that should say rubik’s cube solving robot not Lego solving robot
Thanks for all the replies.
I didn’t know about the difference between the type of motors, thanks for clearing that up !
Shane, I’m also doing a rubik’s cube solving robot. I’m using the mindcuber design, I have a speedcube, but I just can’t get it to be consistent. It will fail at least 2 out of 5 moves.
I think I have the option of getting the large servo motor, do you reckon that would fix the issue ?
Among other technics, David Gilday solved this by using thresholdes (correct idiom?) when reversing the rotation, no thresholds when keeping the same direction. At my own Mindcuber version, the cube inside it’s basket has way more slop than just 1° though.
I used large Lego motors but the program was written in Small basic with the EV3basic API that has a ramp up and ramp down function as part of its PID control and this allowed close enough accuracy to be able to turn a high performance speed cube without jamming. I did spend a lot of time playing with all the variables getting it to turn the faces within the tolerances of the cube.
I do plan at a later stage to build a high performance cube solver using servo motors, this is how they set the records.
What if a different encoder was used?
It doesn’t have to do with the encoder. The encoder can read to very high accuracy the problem is to control a DC motor to spin exactly the speed and stop where you what is the trouble. For DC motors you apply power in and get a twisting torque somewhere proportional to the power in. So you have to read the encoders and try to work out how much to up or down or even revers the power in to get the axle to spin and stop how you want.
I see. That’s where a PID loop comes. Makes sense. @George if you are willing to buy a new BrickPi3 and a pivotpi you can hook up servos. So if you don’t need continuous rotation but want high accuracy and don’t mind paying the money, there’s a solution.
I have to disagree with what Shane said.
The current PID controller is fine for +/-2 degrees reliably, i.e. 2x minimum resolution
If theoretically there were external encoder available of, let’s say, 0.1 degrees resolution, then it wouldn’t matter if the PID controller regulated to also 2x minimum resolution, i.e. +/- 0.2 degrees.
But such an external PID controller is not availble FTM, AFAIK.
OTOH, if one could manually adjust the kp, ki, kd parameters in the BP3 firmware for the SAMD cores, then I’m firmly convinced to make even the current encoders work fine fo reliably +/-1 degree by PID-fine-tuning.
BUT AFAIK that is also not feasable FTM.
But after all, as already stated, IMO also +/-2 degrees should match to the OP’s purposes, because already many people also managed to get along with the current Lego encoder resolution capabilities (e.g., David Gilay even for the NXT version of the Mindcuber by simple NXC code, renouncing either accurately working implemented PID controller capabilities).
Regardless of the fine data coming from the encoders, DC motors have super poor control at low speed. As you drop speed the torque drop exponentially. This means that you can’t slow down to slowly and expect to stop at the correct spot. I played with lots of techniqes even after it stopped read the encoders then try to correct it but what would happen is the cube wouldn’t turn until enough force was applied to break the friction then it would jump too far in the opposite direction. The same thing happened when trying to break from movement and stop at right spot, once you slowed too much then the friction grabbed and stopped the face from turning.
The basic problem is this DC motor have virtually no torque at low speed and also have poor control of torque and speed.
Stepper motors are the opposite the have super high torque at low speed (highest torque achieved at stand still) and the faster a stepper turns the lower its torque. Steppers also have exact speed control as long as the resistance isn’t so high as to stall the motor and cause skipping of steps.
Regardless of the fine data coming from the encoders, DC motors have super poor control at low speed. As you drop speed the torque drop exponentially. This means that you can’t slow down to slowly and expect to stop at the correct spot. I played with lots of techniqes even after it stopped read the encoders then try to correct it but what would happen is the cube wouldn’t turn until enough force was applied to break the friction then it would jump too far in the opposite direction. The same thing happened when trying to break from movement and stop at right spot, once you slowed too much then the friction grabbed and stopped the face from turning.
The basic problem is this DC motor have virtually no torque at low speed and also have poor control of torque and speed.
No, again I have to disagree.
Both the torque regulation and the speed regulation and the setpoint targeting are performed by the PID controller, even for low speed. So when monitoring the actual speed (degrees/sec) and the P term and the D term and the I term when the motor gets into stalling because of high payload, then it’s possible to let the PID ontroller increase pwm power in order to re-increase speed and torque (up to 100% pwm by apropriate programming and tuning).
That all simply has to be implemented in the PID controller code and it’s fine-tuning, it is not a matter of the Legp DC motors, and it can be improved by Dexter Ind. when improving the PID controller source code (e.g., by enabling manual kP, kI, kD settings for proprietary fine-tuning in the future)
Ha Ha Ha you miss the point regardless what the software does (PID) the hardware DC motors can’t physically out put the required control and torque at low speed. This is why engineers when designing high precision machines like CNC, moving the printer head in your printer, robotics factory arms, don’t use DC motors they use stepper motors because the physical motor is able to perform the request that the software is asking from it.
It doesn’t matter how good your software is (PID) if the physical real life hardware isn’t capable.
Ha Ha Ha you miss the point regardless what the software does (PID) the hardware DC motors can’t physically out put the required control and torque at low speed. This is why engineers when designing high precision machines like CNC, moving the printer head in your printer, robotics factory arms, don’t use DC motors they use stepper motors because the physical motor is able to perform the request that the software is asking from it.
you are completely wrong: they can, actually they physically have the highest torque at all (about 45Ncm for the “Lego Servo motors”) when stalling almost or completely.
All DC motors have the highest torque when stalling, not when turning very quickly.
stalling because of high load with very high current and driving a motor slowly because you have reduced voltage and current is 2 very different things.
If you have a physical brake on the motor and you where driving the motor against the load of the brake then yes you can get high torque at low speed. But if you are slowing down by reducing power in put then the torque and control will be reduced dramatically
.
stalling because of high load with very high current and driving a motor slowly because you have reduced voltage and current is 2 very different things.
If you have a physical brake on the motor and you where driving the motor against the load of the brake then yes you can get high torque at low speed. But if you are slowing down by reducing power in put then the torque and control will be reduced dramatically
I think you have quite a misconception about torque, DC motors, speed, and PID control.