radiocommand set for airplane model

[jyb]

hi all
i need help
i can't find the solution
i built a radiocommand set using a 40x2 3.3v for the sender and another one for receiver
the problem i encountered is strong jitter on servomotors
the emitter scans four potentiometers using adc commands ,resize the mesurments,and send them via an xbee module to the receiver which
receipt each channel and dispatch the good value to the good servo
it works but there much jitter i can't kill
reading manual2 it seems (it is what i undersand)that the serin command is the cause of the jitter because it have priority over the servo command

the emitter use readadc command and a serout command
whilst the receiver use a serin command with qualifier system and (servo fot init first time) servopos each time data is received

some good idea for a solution?
thanks by advance

 

[eclectic]

@jyb

Please post

The Code
The schematic

Ec

 

[Andres Rodriguez]

What servos are you using?
The comercially available standard servos used on model airplanes are designed for, at least, 4.8V and they operate well at sightly over 6V.
Your Picaxe uses 3.3V, what is the voltage to the servos?
If you are using standard servos, is the Picaxe pulsing the signal to the servo with the same frequency as a standard RC receiver?

 

[jyb]

here is attachments for sender loop program and the other one for receiver loop program

schematics will come soon

View attachment texteemet.bas
View attachment texterecept.bas

 

[jyb]

What servos are you using?
The comercially available standard servos used on model airplanes are designed for, at least, 4.8V and they operate well at sightly over 6V.
Your Picaxe uses 3.3V, what is the voltage to the servos?
If you are using standard servos, is the Picaxe pulsing the signal to the servo with the same frequency as a standard RC receiver?

hello Marmitas
yes i use standart servo and they are powered by a separate battery 4X1.5v
as i don't find anywhere a table which gives for each picaxe command its timing, it is difficult to calculate a 20millisecond timing for the program loop which must receives,read and filters data then write onto the servopos
on the other side, if i well understood what say the manual
the servopos command issue each 20 milliseconds a signal to the servo till his value is changed, so the 20millisecond period is given automaticaly by the picaxe, but each time a serin command is activated,it interrupt the timer, giving jitter to the servos, another possibility to get jitter is (i think) to issue servopos commands with a program loop which runs in less than 20millisecond
i reduced jitter by optimizing the program loop but it is unstable
another solution could be to replace the 40x2 receiver by two 28x2 one for receive data and one for driving servos but it turns more complicated
may be you know another way ?

 

[hippy]

There are a number of issues with the code which could be leading to servo jitter, including the transmitter code. Because of the repeated use of the single scratchpad location zero a subsequent position is not transmitted if it is the same as the channel before rather than not the same as the channel was previously.

Untested, but I'd simplify the transmitter. Not sure how 'Gosub lect_clav' fits in so I left it out.

Equally untested but on the receiver I would use background serial receive ( but without using interrupts ), use a State Machine which simply polls for data received, looks for the $F0 qualifier then reads channel and servo position value.

This will ensure the servo loop is as best it can be and will only be affected when new data arrives at the same point as the servo pulse changes, There will be no jitter due to frame timing or waiting for serial to arrive.

 

[jyb]

yes ,but.......

There are a number of issues with the code which could be leading to servo jitter, including the transmitter code. Because of the repeated use of the single scratchpad location zero a subsequent position is not transmitted if it is the same as the channel before rather than not the same as the channel was previously.

Untested, but I'd simplify the transmitter. Not sure how 'Gosub lect_clav' fits in so I left it out.

Equally untested but on the receiver I would use background serial receive ( but without using interrupts ), use a State Machine which simply polls for data received, looks for the $F0 qualifier then reads channel and servo position value.

This will ensure the servo loop is as best it can be and will only be affected when new data arrives at the same point as the servo pulse changes, There will be no jitter due to frame timing or waiting for serial to arrive.

hello hippy
some explanations about program where b1 is chanel's index,b0 is read value from adc ,b2 compare argument in conjunction with four line on scratchpad which memorize previous sample to compare with actual one for each chanel
the target is when there is no variation on a chanel no transmit is done for him (to gain time)
get b1,b2
put b1,b0
if b0 = b2 then goto jump
the gosub lect_clav is here to scan the keyboard and stop the transmitter if needed
in a previous version i used hserin in place of serin it was a bit better but the reason i leave hserin is that i need 115200bds for a gyro/accelero in which i can't change speed transmitter
i'am going to try your prescriptions
many thanks

 

[jyb]

@jyb

Please post

The Code
The schematic

Ec

there is schematic for receiver
i cant post transmitter schematic: too heavy: 1,2Mo
i am searching solution

 

[hippy]

With two asynchronous serial inputs it would be worth placing an additional PICAXE between the main PICAXE and the XBee module so that PICAXE can buffer up what is received and pass that over to the main PICAXE when it has data.

Otherwise there are going to be all sorts of interactions going on, beyond servo jitter, with the potential of accelerometer data being dropped while waiting on SERIN.

Asynchronous systems are not easy to deal with at the best of times and in this case there are three asynchronous processes going on ( XBee recieve, accelerometer receive, plus servo framing ) which you are trying to pull together. That may appear simple in theory but in practice can be hard. It is not unlike a single person trying to run an office taking on the roles of three or more people, at some time they will be doing something, and not doing something else they should be doing at that time.

The solution is to take on more staff, and in that respect I would probably not undertake this receiver project without committing to initially using four PICAXE. Two to buffer and handle XBee and accelerometer reception, another to be instrcted how the servos should be positioned, with a master PICAXE co-ordinating taking data from the XBee and accelerometer handlers and generating data for the servo controller.

That would be my base prototyping system which I would aim to get working, and then either stick with that or investigate how PICAXE could be merged, which could prove impossible without adverse consequences arising elsewhere.

The PICAXE is a powerful device, it can be used in multiple numbers to achieve some quite complicated things but it is not perfect for all tasks and it can be extremely difficult to do some multiple things with a single device, and the same can often be true of any single core microcontroller. There can be times where there are fundamental conflicts, such as keeping servo pulses going at the correct rate while waiting for serial input, and it's necessary to take some other approach.

In such cases it is a trade-off between using multiple PICAXE which brings increased cost but delivers simpler design, ease of programming, and shorter project time against single PICAXE which has less cost but has far more complicated design, harder programming, difficult obstacles that are harder to work around ( and may sometimes turn out to be impossible to resolve ), and a much longer development time. In short, easier but expensive, or, harder but cheap.

 

[hippy]

Here is code which would place a PICAXE-X2 between the main PICAXE and the XBee module.

Using the same 'tx.bas' as earlier, it receives the data from the XBee, and updates its servo position buffers. When any servo position changes it sets a DATA_READY line and when the main PICAXE sees that, sets the SEND_DATA input, servo position data is passed from the XBee handler to the main PICAXE. It uses a couple of tricks with the 'state' and '@state' variables and variable numbering to make it as efficient as possible.

This has now simplified the main PICAXE's job to just polling if new XBee data is available and asking for it when it is. The main PICAXE can ignore that data for some time if it chooses to. What it is doing is turning 'you must deal with this now' to 'I will deal with it when I want to deal with it'.

The earlier 'rx.bas' can be used as the actual servo driver, the main PICAXE just has to pick up the servo positions from the XBee handler, re-transmit them to the servo handler in the correct format; see 'main.bas' skeleton attached. Obviously there is a lot of scope in optimising the servo handler communications.

As can be seen, although we have three PICAXE, each is doing a very simple job, and it's very easy to integrate the three. The only issue is latency, how long it takes to pass things from one to another. This should however be minimal and likely no worse than any other solution, and that changes 'jitter on servos' to 'non-jitter on servos' with a possibly slightly slower response time. That latency can be optimised and reduced if required.

It should also be fairly easy to have an accelerometer handling PICAXE working in a similar way as the XBee handler and all that is then required is to alter the main program to also read that data, combine XBee and accelerometer data and determine what to send to the servo handler. All that can be done in the main program without having to worry about the timing as timing is under program control, not dictated by external influences.

You will particularly note that none of the PICAXE programs even use interrupts. And in just a short time here is an implementation which should 'just work' with very few predicted problems, though it is all untested.

 

[papaof2]

Using serial output on a PICAXE guarantees servo jitter because of the timing requirements for serial. I suspect that serial in does the same (haven't used it on a chip with a servo). I haven't tried hserin/out wih a servo so don't know whether there is interaction there.

I have at least one PICAXE chip that has servo jitter when only driving the servo.

John