Issue getting trim to work

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

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 :frowning:
How/where would I attach the 2nd P/S so that the motors were still controlled via firmware?

Hi Karan,
motors attached to 9 V AC/DC adapter
RH motor seems a little slower

I swapped the +/- for RH motor (so the motors are now both going in the same direction)
The difference seems bigger now

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 :frowning:

Can you try out this example: . Also try burning the v16 firmware here: using this sudo avrdude -c gpio -p m328p -U flash:w:fw_ver_16.cpp.hex and see if that helps.


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 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
	elif l_id==LED_R:
	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)
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

and in the code: use something like

Turn selected LED on/off

//cmd[1]: led_pin(0-right,1-left LED)

//cmd[2]: state (0,1)

def one_led_cmd(l_id,state):

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

def two_led_cmd(val):

thought I had attached both files - attaching ver 13 again

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.