Stepper Motors and R/C Transmitter

[HarveyH42]

I've got several R/C transmitters, and was wondering if its possible to use one to control the forward/Reverse/stop of two stepper motors. The recievers all seem to be for servo motors. I don't need position information, just the direction or centered. Yes, it would be so much simpler to just use servos, but I have lots of steppers, seldom come up with something to use them with, and this would be perfect. The transmitter for my truck uses PPM. The Blade CP Helicopter is digital, recievers are expensive.

From what I can figure, PPM, timing is everything. Going to use an AVR chip, so not a huge big deal. I've seen a few code examples, but in 'C', and only a single channel. I need two analog and one digital (push button). I can deal with assembly, but not much 'C', although it looks like timing stuff is made real simple in 'C', maybe I should learn...

Anyway, if anybody knows a link to something useful for this, please post.

This is for a pan/tilt project. I've got a good idea on how to do the tilt, an oval-shaped cam and a cabnet hinge. Won't even need limit switches. If I have trouble finding making the cam, think a piece of flat stock with two bolts sticking out might be just as good (easier to adjust too).

The panning mech isn't coming so clearly, been thinking about a rubber tire off a toy car and some 4" PVC pipe, but not sure how to support it.

 

[Sceadwian]

The nice thing about PPM RC transmitters is you only have to have one channel. The entire signal is sent as a single bit stream, accessable from at least one pin on the decodeing IC in the receiver. It varries from transmitter to transmitter but the frameing pulse is always longer than the maximum pulse length for any given channel. Probably on the order of 4-6ms's After that frameing pulse you'll get each channel one by one until the next frameing pulse. That's about it. If you can tap the entire PPM signal before it goes to the decoder you can actually send serial data directly from the transmitter to the receiver, asuming you do a similiar modification to the transmitter. The modification to the transmitter would technically be illegal.

Runing steppers would require first of all that your AVR could run them. After that you either decode your custom serial bit stream and run the steppers from that information or just use the AVR to decode the pulse width of each channel and set markers for forward/off/reverse and break.

 

[HarveyH42]

After the frame pulse, what seperates the channels in the following bit stream? I'll need to decode the transmitter, instead of modifying it. So on the AVR I'd start the timer/counter to match the frame pulse, the shift the following pulses into byte(s) until I get the channels I'm using or the next frame pulse. Not positive, but the servo channels would be some kind of sync and a pulse width. Guess what I need to do is hook up the scope to the reciever, and see what it looks like.

 

[Nigel Goodwin]

As suggested, it's trivial to do, all you need to do is read a pulse that varies between 0.5mS and 1.5mS. As you want to do multiple channels, you simply use multiple connections from the receiver - each servo output has only one pulse on it, repeated every 20mS.

There are LOT'S of PIC examples on the net, I presume there are plenty of AVR ones as well?.

It's important to connect the servo outputs in the correct order, as they are sequential - so you need to read them in the correct sequence, or it drastically slows response time down.

 

[HarveyH42]

I guess the thing I'm trying to translate, is the transmitter has 6 channels, 4 analog, being 4 pots, and the 2 digital are simple push buttons. The servo is moved to a position the matches the pot position. So, in the PPM pulse train, the duration of the pulse, is related to the pot's position. I need to figure how get a +/- relative to the pot's center position, or no change (hold position).

This is kind kind of weird, controlling a digital device, with an analog signal. Not a normal application, but could turn out to be very useful for other things later on. I'll keep looking, I can't be the first with this idea. Stepper motors are cheap and common.

 

[Nigel Goodwin]

Not really, it's more a digital signal (5V logic level - and can feed directly to a PIC or AVR), certainly in modern R/C gear it will be generated digitally.

I've already told you what to do, measure the width of the pulse - it's from 0.5mS to 1.5mS. with 1mS being the central position.

As I've also said, it's a VERY normal application, with many such projects on the net.

 

[evandude]

Nigel, you seem to be talking about measuring the actual servo pulses which the receiver outputs on each of the servo channels. As you say, this is a rather easy thing to do, you just time the pulse widths to get servo position.

Harvey is talking about reading the PPM signal, which would be an internal encoded signal containing all the same info, just in a PPM format - ie, the actual data that is coming over the radio link, and is then decoded/reencoded to the servo pulses on each channel. This format does not really sound extremely complex to interpret with a microcontroller either (you're just timing the delay between each of a number of fixed-width pulses, instead of timing the width of a bunch of fixed-delay pulses), and would mean you'd only have to monitor one signal, instead of multiple signals (one for each servo channel) but would require hacking into the reciever and finding this signal among the traces.

I haven't looked too deeply at the real details of the PPM scheme, but I believe that essentially you just time the duration between each of the pulses in the string, and each of the inter-pulse delays corresponds to one of the channel positions. When the sticks are centered, there will be a certain delay. If the delay for a given channel is higher or lower than its 'centered' value, you know which way to move. (probably better use a threshold so the stick doesn't have to be PRECISELY centered to get the motors to stop) In addition, because the time delays represent positions, it shouldn't be hard to run your servo motors at a speed proportional to how far the stick was moved, giving you better control, if you wanted.

This is kind kind of weird, controlling a digital device, with an analog signal. Not a normal application, but could turn out to be very useful for other things later on.

Yet, if you stop and think about it, what's inside the servo is a digital circuit controlling the motor, using a the voltage of a potentiometer attached to the servo output shaft as feedback. so really, it's an analog input controlling an analog output, with a digital interface in between just because it's suitable for radio transmission.

 

[Nigel Goodwin]

Nigel, you seem to be talking about measuring the actual servo pulses which the receiver outputs on each of the servo channels. As you say, this is a rather easy thing to do, you just time the pulse widths to get servo position.

Harvey is talking about reading the PPM signal, which would be an internal encoded signal containing all the same info, just in a PPM format - ie, the actual data that is coming over the radio link, and is then decoded/reencoded to the servo pulses on each channel. This format does not really sound extremely complex to interpret with a microcontroller either, and would mean you'd only have to monitor one signal, instead of multiple signals (one for each servo channel) but would require hacking into the reciever and finding this signal among the traces.

Right, sorry, my mistake!.

 

[HarveyH42]

Okay, I think I've got it. The frame pulse is longer than all the channel pulses combined, and marks the start of the train. A 1 ms pulse denotes the pot's center position or no change in my case. A pulse less than 1 ms means a change in one direction, greater is the other direction. There will be 6 pulses in the train. This is looking easier all the time. the timer/counter on the MCU will measure the length of the pulses, just need to find which pulse goes with which function on the transmitter, and a few numbers to compare the count with.

 

[Nigel Goodwin]

Okay, I think I've got it. The frame pulse is longer than all the channel pulses combined, and marks the start of the train. A 1 ms pulse denotes the pot's center position or no change in my case. A pulse less than 1 ms means a change in one direction, greater is the other direction. There will be 6 pulses in the train. This is looking easier all the time. the timer/counter on the MCU will measure the length of the pulses, just need to find which pulse goes with which function on the transmitter, and a few numbers to compare the count with.

Yes, the PPM format is the OLD format I was talking about (I've been googling and reading) - but why aren't you just using the servo outputs from the receiver?. It's easier (although only slightly) than reading the entire pulse train. Incidently, the info I've been reading gives the starting pulse as varying between 6.5mS and 16.5mS, depending on the width of the rest of the pulses.

 

[evandude]

Alright, I see what you're going with. I was thinking of PPM in terms of the non-RC reference material i was looking at, where it was described fixed-width pulses with varying delays between them. Looking at the graphic on this site:
http://www.mftech.de/ppm_en.htm
It's consecutive pulses with varying widths, with fixed delays between them. But it didn't take long to recognize that it's just semantics, as they're both exactly the same thing except inverted
And, incidentally, I think that image also tells everything you need to know about how to interface with the PPM signal - though I would use an oscilloscope to find the real timings involved. Servo pulses are often specified as being something like 1-2mS from one side to the other, however in practice I found that I had to do more like 0.6-2.4 mS to get the servos I had to rotate to both extents.

 

[Nigel Goodwin]

Servo pulses are often specified as being something like 1-2mS from one side to the other, however in practice I found that I had to do more like 0.6-2.4 mS to get the servos I had to rotate to both extents.

That's because you are wanting them to turn further than they are intended to!

 

[HarveyH42]

So the starting pulse isn't the same each time, but always longer than the sum of the channels?

I thought that going to the PPM source would be the best choice, single input on the MCU. Haven't any concrete plans, this just seemed like the simplest/cheapest route. Only need to buy a reciever compatible with the transmitter (common). I could have just ran 6-wire telephone cable, but that would put limits on placement, most likely trip over it. Could have gone with RF modules, but I'd have to buy a set, and come up with how the information is sent/recieved.

This doesn't seem so bad. Things should get back to normal at work next week (holidays...).

Oh, if you do anymore searching on this (curiosity), and see some good rich site, post a link. Think I got a good direction on this, but the more I learn, the better I'll be prepared.

 

[evandude]

That's because you are wanting them to turn further than they are intended to!

Fair enough, but I guess I never actually looked at how many degrees they're supposed to turn in normal use. I always assumed 180 degrees, and if memory serves 1-2ms was only giving me more like a little over 90 degrees. So I always tweaked my timings until I got it to grind the gears at both ends, and then backed them off slightly from there

So the starting pulse isn't the same each time, but always longer than the sum of the channels?

if you look at the image in the link I posted, you'll see that the starting pulse is timed such that the sum of the entire packet is 22.5ms long, so the data packet repeats always at that interval. The starting pulse should always be longer than any one of the servo pulses, so you can always detect the starting pulse by watching for any pulse that is longer than 2ms (or whatever the actual maximum is)

 

[Nigel Goodwin]

Fair enough, but I guess I never actually looked at how many degrees they're supposed to turn in normal use. I always assumed 180 degrees, and if memory serves 1-2ms was only giving me more like a little over 90 degrees. So I always tweaked my timings until I got it to grind the gears at both ends, and then backed them off slightly from there

Nasty, nasty!.

The intended swing is 90 degrees!

 

[evandude]

Nasty, nasty!.

The intended swing is 90 degrees!

I like to live dangerously
The way I see it, I pay $8 or $10 for a servo that can do 90 degrees and I'm getting about twice that much out of it, so I'm REALLY getting my moneys' worth
At least I can always tone it back down if I want to use it in an application where I only need 90 degrees of rotation, and would rather maximize the resolution I get out of my timing routines.

 

[HarveyH42]

The frame pulse is longer than the longest pulse used by any channel. pot centered will be 1 ms, difference indicates direction.

evandude, I'm using the servo information to drive stepper motors, only need three states, forward/off/reverse.

 

[Nigel Goodwin]

evandude, I'm using the servo information to drive stepper motors, only need three states, forward/off/reverse.

Like I said, it's trivial to do - measure the width of the relevent pulse - then do a couple of simple tests, if it's below 0.9mS then it's forward, if it's above 1.1mS it's reverse, anything else it's stop. Obviously you can make those the other way round if you like, and adjust the deadband to what you want.

 

[evandude]

Nigel, I've seen you say it several times here, but the center position of a servo corresponds to 1.5ms, not 1ms (1-2ms, not 0.5-1.5ms for the normal range)
You could probably still get the desired 90 degrees of rotation out of 0.5-1.5ms on some servos, however on most of them, 0.5ms would be grinding the gears

 

[Nigel Goodwin]

Nigel, I've seen you say it several times here, but the center position of a servo corresponds to 1.5ms, not 1ms (1-2ms, not 0.5-1.5ms for the normal range)
You could probably still get the desired 90 degrees of rotation out of 0.5-1.5ms on some servos, however on most of them, 0.5ms would be grinding the gears

Sorry, long time since I've done it!