PICAXE-18X with rc receiver and servo

N

nfk

Senior Member
Hi,

Here's a simple bit of code which I'm having trouble with...

Code: 
main:
	pulsin 0,1,w1
	servo 0,w1
	goto main
PROBLEM 1
I am trying to read in the pulse from a radio control receiver, modify it, and then output it again to a servo. The trouble is that I get a rather unstable reading from the PULSIN command. It seems to vary by +/- 10 microseconds (despite getting a very clean and stable pulse from the receiver) and if I add in more code it seems to get worse.

Do I need a faster PICAXE chip? (I am running the PICAXE-18X with the internal resonator).

PROBLEM 2
Another slightly frustrating problem is that the pulse width is not being read accurately anyway. When the receiver channel is centred (and putting out a 150 microsecond pulse) I'm getting readings of about 163. I know I can fix it by adding...

Code: 
        w1 = w1 - 13
...but I don't want to slow down the microprocessor.

Any guidance much appreciated.
 
B

BeanieBots

Moderator
You are updating the servo command too quickly.
Either put a pause in. (experiment to get the best value ~18 to 25 usually OK)
or, use pulsout instead because the pulsin will set the frame rate from your Rx.

main:
pulsin 0,1,w1
servo 0,w1
pause 22
goto main

Or

main:
pulsin 0,1,w1
pulsout 0,w1
goto main
 
N

nfk

Senior Member
BeanieBots, I've tried your version that certainly helps and PULSOUT completely solves the error problem in the pulse width going to the servo - thanks!

When you say that I am updating the servo command too quickly, do you mean that it is being updated before it has had a chance to complete a complete pulse/gap cycle?

My application requires that the pilot is 'in control' all the time (due to the extremely high precision flying these guys are doing) and I don't like the idea of using the PAUSE command. However, if I use the pulse command I guess I'll have to be very efficient with my code because I'll need to make sure that for each pulse from the receiver that the PICAXE chip is ready and waiting to time the pause and not occupied elsewhere in the code. I guess a faster chip would help.

I'll experiment and see how it goes.

Cheers for the help!
 
B

BeanieBots

Moderator
The pulses from the radio arrive every 20mS.
The servo command requires a full 20mS to "do its thing".
Updating at a rate higher than every 20mS means the "current" pulse gets cut short and things can get a bit erratic.
By inserting a pause of less than 20mS will keep things updated at the highest possible rate as long as the pause value plus however long your code takes is less than the full 20mS frame rate.
A pause value of between 20mS and 40mS will mean the PICAXE output happens every 2nd incomming pulse.

For aerobatic flight that could be too long.
I know pilots that complain about the 'standard' 20mS rate.
Personally I've never found it a problem or even noticeable compared with the 0.5S or so that it takes for a servo to move, but then I only fly for fun and my skill level is way short of any competition standard.
 
W

Wrenow

Senior Member
But, as noted earlier, if you are not using the Servo command, just pulsin and pulsout, the pulsin will set the timing. There are no pauses necessary and no noticeable delay will be introduced.

A couple of hints -
1) read all the pulsins you want to read IN ORDER of they way the radio outputs them (generally, the channel number). Otherwise it can take multiple cycles to perform a read.
2) don't get greedy and expect to read a ton of channels in, massage the data, and put a ton of channels out, all on one chip. Remember, the 20ms frame is pretty darn full of pulses at 8 or 9 channels. For safety, I would try and read no more than 3 or 4 channels and output no more than 3 or 4 per chip. MAX. If you want to try and read in all and massage the data, I think you are going to have to go with a dedicated servo controller like the 21 servo controller board.

My current project uses the 08M 3 servo controller Board (the AXE024) to take 3 inputs, do some logic, and output one output. Yes, the servo outs can be used as RX signal ins, resistor and all.

Cheers,

Wreno
 
N

nfk

Senior Member
Thanks!

If I use two pulsin commands, one after the other, to read two adjacent pulses will the PICAXE chip be able to cope? As you say, the pulses are pretty close together.
 
N

nfk

Senior Member
Thanks. yes, I understand that they must be read in the correct order. It just amazes me that the processor is fast enough to be able to do this stuff!

Anyway, that's great news - I should have no problems with the project now.

The real turning point for me was learning about PULSOUT so thanks to all for your help!
 
B

BeanieBots

Moderator
Actually, a PICAXE is not particularly fast:(
However, you get few hundred uS between each pulse and 20mS between each frame. A 'typical' PICAXE instruction takes about 250uS so you should be able to execute the best part of 80 lines of code between frames:)
 
N

nfk

Senior Member
As an update to this question, I have noticed that I get a certain amount of servo 'jitter' when using PULSIN and PULSOUT.

In this simple example...

Code: 
main:		pulsin 0,1,w1
		pulsout 0,w1
		goto main
...I would have expected no problems because, as stated above the PULSIN command sets the pulse rate and indeed I think that works fine. However, using an oscilloscope I can see that the pulse width is varying slightly and this is confirmed with a servo testing gadget I have.

The system is being powered by a battery so it can't be a power supply problem.

Any assistance much appreciated.

Nigel
 
T

toxicmouse

Senior Member
i have a similar problem. instead of the pulsout i use the servo command, but to avoid the problem of too frequent commands i add a bit of code:

'RUDDER ROUTINE
pulsin RC_rudder_in, 1, b1 'check rudder

if b1 = 0 then no_signal 'if there is a loss of signal b0 =0

if b1 = b13 then main1 'if the servo command is the same as last, skip

b13 = b1 'if pulsin is different to the last reading, update b13
servo to_rudder, b1 'repeat the input signal to the output
goto main1


i seem to get a sort of ghosting on my pulsin readings, no idea what causes it, but it seems to go away occasionally, so i just do tests when there is no ghosting. the graph shows the pulsin reading on the vertical axis, and reading number on the hori axis. the RC did not change position for the duration.
 

Attachments

W

Wrenow

Senior Member
I had some issues with the first pulsin (I am reading 3 sequentially) until I went to using the 3 servo controller board with the 08M - then no more big jitter issues. Remember that, even using a battery, there can be interference from the servos - which can be noisy. The 3 servo controller board has some conditioning built in to combat this. Also, you might want to tie the inputs low or high with a resistor to see if that stabilizes it.

By the way, the 4 servo controller will read the RX pulses on the servo output pins with the resistors in place, for what it is worth.

Cheers,

Wreno
 
N

nfk

Senior Member
Thanks for your help - some neat ideas there although I'm still stuck with the fundamental problem of trying to understand how this jitter is creeping into the system. I know that it isn't through servo interference because I have looked at it on a scope and a servo tester and both show a slight changes in the length of the pulse.

I am trying to build a very small gadget which will control servos so i don't want to have to add a 3 or 4 servo controller which is why I am very keen to work out what's going on. I have a suspicion that it might be on the inout side rather than the output because if I 'debug' the value it isn't contant. I have tried tying the input both high and low using various resistor values but this doesn't seem to have any effect.

Any ideas anyone?
 
G

goom

Senior Member
toxicmouse,
I suspect that a "steady" state may actually provide a pulsin value that varies by 1 or 2 counts, in which case your code will produce lots of servo command updates with the inherrant problems mentioned earlier. Much better to use pulsout instead.
You could add a bit of hysteresis so that so that the servo command only updates when the pulse width has changed by, say, more than +/-2.
For a loss of signal, you may be better checking for a pulse which is out of limits e.g. >210 or <90. A true loss of signal may result in the detection of random noise spikes which will be unlikely to be in the 90 to 120 range.
 
T

toxicmouse

Senior Member
thanks for that goom, depending on the application i change the hysteresis, if i need a lot of accuracy then the code i submitted is what i use, the most stable is with a hysteresis of 3 in either direction. in practice the accurate code does not have much servo jitter, even though it would seem it would, the real problem is the parallel readings 70 to 100uS (on the graph 7 to 10 higher) longer than the actual pulse length. unfortunately i have not discovered what causes these parallel readings.

thanks
 
N

nfk

Senior Member
To get accurate pulse width measurement I wonder if I need to use an external crystal to act as the clock source? (I don't know how stable the built-in reference is).
 
W

Wrenow

Senior Member
nfk,

I haven't needed a crystal to read 3 input pulses with an 08m and output one "massaged" pulse, at its standard speed.

Cheers,

Wreno
 
N

nfk

Senior Member
Thanks Wreno but what I meant was that when the signal is read from the input port, despite it coming from a very stable source (I can look at it on an oscilloscope) the value stored by the PICAXE chip varies by one or two units, e.g. if the true signal has a value of 150 then I might get a wavering reading of between 149 and 151. This causes the servos connected to the output side of my system to jitter which isn't that bad EXCEPT that none of the other equipment does this. I am therefore worried that my potential customers might see this as a sign of low quality in my equipment and therefore would really like to avoid it. (Note: The precise nature of the equipment means I don't want to use hysteresis-type coding to get around the problem although in many other systems I'm sure this would be fine).

Cheers,
Nigel
 
W

Wrenow

Senior Member
Just guessing here, but have you tried running at a higher frequency to help eliminate rounding errors? Tied the inputs low to keep them from floating? Not sure if either would solve or alleviate the problem, but might be worth a quick try.

Cheers,

Wreno
 
N

nfk

Senior Member
Hmmmm...I'm not sure if I've tried both together. Good idea - thanks! I'll try it and report back. It will be with a 8MHz resonator (i.e. twice what I was using before).

Nigel
 
N

nfk

Senior Member
Just tested it as you suggested Wrenow (at the higher speed and with varying resistance) with no luck I'm afraid.

A few days ago I even emailed Tech Support but haven't had a reply so perhaps they don't know the answer to this one either.

Can anyone else suggest why this might be happening?
 
W

Wrenow

Senior Member
One other thing to try - put a 330R resistor inline with the signal as well.
Also, are ALL your input pins tied low?

Just speculating here, but those are things I would try.

Cheers,

Wreno
 
N

nfk

Senior Member
As soon soon as I got your suggestion I went upstairs to the lab and tried it out but it's still doing the same thing. The funny thing is that with all those resistors there in the breadboard I then tried holding onto them with my fingers and after a while (maybe five seconds) the jitter stopped! Really weird and of course I can't replicate my fingers in components! I just wish I knew more about this subject!

I just got this from Tech Support:

The pulsin command can be affected in one of two ways:

It can take the chip between 1 and 10us to actually detect the start of the pulse, depending on the position within its assembler code 'standby loop' when the pulse actually starts. This can cause a difference of +/- 1. Overclocking the chip can help reduce the length of time of the standby loop, hence reducing the error.

Background timer interrupt tasks (such as the servo command) can affect the timing. Disable such features during the pulsin command for more accurate results.
__________________
PICAXE Technical Support
Click to expand...
...so maybe I'll have to try 16MHz as well although the jump from 4 to 8 didn't seem to make a difference. It's not an interrupt task as I only have a simple pulsin and pulsout program - just three lines of code.

A friend of mine is an electronic design engineer in the defence industry - I guess I'll have to ask him to take a look at it.

Again, thanks for these suggestions!

Nigel
 
Last edited:
lbenson

lbenson

Senior Member
>can't replicate my fingers in components

If the problem is that the picaxe is resetting, then you can by eliminating the cause. Have you tried putting a 'sertxd ("Resetting",13,10)' before main? If you see the line repeating, then the picaxe is being reset by something. Typical causes are RX not being pulled low when not connected to the programming cable, ripple in the power supply, unused inputs not being pulled low (rarely, I think), EMF. Fingers may more often cause resets, but the opposite is possible.
 
N

nfk

Senior Member
Well, I've just tested this and no, the chip isn't resetting.

I'd really like other people to try this and verify my problems with this. I might start another thread and appeal for other people to see if they get the same problems.
 
Last edited:
You must log in or register to reply here.
Top