Closed dwalton76 closed 8 years ago
If you have an early model PiStorms, there are hardware issues. You should contact mindsensors.com.
PiStorms uses completely different motor drivers from the EV3, so that fact that it works with the EV3 and not on the PiStorms makes the drivers suspect rather than the python library.
I bought it in January...I do not see a rev # printed on it anywhere. Is there a way to tell from ev3dev what rev of PiStorms I have?
Not the hardware revision. If you just bought it in January of this year, it is not that old, I don't think. What color is it? If it's black, it's not an early model. If it's red, it might be.
It is red
It still seems odd to me that I see different behavior from doing an "echo run-to-rel-pos > /sys/class/tacho-motor/motor1/command" vs. using the python library to write that value to the file. If echo works then that suggest the HW is fine. I'm not connecting the dots here on how this could be a HW issue?
I had an older model PiStorms, so I wasn't able to fully test the motor changes from the 10-ev3dev
kernel. So, from that aspect, I would tend to be more suspect of a driver issue. But I agree if manually sending commands works but the python library doesn't, then the python library is suspect.
You should also upgrade the firmware if you have not already:
http://www.mindsensors.com/blog/how-to/how-to-upgrade-pistorms-firmware
From http://www.mindsensors.com/pdfs/PiStorms-Advanced-Development-Guide.pdf
"PiStorms has one LED (located at the corner of Bank A for newer models, and Bank B for older models)". Maybe I am blind but I do not see a LED on either side.
yep am already on the latest firmware.
you have to turn on the LEDs to see them. They are on the top behind the white plastic sandwiched between the red circuit board layers.
Anyone else have a PiStorms that can check to see if they are hitting the same issue?
I did some more digging on this, it is not related to the python library after all. I can get it to break via
echo reset > /sys/class/tacho-motor/motor1/command
echo hold > /sys/class/tacho-motor/motor1/stop_action
echo 400 > /sys/class/tacho-motor/motor1/speed_sp
echo 1080 > /sys/class/tacho-motor/motor1/position_sp
echo run-to-abs-pos > /sys/class/tacho-motor/motor1/command
The trigger is setting the stop_action to hold, this is what causes the motor to shake. 'brake' and 'coast' are both fine.
I will close this ticket (since this is not related to the python library) and open a new one under ev3dev.
I am running "utils/move_motor.py --speed 400 B 1080" and I see the motor rotate 1080 but then the motor continues to move back and forth in very small increments but still continues to rotate slowly. I posted a small clip on youtube, the ratio from the motor to the turntable holding the rubiks cube is 3:1 so for 1080 we should see the cube turntable make one full rotation and stop.
https://www.youtube.com/watch?v=NjeqUuCAIHc
I thought maybe the wait_for_stop(), etc calls in move_motor.py were coming into play so I modified move_motor.py so that it exits right after calling run_to_rel_pos() (that was the state of move_motor.py in the video shown).
I can "echo run-to-rel-pos > /sys/class/tacho-motor/motor1/command" and it works just fine. So this does not appear to be a kernel issue or driver issue but is something in ev3dev-lang-python. That seems odd though because move_motor.py isn't even running when the motor finishes its rotation and starts shaking back and forth.
I am running the latest ev3dev-lang-python develop and the following kernel: robot@raspberrypi2[utils]# uname -a Linux raspberrypi2 4.4.9-11-ev3dev-rpi2 #1 SMP Sun May 8 00:44:12 CDT 2016 armv7l GNU/Linux robot@raspberrypi2[utils]#
This works just fine on a EV3 so I am scratching my head a bit on this one. @rhempel ideas on where to look at next?