search

akash-roboticist / open9x

Automatically exported from code.google.com/p/open9x
0 stars 0 forks source link

Reduce the latency between the mixing and PPM output #164

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
The sequence of generating PPM is:

(1) doMix - reading sticks & switching, and mixing them
(2) setupPulses - generating user chosed protocol data structure
(3) output pulses - output what in 2

In Issue 157, we had modified the timing of (1) & (2)
Now, (1) & (2) as close as possible with a safe margin of 1.5ms

It is good! (See attached 1.jpg)

On the other hand, the timing of (2) & (3) is improper.

The original code generates pulsed on the rising edge of REST pulse
(The one with at least 4ms. 10ms in average)

The timing of (2) & (3) should be re-arranged, make it as close as possile. 

Then, the stick response shall be quicker for 10ms.

Original issue reported on code.google.com by myfo...@gmail.com on 30 Nov 2012 at 7:40

Attachments:

GoogleCodeExporter commented 8 years ago 
The expected result...

Original comment by myfo...@gmail.com on 30 Nov 2012 at 7:42

Attachments:

GoogleCodeExporter commented 8 years ago 
PPM code modified, changed its REST pulse to be postfix.

Verified with DSO.

Excellent performance! Saving extra 10ms in average.

<< PPM part >>

The attached patch call DoMix just end before PPM first CH for 1.5ms.

v.s.

Last version (with/without IRQ5) about 12ms.
Older version about 18ms.

2012-11-29 01.20.29.jpg
CH1 = duration & timing of doMix()
CH2 = PPM output (JR format)

2012-11-29 01.17.16.jpg 
CH1 = duration & timing of doMix()
CH2 = duration & timing of setupPulses()

Original comment by myfo...@gmail.com on 30 Nov 2012 at 7:51

Attachments:

GoogleCodeExporter commented 8 years ago 
Fox's patch a little bit modified.

Original comment by bson...@gmail.com on 5 Dec 2012 at 9:48

Attachments:

GoogleCodeExporter commented 8 years ago 
Combined this patch with '3 pass modification' yesterday,
works perfect!!

Original comment by myfo...@gmail.com on 5 Dec 2012 at 12:14

Attachments:

GoogleCodeExporter commented 8 years ago 
Condition of previous chart:

CH1 = 100% CH2
CH2 = 100% CH3
CH3 = 100% CH4
CH4 = AIL

Only loops for 3 times, so CH1 delayed for 1 PPM.

Original comment by myfo...@gmail.com on 5 Dec 2012 at 12:16

GoogleCodeExporter commented 8 years ago 
A note for the issue.

We assumed the 1.5 ms margin is enough for Issue 157, that's incorrect!

We had per-calculated the mixing duration in the issue 157, but forgot the sync 
position will be changed when the CH pulses width changed.

To make the concept of Issue 157 works (no matter if IRQ is used or not), we 
must make sure to sync with the fix position of a PPM pulse. 

Otherwise, we will lost sync with the next PPM even the mixing duration is 
unchanged.

Issue 164 patch is necessary for issue 157.

Original comment by myfo...@gmail.com on 5 Dec 2012 at 12:24

GoogleCodeExporter commented 8 years ago 
I thought about allowing 5 pass. This max is there to avoid infinite loops.

Original comment by bson...@gmail.com on 5 Dec 2012 at 1:16

GoogleCodeExporter commented 8 years ago 
Unless 5 pass causes extreme long mixing duration (i.e. > 10ms).
otherwise, I guess 5 is no problem. 

Within pass 1, every CH is calculated.
...
Within pass 5, only dirty CHs are calculated. Maybe 1 or 2 CH is dirty then.
Re-calculating 1 or 2 CH is very fast.

If not, must be a defect mixing setup.

BTW, for most cases, only 2 pass is enough & the loop ends immediately.

Original comment by myfo...@gmail.com on 5 Dec 2012 at 2:19

GoogleCodeExporter commented 8 years ago 
On the other hand, if the mixing setup is correct, needs 5 pass, and require 
20ms to complete calculation(^_^), I still prefer extreme long latency instead 
of losing sync between channels.

e.g.

If the CH1 = Right FLAP, CH2 = Left FLAP
I would like they are delayed for extra 22.5ms, not one deployed but another 
doesn't. @_@"

Heli CCPM is the same.

Remember, propagation delay will be about 50ms, delay by 1 PPM may > 22.5ms.
It depends on the sync of Tx Module <-> RX <-> Servo 
(Miss 1 train may miss next airplane)

Original comment by myfo...@gmail.com on 5 Dec 2012 at 3:33

GoogleCodeExporter commented 8 years ago 
I think 5-pass will cover all needs and more. It doesn't spend more time than 
with 2-pass when no recusive channels in the mix settings (or < 3)

Original comment by bson...@gmail.com on 5 Dec 2012 at 4:10

GoogleCodeExporter commented 8 years ago 
Absolutely agree!

Original comment by myfo...@gmail.com on 5 Dec 2012 at 4:20

GoogleCodeExporter commented 8 years ago 
Would you answer there? Perhaps with 2 models, one simple and a complex? I 
think gbirkus one is above 50ms difference with er9x ...
http://9xforums.com/forum/viewtopic.php?f=45&t=2196

Original comment by bson...@gmail.com on 6 Dec 2012 at 3:38

GoogleCodeExporter commented 8 years ago 
Buy myself a Logic Analyzer at home. Now I can capture the waves more easily...

I'd spent some time to describe the details as I can.
Save a copy here...

---

After completing issue 157 & 164, Open9x had reduced the average & max latency 
at least 15 ~ 50ms.
Refer the pic above, 

line 1 is the status of a switch
line 2 is the timing of doing the mixing
line 3 is PPM output

bar B is where a PPM frame start
bar C is where we start calculating the mixing depends on your stick & switch 
position
bar A is where the calculation stops
bar T is the trigger point, where we change a switch or etc.
bar D is where the 8th CH stop of previous PPM 

Each channel's recent status is embedded in the PPM hi pulses width.

Let me explain the newest implementation of Open9x.
In the pic above, we must prepare everything to send before point B.
So, we must start calculating from point C and end at point A.

One problem arose here, we cannot expect how long the calculation will take!
We must set the timing according to 2 facts, 1) the last mixing duration 2) a 
safe margin.

Here we have 2.5ms (A-C) according to the last record, and extra 1.5ms safe 
margin to ensure
(hopefully) everything is done before point B
Note: the duration is updated every time. Always use the most recent update 
value.

Then, any changes before point C will be transmitted in the next PPM.
Sure! Changes too early makes no difference.   
The train runs on its schedule, I only guarantee that you will be in time.

This is the most optimized timing we can expected.

---

Below is the history, you may skip them. 

1) Without Issue 164 - The point B is moved to point D

The PPM pulse is formed at point D, so you will expect the Trigger (you moved 
your switch at point T)
will miss next train. You will delay at least 22.5ms

The worst is, B-D is variant. You can find 8.2ms & 11.26ms in sequential 2 
frames.   

2) Without re-calculating the mixing recursively, you will be late more

If the mixing setting is recursive, e.g. virtual channels are used

CH1=100%CH2
CH2=100%CH3
CH3=100%CH4
CH4=ID1
(Assuming you are using ID1 to deploy 4 servos of FLAP)

doMix() resolve 1 CH each time.
To makes all CH1~CH4 updated, you must call doMix() 4 times.

That's 2.5ms * 4 = 10ms   
(In fact, for a complex mixing setting, 6ms * 4 is common)

If we do nothing about it, CH4 may get updated in the NEXT PPM,
then CH3 get updated in the 2nd PPM, and etc.

Your flaps will becomes aileron   

Now, we had solved this problem, let all CHs be updated 1 time and still keep 
the mixing be speedy.
(In fact, the pic above does use the same setup, and only takes 2.5ms)

3) Without Issue 157 patch, the latency is not predictable

The original design of the mixing strategy is .... combining 'Mixing 
Calculation' with 'UI redraw', 
'Telemetry', 'SD', ...

So, I don't know when the mixing is processed (according to the pic above, 
point C could be anywhere)

For a time-consuming operation (e.g. complex UI redraw or SD access), it 
occupied the timing of
mixing calculation.

We fixed it.

At the point C, we ALWAYS reserve time for beginning calculating the mixing.
In the pic above, you will also find that the calculation always be on time, no 
matter how long 
the REST pulse is (please compare the position of 8.2ms, 11.26ms )

By improvement of (1) (2) (3), I suppose the latency is reduced 15~50ms in 
average.

Original comment by myfo...@gmail.com on 6 Dec 2012 at 1:14

Attachments:

GoogleCodeExporter commented 8 years ago

Original comment by bson...@gmail.com on 7 Dec 2012 at 6:25

GoogleCodeExporter commented 8 years ago 
Thanks Fox!

Original comment by bson...@gmail.com on 7 Dec 2012 at 6:26