Inconsistent Movement

Hi all,

I’ve put together a GoPiGo with a Rasbperry Pi B+ and two (possibly related) things I’m struggling with is 1.) inconsistent movement from the robot and 2.) turning left causes the wheel to turn indefinitely. I’ve only tried using the python interface so far.

Issuing commands fwd(), bwd(), right(), motor_fwd(), etc, all cause the robot to move in the expected direction, but for varying and seemingly random durations. Sometimes I get 10 centimeters, sometimes it looks like it stalls and moves only a fraction of a centimeter.

One strange exception is the left() command, which sets the wheel in motion and doesn’t stop at all until I issue a stop() command.

I’ve tried firmware version 1.2 and 1.3. With 1.3 installed, I’ve monitored the enc_read() output and it looks like the encoders are counting correctly (even with the left() command). However, setting a very large target (i.e. enc_tgt(1,1,1000)) doesn’t seem to have any effect when issuing fwd() – the wheels turn for some random amount and stop.

I noticed that when running the enc_val_read.py script that it’ll print out “IOError” when the wheels stop…so maybe that gives a hint?

Any help is appreciated. Thanks!

EDIT: I mispoke earlier, I am using a Raspberry Pi 2 (not a B+).

Hey,
What image are you using with the GoPiGo and what output do you get when you run the firmware version command. Also, are the batteries giving out 9-12V. Let me looks a bit into the encoder targeting too.

-Karan

Hi Karen,

I’m using a standard Raspian distribution:
$ uname -a
Linux raspberrypi 3.18.10-v7+ #774 SMP PREEMPT Wed Mar 25 14:10:30 GMT 2015 armv7l GNU/Linux

I followed the instructions in “Options 3” to set up my SD card:
http://www.dexterindustries.com/GoPiGo/getting-started-with-your-gopigo-raspberry-pi-robot-kit/sdcard/

Here are a few readings from the volt() command, issued a few seconds apart from each other:
>>> volt()
10.13
>>> volt()
10.16
>>> volt()
10.22
>>> volt()
10.13
>>> volt()
10.13

Firmware version is 1.3:
>>> fw_ver()
1.3

Thanks for looking into this.

p.s. I don’t know if this is related, but my motors are connected so the cables are in the order black/white/white/black. The setup guide says they should be connected in alternating order, but when I do that the wheels turn in opposite directions when given the fwd() command.

Hey,
If the wheels turn in the opposite direction when you give forward command, can you just invert one of the wires so that both of them start moving forward and try running the basic test.

-Karan

Yeah, no problem, I already inverted one of the wires and I get movements in the right direction. I was just mentioning that in case it gave you any clues.

My main problem is still 1.) inconsistent movement from the robot and 2.) turning left causes the wheel to turn indefinitely.

Let me know if I can give you any more info. Thanks!

Hey,
Can you run the firmware update in the page: https://github.com/DexterInd/GoPiGo/tree/master/Firmware and go back to firmware v1.2 and see if that helps. We had made some changes to the motor controls in v1.3 so it might help.

-Karan

Hi Karan, I went back to v1.2 and I still see the same behavior.

Do you think the “IOError” I mentioned before (when running v1.3) is related to the overall motor control problem?

I noticed that when running the enc_val_read.py script that it’ll print out “IOError” when the wheels stop…so maybe that gives a hint?

Hey,
I think that the IO error is definitely the result of the motor problem but it is not the cause. Somehow the firmware is crashing on your GoPiGo and I am unable to replicate it on the GoPiGo that I have.

Can you give some more details and try to investigate what is causing the problem. Also, do you have to cycle the power after you give the left() command or does it start working automatically. You are still facing all the problems that you mentioned in the first post, right and are you still using encoder targeting.

-Karan

Hey Karan, I’m facing the same problems (including encoder targeting) that I had with version v1.3.

I haven’t needed to do any power cycling.

BTW, I mispoke before, it is the right() command (which causes the left wheel to turn) that causes the wheel to rotate non-stop until I issue a stop() command. The rot_right(), however, does not cause the wheels to rotate indefinitely (but instead they seem to rotate a random amount).

So it seems if only the left wheel is involved, the motor will spin until I issue a stop() command. If both wheels are involved then they stop on their own after a random amount of time.

I’ll let you know if I notice anything else that could be potentially helpful. Thanks for investigating and for the quick responses!

p.s.
I’m using a Raspberry Pi 2, which I know is a newer model. Are there any extra steps I need to take to get it working with the GoPiGo?

Ok, I think I got it. So basically, when you use left(), the right wheel starts rotating so that the GPG turns towards the left and the same goes for right() too. Now since there is no exact way of determining how much the GoPiGo has actually turned, we have left it for the users to update and modify example so that you can use the functions. So you have to issue another command like fwd() or stop() to stop the GoPiGo from indefinitely turning. One good example of how this works is the browser streaming robot, where you have a joystick which you can use to control the GoPiGo.

Let me know if this makes sense and sorry for the confusion.

-Karan

He Karan,

So if I understand you correctly, you are saying for the commands left() and right() I should in fact expect turning to not stop until I issue another command to stop. Is that right?

If that is so, then that explains one of the issues I was seeing (thanks!) and the one remaining issue is why the encoder targeting does not and commands like fwd() run for inconsistent distances. I believe you suspected the firmware is crashing…any idea what could be causing that?

Thanks!

Hi Karan

I ran the browser streaming robot example you mentioned. I see how it handles the turning and that makes sense, but there is still the issue with the forward/backward commands. When I hold the joystick forward or hold it backward I get very jittery backward or forward motion. The wheels keep stopping randomly.

I’ve attached a video of the what it looks like when I hold the joystick in the forward position.

Hey,
The encoder targeting has become a bit old and might have some bugs. Just let me have a look at it and get back to you in some time.

Do you get the same jittery movement with the motors when you move forward and backward in all the conditions. Were you ever able to get good continuous motion out of it. Is it the same with basic_test_all.py too.

-Karan

Thanks Karan. Yes, I get the same jittery movement in all conditions I’ve tried so far. Same with the basic_test_all.py.

If I had to guess, I’d say this is a hardware issue (but I’m no hardware expert). Based on the video, doesn’t it look like the power to the motors keeps getting interrupted?

Hey Aro,
I still suspect that it might be something on the software. Give me some time to write a firmware test that you can try to test the motors.

-Karan

OK, thanks Karan.

Hi Karan,

I did some more experimenting and it appears one of the motors has a problem. Let’s name the motors as motor A and motor B and say motor B is the bad one.

If I have just motor A plugged in, all commands it is involved in work smoothly, fwd() and bwd() work smoothly with no problem. The left() and right() work fine as well if I plug the motor into the appropriate side.

Now there is motor B, no matter what side I have it plugged into, all commands behave in the jittery manner that I showed in the video a few posts up.

From what I can tell, this is a hardware issue with one of the motors.

Afshin

Here is one more datapoint: I tried connecting the motors directly to a power-source (completely bypassing the any circuit board) and it seem that both motors behave fine in that case.

Here is one more datapoint: I tried connecting the motors directly to a power-source (completely bypassing the any circuit board) and it seem that both motors behave fine in that case.

This sounds more like a software problem then.