I've got a little testing Pi here that I was trying something on, and it's acting totally bizarre
At least, I think it is
It's just a Pi3B connected to an L298N and 2 motors with a PiCam (v1.2)
One motor on each side, each facing the opposite direction, so, fwd means each motor goes the opposite direction, same for back, and left/ right they go the same direction
So when I press the "UP" arrow, they act correctly, and when I press the "LEFT" arrow, they act correctly, but when I press the "DOWN" arrow or the "RIGHT" arrow, only the right motor spins
At first I thought maybe the batteries were dieing, but swapping them out with new ones didn't help, then I thought maybe I messed up the L298N, so I swapped that out. No help
I THINK the program looks correct (it's python)
The curses calls the arrows, the gpio calls the gpio pins, enter stops the action, and Q quits the program, and the rest is the program...
Anybody got any ideas where I screwed this up ?
Or is this a case of a missing shebang ?
# import curses and GPIO
import curses
import RPi.GPIO as GPIO#set GPIO numbering mode and define output pins
GPIO.setmode(GPIO.BOARD)
GPIO.setup(7,GPIO.OUT)
GPIO.setup(11,GPIO.OUT)
GPIO.setup(13,GPIO.OUT)
GPIO.setup(15,GPIO.OUT)# Get the curses window, turn off echoing of keyboard to screen, turn on
# instant (no waiting) key response, and use special values for cursor keys
screen = curses.initscr()
curses.noecho()
curses.cbreak()
screen.keypad(True)try:
while True:
char = screen.getch()
if char == ord('q'):
break
elif char == curses.KEY_UP:
GPIO.output(7,False)
GPIO.output(11,True)
GPIO.output(13,False)
GPIO.output(15,True)
elif char == curses.KEY_DOWN:
GPIO.output(7,True)
GPIO.output(11,False)
GPIO.output(13,True)
GPIO.output(15,False)
elif char == curses.KEY_RIGHT:
GPIO.output(7,True)
GPIO.output(11,False)
GPIO.output(13,False)
GPIO.output(15,True)
elif char == curses.KEY_LEFT:
GPIO.output(7,False)
GPIO.output(11,True)
GPIO.output(13,True)
GPIO.output(15,False)
elif char == 10:
GPIO.output(7,False)
GPIO.output(11,False)
GPIO.output(13,False)
GPIO.output(15,False)finally:
#Close down curses properly, inc turn echo back on!
curses.nocbreak(); screen.keypad(0); curses.echo()
curses.endwin()
GPIO.cleanup()
@spyder, did you get your L298N functioning properly again?
I don't own a L298N, but your title triggered me when I was looking for a solution to my bizarre motor (driver) functioning. Our problems seem different, so I'll make a new post for mine.
In your code, up and down and left and right have there falses/trues reversed as I'd expect (without knowing L298N details) and the number of trues are two in each case. What I do miss is an "except:" in your try-except-"finally". Even if you don't want do anything on an exception it is more clear to have an "except: pass" before the "finally".
did you get your L298N functioning properly again?
No, I didn't. I ended up doing a different project and put that one on a shelf, and it's been sitting there ever since, hoping that somebody would come up with a solution so it could drive itself off the shelf and into the world of usefulness
As to your suggestions. I'm sure they're probably something I should implement, but, in actuality, I have no idea how, but I will be googling like a madman about it later
I'm not a programmer. I'm a hardware guy. I can build anything, but if it needs to be programmed after I build it, chances are all I will have achieved is the creation of a really interesting looking statue
I didn't write that code, I stole it from various websites and stitched it together in the hopes that something positive would happen, and then suddenly, something positive immediately failed to happen, so I built something else really cool looking while it was extremely busy collecting dust, which is an activity I was hoping fervently to interrupt
I didn't write that code, I stole it from various websites and stitched it together in the hopes that something positive would happen, and then suddenly, something positive immediately failed to happen,
Not the way to program! A big part of programming is debugging the code and that means you must clearly understand exactly what each line of code does.
What is the exact wiring? Make a mistake and you may damage the hardware and that can be the bug. I can't see any reference to the enable pins on the L298 so I assume no speed control ?
Noise static blah blah! Noise static blah blah noise blah noise blah noise static blah noise blah noise static blah blah blah noise noise blah noise blah blah noise static blah blah.
What is the exact wiring? Make a mistake and you may damage the hardware and that can be the bug. I can't see any reference to the enable pins on the L298 ?
The amount of caring I typically give to other people's opinions of me carries about as much weight as a deflated helium balloon, so I was going to ignore this entire post, until I saw something that might be potentially useful
Thank you
Sorry if you took the post as a personal slight it wasn't what I was feeling. Maybe a 🙂 instead of a ! would have been better. I have no interest in offending anyone. I was replying because I intended to help you solve the problem. However thank you for responding because without a response I wouldn't have known the effect it had on you and I will try and be more careful in future in how I word something.
@casey
Thank you
No, there's no speed control. The motors are pretty small and don't go very fast anyway.
Unfortunately, or maybe fortunately depending on how you look at it, my hours at work have changed, so I can't get back to this until Sunday
Just a thought, and it may not be a correct one as I'm running on virtually no sleep today, but the L298N is a 5-volt logic device. It will run on 3.3-volt logic as the threshold for a "digital one" is below 3-volts, but it's on the edge. Although I have seen a number of Raspberry Pi designs that use it.
Not sure if you have a scope but it might be worth checking the levels you are getting out of the Raspberry Pi.
Otherwise, I have some (admittedly self-promotional) suggestions:
I did an article and video about the L298N a few years ago, and in them, I showed how to test the L298N without using a microcontroller. You will need a source of 5-volts for the test.
I also did an article and video recently about replacing the L298N with a TB6612FNG, which is 3.3-volt logic compatible.
Basically you need to (A) figure out if the L298N is actually working in the fashion you wired it up and (B) figure out if the Raspberry Pi is sending the motor controller the correct signals.
And finally, one rather obvious question - have you made sure to strap the Enable lines on the L298N so it is indeed enabled? Usually, these are used to control the speed via PWM, but when you don't need a speed control they must be strapped or the device simply won't work.
Just a few random thoughts from someone who is severely sleep-deprived!
?
Bill
"Never trust a computer you can’t throw out a window." — Steve Wozniak
It's been so long since I touched this one, I had to pull it out to look
Positions 1 & 6 are jumpered, labeled ENA and ENB. As far as putting a scope on it, that'll have to wait til Sunday. I just got home, and I have to go back to work tomorrow again. College kids are out of school for a bit, so my work schedule has increased for now, and I've been running on very little sleep this week as it is. On the upside, that's more money for robot parts, on the downside, that's less time to work on the robots
So I connected the Pi to the only scope I have, which is a cheap dso138, and I learned something
I'm not sure exactly what it is that I learned, but, it's data
The pins I'm calling "Right" are 7 and 11. The pins I'm calling "Left" are (were) 13 and 15
The scope is a cheap one, so, the data is sketchy, but relevant. On the Right pins, with the program not running, I got one signal. When I started the program, the signal changed, and changed again when I put it into reverse
On the Left pins, when I started the program, the scope froze, and started again when I shut down the program
This made me wonder if those gpio pins might be damaged somehow, so I switched the pins from 13 and 15 to 33 and 35 (I chose those to make reprogramming it easier, plus the pins were easy to find without removing the lid that holds the L298N board)
Oddly enough, I got the same output from the scope, and it's getting late now, so I shut down the project for the night, which is when I saw a new development...
When I typed in the shutdown command, the Left wheels started spinning backward
Interesting
I don't know what it means, but it's interesting
I believe that the next phase should involve swapping out the Pi itself (I've already swapped out the L298N once). But not right now. I have to go to work in the morning
Hi Spyder,
I have issues with logic LOW going from 3.3v to 5v systems.
If you have a logic level shifter board, you could put that between the pi and the h-bridge. You could also use a npn (2n2222) transistor and resistor to make one for each line needed.
Scott
I didn't even think of that !
It looks like that might be the answer. According to this...
The pi uses 3.3v on the GPIO, but, according to this...
https://lastminuteengineers.com/l298n-dc-stepper-driver-arduino-tutorial/
The L298N uses 5v for signal when not using the PWM, so, that looks like the answer. I'll have to test it, but that looks like the answer !
Thank you !
Figured I should try and duplicate your circuit and code to test. I am new to Python and one annoying quirk is the indentation. A copy paste of your example source code lacks the indentations.
https://forum.dronebotworkshop.com/test/source-code-formating-test/#post-561
When I run your code a get a syntax error for the key word finally:
Are you using Python 2 or Python 3
# import curses and GPIO import curses import RPi.GPIO as GPIO #set GPIO numbering mode and define output pins GPIO.setmode(GPIO.BOARD) GPIO.setup(7,GPIO.OUT) GPIO.setup(11,GPIO.OUT) GPIO.setup(13,GPIO.OUT) GPIO.setup(15,GPIO.OUT) # Get the curses window, turn off echoing of keyboard to screen, turn on # instant (no waiting) key response, and use special values for cursor keys screen = curses.initscr() curses.noecho() curses.cbreak() screen.keypad(True) try: while True: char = screen.getch() if char == ord('q'): break elif char == curses.KEY_UP: GPIO.output(7,False) GPIO.output(11,True) GPIO.output(13,False) GPIO.output(15,True) elif char == curses.KEY_DOWN: GPIO.output(7,True) GPIO.output(11,False) GPIO.output(13,True) GPIO.output(15,False) elif char == curses.KEY_RIGHT: GPIO.output(7,True) GPIO.output(11,False) GPIO.output(13,False) GPIO.output(15,True) elif char == curses.KEY_LEFT: GPIO.output(7,False) GPIO.output(11,True) GPIO.output(13,True) GPIO.output(15,False) elif char == 10: GPIO.output(7,False) GPIO.output(11,False) GPIO.output(13,False) GPIO.output(15,False) finally: #Close down curses properly, inc turn echo back on! curses.nocbreak(); screen.keypad(0); curses.echo() curses.endwin() GPIO.cleanup()
Did you check the physical pin numbers match the GPIO numbers in the code?
Remember the GPIO pin numbers are not the same as the physical location of the pins.
The code below worked ok without any 3.3v issues.
import RPi.GPIO as gpio import time def init(): gpio.setmode(gpio.BCM) gpio.setup(17,gpio.OUT) gpio.setup(22,gpio.OUT) gpio.setup(23,gpio.OUT) gpio.setup(24,gpio.OUT) def forward(tf): init() gpio.output(17,False) gpio.output(22,True) gpio.output(23,False) gpio.output(24,True) time.sleep(tf) gpio.cleanup() def reverse(tf): init() gpio.output(17,True) gpio.output(22,False) gpio.output(23,True) gpio.output(24,False) time.sleep(tf) gpio.cleanup() print ("forward") forward(3) print ("reverse") reverse(3)
@casey
Ok...
That works. Thank you !
The problem is that I don't understand why it works. I was originally using
gpio.setmode(gpio.BOARD)
Along with (board) pins 7, 11, 13, 15. Then I switched pins 13 & 15 for 33 and 35 (sticking to gpio.BOARD) with the same results
Following your suggestion of using gpio.BCM (and changing the pins again) it finally worked
I'm using python2 for this project. Does python2 not work correctly with board vs bcm numbers ?
Was the change from BOARD to BCM the critical change ?
All the pins I used (both your numbers and mine) were labeled "gpio" on the chart, so, even tho it works now, I'm still confused as to why