|
Hi, I'm trying to do electronics and have no idea what I'm doing. So my state right now is I have a raspberry pi zero, the pi-blaster thing to control GPIO pins, and a couple of servos. I managed to get one of the servos to whirr one time, but now I can only persuade it to twitch in an annoying fashion where I'm not sure if it's even heading for the angle I'm trying to set it to, or just twitching in place. I was doing the thing that seems to be half and half "this is fine" or "don't do this everything will break"; powering the servo straight off the 5v pin. Maybe that's my problem, maybe the servo sucks, maybe both. It's definitely using the expected GPIO pin, because it stops twitching if I set that output to steady off or steady on. At this point I'm thinking I probably didn't really want to be using servo motors in the first place, they seem finicky and I now gather quite sensitive (a lot of people saying they'll jitter if your signal isn't perfect, and you won't get a perfect signal out of a pi because interrupts etc. - I'm running a low-end pi with also a camera at the same time so I expect my signal quality is not going to be the best). For my use-case I don't really need "point this way" I just need e.g. "turn left this much" which seems like a better fit for a plain old motor with "high torque low speed" gearing, where if the signal update is delayed by a millisecond or two it just turns slightly more than you wanted and that's fine. (I realize it sounds actually like a job for a stepper motor but I think that leans towards the "annoying signal" problems again, and also costs more - I'm fine with software-timing-based imprecision here.) But then it looks like I probably need some extra hardware in the middle because a motor is just "you got this voltage and amps and now you spin" two-wire input, and there's no direct control over that sort of thing from a pi. So I think I'm looking at a TB6612 as a controller for two motors, and maybe these motors, but then I'm lost when it comes to this: "Just make sure they're good for 1.2 Amp or less of current, since that's the limit of this chip"; what controls the amps going to a motor in this situation, and how do you know what amps a motor is "good for"? Is it feasible to power such motors from the pi's 5v pins (perhaps with a capacitor on there to reduce brownouts) or do I have to introduce another power supply brick here? Is there some sort of thing people typically use for this purpose, like something with a USB-out to power a pi *and* some basic "act like a set of batteries" wires? All the example projects I see using motors put actual bundles of batteries into their things, which I'd really rather not. Also, is there a simpler control method for this task, given I don't really need speed controls? I think maybe an L293D can do it (and also has PWM speed controls!) but maybe I'd just be making my life more difficult as that thing seems like it maybe needs me to understand the electronics more. Or maybe it's literally the same thing just with bare spike-things instead of pins that aren't even soldered on anyway? (The totality of the project is a remote-controlled remote-aimed water-pistol turret, essentially.)
|
#
¿
Oct 14, 2023 22:52
|
|
|
|
| # ¿ May 5, 2024 11:54 |
|
|
Rexxed posted:Anyway for your first step I'd get to the point where the Pi is controlling your servo. That will be the main thing your program needs to be able to do to make the rest work. You can set that up with just the Pi and one servo to start but you may need an separate power supply for the servo (and tie the grounds together if you do it this way). That's just to get started, though, you can't do everything at once. I did some multimeter tests on the pins to ensure that they have the expected voltage, and the pi doesn't die when the servo starts doing stuff, which I assume means the servo isn't draining so much power that it's causing a problem, but it's also not working. My multimeter doesn't have frequency analysis capabilities so I can't tell if the signal timing is right, but I *can* tell from the command-line (raspi gpio get 14) that it is on/off proportional to the expected amount. I guess I do have three servos so I could try connecting different ones to determine whether it's the pi or the servo that's failing to do what I want. One thing that's maybe making it difficult is that the servos are some generic brand sg90 with no datasheet - I don't know if all sg90 have the same PWM frequency etc. The datasheets I found both say 20ms PWM period (50Hz), 1-2ms duty cycle. I notice pi-blaster seems to have a 10ms PWM period (100Hz), but I don't know if that means it's expected to be straight up incompatible, or if I should be halving the 'on' fraction of the duty cycle, or it's okay using the same fraction, or what? (It is possible to change the period but I assumed from the fact that doing so requires rebuilding the whole library that it's not normal to do so - maybe that assumption is wrong.)
|
|
#
¿
Oct 15, 2023 05:14
|
|
|
Perhaps someone can answer the question in this simple form - if you have a servo and the datasheet suggests it expects a signal like the top graph and you give it a signal like the bottom graph, what would you expect to happen?
|
|
#
¿
Oct 15, 2023 23:50
|
|
|
Foxfire_ posted:
|
|
#
¿
Oct 16, 2023 00:15
|
|
it will depend on how they implemented the thing, may be inconsistent part-to-part, and probably nobody has spent much time thinking about what exactly happens.
|
Cojawfee posted:Are you unable to produce the required signal? Servos are usually controlled by an IC reading the PWM you are sending it and it might not be able to read such a narrow pulse.
|
|
#
¿
Oct 16, 2023 00:33
|
|
|
csammis posted:source: currently working on a project with a dozen cheapass sg90 servos which don’t do poo poo if driven out of spec and barely do poo poo when driven in spec
|
|
#
¿
Oct 16, 2023 00:40
|
|
|
Update on my servos from a while back - either I wrecked the servo that was twitching, or it was bad in the first place, because after changing the signal frequency it still only twitched, but switching the same wiring and signal over to the *other* supposed-to-be-identical cheap servo has that one responding as expected now.
|
|
#
¿
Oct 24, 2023 04:14
|
|
|
ryanrs posted:Tonight at 2 AM, the angry alarm went off.
|
|
#
¿
Jan 13, 2024 14:55
|
|
|
ryanrs posted:I'm out on the street directing the cops.
|
|
#
¿
Jan 14, 2024 15:03
|
|
|
As a not-electronics person, the problem of securing a USB port against overload *and* screwdriver-jamming seems eminently solvable if you have no cost constraints. Simply arrange: Protected USB port : wifi adapter or similar radio signal : physical barrier : USB-data-to-wifi-or-radio transformer : new USB port to which the hostile party has access Transform the data from the unprotected USB port into some over-the-air format at that end, and back to USB data at your protected port, and there's no possibility of overloading it. Boom.
|
|
#
¿
Feb 10, 2024 14:11
|
|
|
I would think some supercapacitors would be good for "smoothing" battery use in long-term things with weird behaviors, like if you have solar panels and a battery inverter thing and you have something connected to it that uses *about* the same amount of power as the panels produce, instead of constantly charging and discharging the battery a little bit you could do that rapid-cycling in a capacitor instead, which would be an improvement for the battery's long-term lifespan? Or is batteries' lifespan being measured in cycles misleading? Or do capacitors also have a limited number of cycles?
|
|
#
¿
Apr 13, 2024 05:33
|
|
|
|
| # ¿ May 5, 2024 11:54 |
|
|
kid sinister posted:Oh man. That gives me a flashback. I bought Microsoft's first gen wireless keyboard and mouse. Either one took 2 AAs. The batteries in the mouse lasted 1 week. The keyboard lasted a month. (NB. this is using the dedicated USB radio receiver, I assume using bluetooth would make it drain a lot faster.)
|
|
#
¿
Apr 14, 2024 17:56
|
|