Hi
I’m having trouble getting the motors trimmed. It looks like one motor is significantly slower that the other. The basic test is to set the trim value in range(-35,36,10), clear the encoders, run the motors for 2 sec, stop the motors, wait 0.5 sec then read the encoders.
When the left hand motor is plugged into the left hand set of pins (ie running @speed1), the encoder counts are in the high 80s.
When the right hand motor is plugged into the left hand set of pins (ie running @speed1), the encoder counts are only in the 60s
Using fw_ver_15 the results are about the same except that the GPG voltage is being reported as ~3.3 V
Hey,
Can you try out how the test works with firmware version 13 and would it be possible to power both the motors directly from a 6-9V source and check the encoder counts with that.
Hi Karan,
The results in the attached file were from ver 13. My hardware skills are very minimal
How/where would I attach the 2nd P/S so that the motors were still controlled via firmware?
Steve
The RH motor runs about 15% slower that the LH motor when powered directly @9v. But if I go back to the gopigo and I set the trim value +28% (which is where speed2_trim starts getting clipped to its max of 255) and start running, I get maybe a minute where the motors are reasonably “in trim” but then the LH motor starts speeding up and the RH motor slows down and for the next ten minutes, the LH motor is running ~15% faster than the RH motor which is running @+28% trim (see attached).
I really would like to have the gopigo be able to run in a reasonably straight line
Results attached.
Notes: the motor “stop” and “fwd/bwd” commands were sometimes “dropped” in both ver 1.3 and 1.6. Ditto for the LED on/off commands. Pretty sure this is a combination of the buffer overrun vulnerability in the firmware “void receiveData(int byteCount)” routine and the LED logic in gopigo.py where it calls pinMode and digitalWrite back to back.
if l_id==LED_L or l_id==LED_R:
if l_id==LED_L:
pinMode(l_led,"OUTPUT") <--- pinMode and digitalWrite don't have delays
digitalWrite(l_led,0)
elif l_id==LED_R:
pinMode(r_led,"OUTPUT")
digitalWrite(r_led,0)
return 1
anyway - when the motors did run, the LH motor had more encoder counts.
Suggestion for the LED commands:
In the firmware: use the led_light() function e.g.
… #define led_cmd 108 // Turn On/Off the selected LED #define led_cmd2 109 // Turn both LEDs on/off
…
case led_cmd:
//Turn the selected LED on/off
//cmd[1]: led_pin(0-right,1-left LED)
//cmd[2]: state (0,1)
led_light(cmd[1],cmd[2]);
cmd[0]=0;
break;
case led_cmd2:
//Turn both LEDs on/off
//cmd[1]: bit 0: state for right LED -- bit 1: state for left LED
//state: 0:LED off 1:LED on
led_light(0,cmd[1]&1); // right LED
led_light(1,cmd[1]&2); // left LED
cmd[0]=0;
break;
Hey shansen,
Thanks a lot for sending the logs. Just wanted to let you know that we are working to resolve the problems and will get back to you ASAP with a solution.