Hello I have spent hours trying to get BrickPi to work.
my code:
from future import print_function
from future import division
from builtins import input
from BrickPi import *
BrickPiSetup()
BrickPiSetupSensors()
BrickPiUpdateValues()
Yes the motor turns, but it don’t care what the degrees are it won’t work. I put it on 7000 deg and there is no difference from 4000. Then on 10000 it just spins like crazy. There is no difference between 20 and 100. I also copied and pasted the LEGO-Multi-Motor_Encoder_Test.py Totally different results. I would greatly appreciate any help. BrickPi.MotorSpeed[PORT_A] = 200 doesn’t work any more either. It’s as if the BrickPi went bonkers.
My BrickPi similarly under-performs with your code, and with LEGO-Multi-Motor_Encoder_Test.py You might try this variation from alexkniffin
I’m working on a variation of alex’s variation.
Thanks, but It seems that the code is very long, very very long. I think the problem is most likely a bug, work around hacks are just that work around hacks, the root problem must be solved.
I noticed something interesting, I ran the encoder test and turned the motor till it was on degree 0. Then I ran motorRotateDegree(power,deg,port) and it ran correctly, but after that it didn’t. What this means is that the motors move to a specific degree. Basically if I say move 720 degrees it doesn’t move 720 degrees from its current position. It may move only 2 degrees because it is confused because it is already on 720 degrees. I don’t know for sure if this solved it, but I am pretty sure it will. I just need to somehow reset the encoder.
You set the encoder offset to the value of the encoder. The firmware subtracts it from the encoder variable, only it doesn’t work on my BrickPi.
I’ve stared at the firmware but can’t see why it doesn’t work.
Hey guys I solved it! I decided to create my rotate motor function, check it out on github. It is way more efficient than the code in BrickPi.py
Its shared under creative commons sharealike so there should be no issues if you want to merge it into brickpi.py
Thanks for your contribution to BrickPi motor driving.
I see your code runs only 1 motor. The Dexter code runs up to 4.
Your braking code applies an arbitrary power of 10 (or -10) for 2 calls to BrickPiUpdateValues, then returns (without disabling the motor).
The Dexter code brakes by applying full opposite power for a caller specified time.
I tried @alexkniffins variation and it did work. Sorry I looked at it again and it is less complex than I thought. I thought you ran that in addition to the rotateMotor function in BrickPi. It still is more complex than it should be. 239 lines of code to make a motor turn 360 degrees. Really? Also its breaking is less effective then my method. The question is which should we improve? Mine has the potential to be simpler and have all the features, but @alexkniffins is already working.
The alexkniffins code again runs multiple motors, has Proportional Integral Control to keep the motors in synch for long runs, & brakes like the Dexter code.
I’ve taken the alexkniffens code, modified the PIC part, and replaced the braking with “slow down before done”. with learning from past performance as to when to start slowing down (the idea is the algorithm adjusts for the robot’s momentum). It gets to 1% error after a few attempts, but its still a work in progress.
If you just want to move a single motor, just a bit, I’m sure this is all overkill.