papous
Posts: 72
Joined: Fri Jan 05, 2018 5:50 am

CamJam engine erratic behaviour

Fri Jan 05, 2018 7:11 pm

I am trying to assemble and run a CamJam robot and I have run into similar problems with Mark53 (viewtopic.php?t=185814). The motors behave erratically, stopping and restarting at (their) will.
The Raspberry is 3B and the engine batteries are new rechargeable showing a charge of >6v
I have written a python/Flask script that controls the engines via WiFi and I wonder whether it has anything to do with that.
Also, would changing the engines or using a power bank instead of the battery pack improve things? And if so could someone suggest another (better) engine?
Thanks for your help

pcmanbob
Posts: 6248
Joined: Fri May 31, 2013 9:28 pm
Location: Mansfield UK

Re: CamJam engine erratic behaviour

Fri Jan 05, 2018 9:11 pm

If you read the thread you linked, you will see marks problem was caused by a battery pack that was not able to supply the required current, you may have the same problem but cant be sure as we don't have access to your pi.

If your motors are switching on and off on there own I would check all connections as it sounds like you may have a problem with the wiring.
We want information… information… information........................no information no help
The use of crystal balls & mind reading are not supported

papous
Posts: 72
Joined: Fri Jan 05, 2018 5:50 am

Re: CamJam engine erratic behaviour

Sat Jan 06, 2018 7:28 am

Thank you pcmanbob for the quick reply.
I did read Mark1953 post and replies. It seems that it was not faulty wiring and he (nearly) solved the problem using a different power supply and this is why I am asking if a power bank might be a solution.
what is your view on that?

pcmanbob
Posts: 6248
Joined: Fri May 31, 2013 9:28 pm
Location: Mansfield UK

Re: CamJam engine erratic behaviour

Sat Jan 06, 2018 11:02 am

Just because his wiring was not faulty it does not mean yours is not, as for the battery I have no way of knowing as you have not stated what the battery you are using is nor do I know what the required motor current is.
but if your kit uses the small yellow motor/gearbox seen on many robots then your battery needs to be able to supply at least 0.5A per motor without lost of voltage.
We want information… information… information........................no information no help
The use of crystal balls & mind reading are not supported

papous
Posts: 72
Joined: Fri Jan 05, 2018 5:50 am

Re: CamJam engine erratic behaviour

Sun Jan 07, 2018 12:23 pm

Thank you so much for your replies. I checked my wiring and tis OK, so I'll go for a suitable powerbank
Thanks again

papous
Posts: 72
Joined: Fri Jan 05, 2018 5:50 am

Re: CamJam engine erratic behaviour

Thu Jan 11, 2018 7:22 pm

Back on the same subject, I am using a new set of batteries with ~6V. The engine behaviour remains the same.
Here is peculiar thing however:
If I run a module 'motors' code below taken from CamJam EduKit 3) the engines run at the same speed without any problems.
If I call a function from module 'motors' , the engines behave erratically reducing and increasing their speed at will.
So, it not wiring or current that creates the problem. It is the code. Any idea why this is happening?

Code: Select all

# CamJam EduKit 3 - Robotics # Worksheet 4 – Driving and Turning
try:
    import RPi.GPIO as GPIO
except RuntimeError:
    print("Error importing RPi.GPIO!  This is probably because you need superuser privileges.  You can achieve this by using 'sudo' to run your script")

#import RPi.GPIO as GPIO # Import the GPIO Library
import time # Import the Time library

# Set the GPIO modes
GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)

# Set variables for the GPIO motor pins
pinMotorAForwards = 10
pinMotorABackwards = 9
pinMotorBForwards = 8
pinMotorBBackwards = 7

# How many times to turn the pin on and off each second
#The duty cycle is the amount of time a signal is in the high state in one cycle.
#It is expressed in terms of a per cent measure.
#The frequency determines how fast the PWM completes a cycle. When the state of a digital signal toggles rapidly with changing duty cycle values, we feel that we get analogue signals.
Frequency = 200
# How long the pin stays on each cycle, as a percent (here, it's 30%)
DutyCycleA = 0
DutyCycleB = 0
# Setting the duty cycle to 0 means the motors will not turn
Stop = 0

# Set the GPIO Pin mode
GPIO.setup(pinMotorAForwards, GPIO.OUT)
GPIO.setup(pinMotorABackwards, GPIO.OUT)
GPIO.setup(pinMotorBForwards, GPIO.OUT)
GPIO.setup(pinMotorBBackwards, GPIO.OUT)

# Set the GPIO to software PWM at 'Frequency' Hertz
pwmMotorAForwards = GPIO.PWM(pinMotorAForwards, Frequency)
pwmMotorABackwards = GPIO.PWM(pinMotorABackwards, Frequency)
pwmMotorBForwards = GPIO.PWM(pinMotorBForwards, Frequency)
pwmMotorBBackwards = GPIO.PWM(pinMotorBBackwards, Frequency)

# Start the software PWM with a duty cycle of 0 (i.e. not moving)
pwmMotorAForwards.start(Stop)
pwmMotorABackwards.start(Stop)
pwmMotorBForwards.start(Stop)
pwmMotorBBackwards.start(Stop)

# Turn all motors off
def StopMotors():
    pwmMotorAForwards.ChangeDutyCycle(Stop)
    pwmMotorABackwards.ChangeDutyCycle(Stop)
    pwmMotorBForwards.ChangeDutyCycle(Stop)
    pwmMotorBBackwards.ChangeDutyCycle(Stop)

# Turn both motors forwards
def Forwards(DutyCycleA,DutyCycleB):
    pwmMotorAForwards.ChangeDutyCycle(DutyCycleA)
    pwmMotorABackwards.ChangeDutyCycle(Stop)
    pwmMotorBForwards.ChangeDutyCycle(DutyCycleB)
    pwmMotorBBackwards.ChangeDutyCycle(Stop)
    
# Turn both motors backwards
def Backwards(DutyCycleA,DutyCycleB):
    pwmMotorAForwards.ChangeDutyCycle(Stop)
    pwmMotorABackwards.ChangeDutyCycle(DutyCycleA)
    pwmMotorBForwards.ChangeDutyCycle(Stop)
    pwmMotorBBackwards.ChangeDutyCycle(DutyCycleB)    

# Turn left
def Left(DutyCycleA,DutyCycleB):
    pwmMotorAForwards.ChangeDutyCycle(Stop)
    pwmMotorABackwards.ChangeDutyCycle(DutyCycleA)
    pwmMotorBForwards.ChangeDutyCycle(DutyCycleB)
    pwmMotorBBackwards.ChangeDutyCycle(Stop)


# Turn Right
def Right(DutyCycleA,DutyCycleB):
    pwmMotorAForwards.ChangeDutyCycle(DutyCycleA)
    pwmMotorABackwards.ChangeDutyCycle(Stop)
    pwmMotorBForwards.ChangeDutyCycle(Stop)
    pwmMotorBBackwards.ChangeDutyCycle(DutyCycleB)

'''
#Your code to control the robot goes below this line
DutyCycleA = 100
DutyCycleB = 100

Forwards(DutyCycleA,DutyCycleB)


time.sleep(3)

StopMotors()
GPIO.cleanup()
'''

pcmanbob
Posts: 6248
Joined: Fri May 31, 2013 9:28 pm
Location: Mansfield UK

Re: CamJam engine erratic behaviour

Thu Jan 11, 2018 9:47 pm

As I don't have the kit in question there is no way for me to test this and figure out why, seeing as it's a kit that you have purchased may be you should contact the kit manufacturers after all they sold you the kit.
We want information… information… information........................no information no help
The use of crystal balls & mind reading are not supported

GreenPie
Posts: 3
Joined: Tue Jun 11, 2019 6:08 pm

Re: CamJam engine erratic behaviour

Sat Jun 29, 2019 5:26 pm

Hello! I too am having the same exact problem with the motors. They are unreliable. Sometimes they turn, sometimes they don't turn, or they may turn at different speeds. I am also trying to use Flask to create a web app for controlling the motors. Because we are both trying to do the same thing, I think that Flask has to do with the problem. However I'm not sure what that problem is. I am using GPIO Zero to control the motors instead of what you were using and am having the same problem, so it might not be your motor control code that is the problem but rather the Flask code. Hopefully we can solve the problem. :D

pcmanbob
Posts: 6248
Joined: Fri May 31, 2013 9:28 pm
Location: Mansfield UK

Re: CamJam engine erratic behaviour

Sat Jun 29, 2019 6:02 pm

The probable cause is the use of software pwm to control the motor speeds.

As the OS is not real time there can be delays which causes the pwm to vary without being commanded to.
We want information… information… information........................no information no help
The use of crystal balls & mind reading are not supported

Return to “Automation, sensing and robotics”