Mr 85%. Thoughts on synching.

A "new fashioned" televisor, using an Arduino to drive the motor and display.

Moderators: Steve Anderson, Dave Moll, Andrew Davie

Mr 85%. Thoughts on synching.

Postby Andrew Davie » Sun Apr 09, 2017 3:31 am

This is a problem I have - getting things to 85% and then kind of losing interest. I've been working hard on this project for a while and it's becoming a bit draining. I hope this doesn't end up as another of my 85% complete projects. I'm on the home stretch - what I need to do is get the disc synch going, get the audio working, and build a housing. Maybe a few other things, but those are the biggies.

So, the disc synch has been in my mind for a few days. I think the real benefit with the design is that I absolutely KNOW the signal frequency, and thus can calculate exactly when/where each synch pulse is, in terms of the signal. That's easy peasy. I don't even need synch pulses in the data, but let's just leave them there for now. The other bit of the puzzle is that I have a single hole in the disc which the IR sensors are giving me a pulse from. Meanwhile, the PWM continues at whatever it was last set at, keeping the motor at a reasonably constant speed between updates.

Previously I'd used a PID to synch, and using the time bewteen IR pulses to calculate a disc rotation speed, and then adjust the PWM via the PID. That was kind of hacked, though, because I've used the timer that the system uses to give milliseconds value so milliseconds aren't milliseconds anymore. However, I guess the correct value should be calculatable. The PID solution is elegant; I'm just not quite sure how to tie the IR detected hole with the signal (or calculated) synch pulse. To use a PID I need effectively have a "current value", "desired value", and an adjustable factor for the PID to modify. The adjustable factor is the motor PWM value. But now instead of current and desired value being expressed in RPM (i.e., 750) they are differential times.

To get framing I have to use the time at which the IR pulse is detected, compared to the time at which the signal frame pulse is expected. I'm just thinking this out as I'm writing. So instead of RPM I would be using time values. The PID would be trying to adjust a IR signal time by modifying the adjust factor(which is the motor PWM) to get to the signal synch time. The gotcha is that the signal synch time will be changing over time, so we have a "moving target". I guess on a single call-by-call basis the PID should handle it - I don't know.

So, in theory then... PID is passed...

1. the absolute playback sample # at which the last IR synch pulse was detected.
2. the absolute playback sample # of the correct frame pulse

It calculates the PWM motor value as a result, which is fed to the motor and drives it faster or slower, which then affects the #1 value above for the NEXT time around.
This sounds workable.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1508
Joined: Wed Jan 24, 2007 4:42 pm
Location: Hobart, Tasmania, Australia

Re: Mr 85%. Thoughts on synching.

Postby Andrew Davie » Sun Apr 09, 2017 12:19 pm

So, I have an "absolute position" counter that gives the sample number (x2 or x4 depending on the bytes per sample on the playing track). This increments by one "unit" each time a new sample is played by the interrupt doing the LED pulsing. In other words, it's a time counter. I can use this for the PID. So, all I need to do is store the absolutePosition of the NEXT frame synch pulse (which can be calculated from the current absolutePosition easily enough. Then, when we get an IR pulse I know the current absolutePosition when the pulse happens, and the desired absolutePosition based on that earlier calculation. From those two I can calculate a delta value which will be + or -. The PID's job is to get the delta to zero by modifying the PWM of the motor. By using a delta there's no longer a problem of the "moving" target time that I mentioned in the post above. I'll have a stab at implementing this today.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1508
Joined: Wed Jan 24, 2007 4:42 pm
Location: Hobart, Tasmania, Australia

Re: Mr 85%. Thoughts on synching.

Postby Klaas Robers » Mon Apr 10, 2017 2:57 am

Servo systems are always "Error Driven". So you need to construct an error signal. And because this is not a speed stabilizer, but a position stabilizer, your error signal is the time difference between the sync pulse from the signal, or whatever you will use in place of that, and the IR-pulse coming from the disc. You have to do whatever you can to make that error signal to go to zero.

If you want to have a certain, fixed or variable offset, you can add a positive (or negative) number to the measured timing error.

This error signal is the input for your PID. Don't try to invent the PID yourself.
User avatar
Klaas Robers
Frankenstein was my uncle.
 
Posts: 1431
Joined: Wed Jan 24, 2007 8:42 pm
Location: Valkenswaard, the Netherlands

Re: Mr 85%. Thoughts on synching.

Postby Andrew Davie » Thu Jun 08, 2017 10:47 pm

Klaas Robers wrote:Servo systems are always "Error Driven". So you need to construct an error signal. And because this is not a speed stabilizer, but a position stabilizer, your error signal is the time difference between the sync pulse from the signal, or whatever you will use in place of that, and the IR-pulse coming from the disc. You have to do whatever you can to make that error signal to go to zero.

If you want to have a certain, fixed or variable offset, you can add a positive (or negative) number to the measured timing error.

This error signal is the input for your PID. Don't try to invent the PID yourself.


I have a really nicely functioning and simple PID. But what kills it is when it "starts" when it's not anywhere near the correct speed. It has the intergration component that causes it to spin way over-speed for a while to "catch up" and then it's spinning way too fast, and thus it tries to slow way down until it's "caught down" and then it's way too slow... and it oscillates. I tried to cure this by only kicking in the PID when it was pretty much at exact speed for the first time. That is, full speed on the motor, look at the speed, when it's just a tad too fast THEN turn on the PID. It mostly works, but if the detection of speed is incorrect (can happen if the IR signal glitches, or is detected multiple times) then sometimes it seems the PID is enabled too soon. Sometimes I see a "runaway" disc just going way too fast and seemingly not knowing how to slow.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1508
Joined: Wed Jan 24, 2007 4:42 pm
Location: Hobart, Tasmania, Australia

Re: Mr 85%. Thoughts on synching.

Postby Robonz » Sat Aug 12, 2017 7:31 pm

Hi Andrew

First time post as I only discovered mechanical TV a few days ago and am fascinated by it. I am keen to try building one myself. I have had a bit of experience with PID and motor control. I think you may be simply missing the 4th term which is not well taught. I have always had add a 4 the term which I call i_max

It is basically a maximum allowable value for I. It is used to prevent "integrator wind" up as they call it.

e.g.
calculate i then
If i > i_max
i = i_max
if i > -i_max
I = - i_max

I am enjoying reading about your build so keep on keeping on.
User avatar
Robonz
Evil Genius
 
Posts: 147
Joined: Sat Aug 12, 2017 7:15 pm
Location: New Zealand

Re: Mr 85%. Thoughts on synching.

Postby Andrew Davie » Tue Aug 15, 2017 1:28 am

Robonz wrote:Hi Andrew

First time post as I only discovered mechanical TV a few days ago and am fascinated by it. I am keen to try building one myself. I have had a bit of experience with PID and motor control. I think you may be simply missing the 4th term which is not well taught. I have always had add a 4 the term which I call i_max

It is basically a maximum allowable value for I. It is used to prevent "integrator wind" up as they call it.

e.g.
calculate i then
If i > i_max
i = i_max
if i > -i_max
I = - i_max

I am enjoying reading about your build so keep on keeping on.


Thanks for that. Here's my current PiD code, which is functioning pretty well - provided the disc is not significantly overspeed when it starts up. Given the use-case, that's unlikely/impossible. If it IS significantly overspeed, it takes a while to settle - lots of oscillations. However, if it's about right already, or starting from scratch, spinup and lock are impressively quick...

Code: Select all
byte calculatePID(double error) {

    double now = ( (double) playbackAbsolute ) / singleFrame;
    double timeChange = now - lastTime;
    if (timeChange > 0) {


        errSum += ( error * timeChange );
        double dErr = ( error - lastErr ) / timeChange;
        motorSpeed = kp * error + ki * errSum + kd * dErr;

        if (motorSpeed > 255)
            motorSpeed = 255;
        if (motorSpeed < 0)
            motorSpeed = 0;

        lastErr = error;
        lastTime = now;
    }

    return (byte) ( motorSpeed + 0.5 );
}


Note that I am getting perfect frame and scanline lock (scanline in correct position as well as frame in correct position) every time. There's essentially two parts to the PID/locking. The first part gets to frame synch but scanline incorrect, and then it 'sidetracks' by fooling the PID until the scanline is correct too. You can see this two-part process if you watch the video carefully. The 'sidetrack' always shifts the frame leftwards until it's centered properly. It's basic, but does very well indeed.

I did a video of various startups - from cold, and from already running. You can see the process pretty clearly...

Attachments
VID_20170815_000718c.mp4
(11.42 MiB) Downloaded 259 times
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1508
Joined: Wed Jan 24, 2007 4:42 pm
Location: Hobart, Tasmania, Australia

Re: Mr 85%. Thoughts on synching.

Postby Andrew Davie » Tue Aug 15, 2017 2:15 am

Robonz wrote:First time post as I only discovered mechanical TV a few days ago and am fascinated by it. I am keen to try building one myself.


Depending on what approach you wish to take, you can purchase circuit boards from the club shop, or you can of course design something yourself. Another option - you might like to be an early-adopter of my design and build an Arduino-based televisor. I'd be happy to send you a circuit board and some of the components at cost.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1508
Joined: Wed Jan 24, 2007 4:42 pm
Location: Hobart, Tasmania, Australia

Re: Mr 85%. Thoughts on synching.

Postby Robonz » Tue Aug 15, 2017 10:00 am

Thanks for the offer of boards, I appreciate it. I am debating over the following

1: Go old school for the nostalgia and build it all discrete e.g. the club design
2: Build your design
3: Do a custom bit of firmware myself

Yes, your frame locking is much better than most I have viewed on youtube

Just a few notes from an academic and not a critical perspective.

errSum += ( error * timeChange ); <--- typically this would have some bounds which would limit integrator wind up.
e.g. if errSum > maxErrSum
errSum = maxErrSum
if errSum < -maxErrSum
errSum = -maxErrSum

Also I noticed you are using 8 bits for the motor speed. I would typically start at 10 unless there was a reason not to. It may lock in the vertical frame stability a little better, then again maybe not. I just like to use all the power if its just a matter of typing in two extra lines of code.
User avatar
Robonz
Evil Genius
 
Posts: 147
Joined: Sat Aug 12, 2017 7:15 pm
Location: New Zealand

Re: Mr 85%. Thoughts on synching.

Postby Andrew Davie » Tue Aug 15, 2017 10:06 am

Robonz wrote:errSum += ( error * timeChange ); <--- typically this would have some bounds which would limit integrator wind up.
e.g. if errSum > maxErrSum
errSum = maxErrSum
if errSum < -maxErrSum
errSum = -maxErrSum

Also I noticed you are using 8 bits for the motor speed. I would typically start at 10 unless there was a reason not to. It may lock in the vertical frame stability a little better, then again maybe not. I just like to use all the power if its just a matter of typing in two extra lines of code.



The motor speed is a double, and so there is sufficient precision there before it's converted to a byte for use in the PWM that drives it -- which is limited to 8 bits. So I think it's probably OK as it is. Also, I try to limit calculations to a minimum because this is running in an interrupt that's serviced regularly - and every cycle counts. Thanks for the note on limiting the integration sum - this makes sense and I may have a play with this with regard to my overspeed oscillation (not that it happens, but just as an experiment).
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1508
Joined: Wed Jan 24, 2007 4:42 pm
Location: Hobart, Tasmania, Australia

Re: Mr 85%. Thoughts on synching.

Postby Harry Dalek » Wed Aug 30, 2017 10:29 pm

Its pretty good Andrew (excellent) results ! you pretty much mastered this . :mrgreen:
The electromagnetic spectrum has no theoretical limit at either end. If all the mass/energy in the Universe is considered a 'limit', then that would be the only real theoretical limit to the maximum frequency attainable.
User avatar
Harry Dalek
"Fester! Don't do that to 'Thing'"
 
Posts: 4045
Joined: Fri Sep 26, 2008 4:58 pm
Location: Australia

Re: Mr 85%. Thoughts on synching.

Postby Robonz » Fri Sep 01, 2017 9:09 pm

Andrew wrote: I try to limit calculations to a minimum


Andrew, can I ask you to try one thing? Could you set all the PID to singles instead of doubles and see if there is any difference. I am betting there will not be. This would take the PID processing down to around a quarter of the time.

If I had a working Telvisor I would try it but I haven't even started the electronics yet.

I noticed you are getting really awesome video too. Are you using a camcorder that has a 12hz setting for long exposure video?

Cheers
Keith
User avatar
Robonz
Evil Genius
 
Posts: 147
Joined: Sat Aug 12, 2017 7:15 pm
Location: New Zealand

Re: Mr 85%. Thoughts on synching.

Postby Andrew Davie » Fri Sep 01, 2017 11:30 pm

Robonz wrote:Andrew, can I ask you to try one thing? Could you set all the PID to singles instead of doubles and see if there is any difference. I am betting there will not be. This would take the PID processing down to around a quarter of the time.


I will have a look-see. However, the documentation I have read so far suggests floats and doubles on Arduino both use 4 bytes and implemented in software. I am not sure, however, about the ATMega32U4 and how they are handled on that. Perhaps a better way would be to look into fixed-point artithmetic and using integer arithmetic.

However, the real point is that optimising the PID isn't going to be very beneficial, because it's only running when the infra-red triggers - that is, during normal operations only 12.5Hz rate. You can optimise this till the cows come home and it's going to make little to no difference to anything. What really needs optimising is the interrupt servicing the audio/video (that is: ISR(TIMER3_OVF_vect)) and that appears to already be using integer arithmetic.

Robonz wrote:I noticed you are getting really awesome video too. Are you using a camcorder that has a 12hz setting for long exposure video?


Nope! I do all my recordings with my (cheap!) phone. Redmi Note 3 Pro. I noticed that it seemed to adjust its exposure time based on the brightness of the thing you're looking at, so I pointed a light over my shoulder and when I see banding, I lean one way or the other to reduce or increase the light on the wall behind the televisor (i.e., the wall the phone is pointing towards when recording). I basically manually control the brightness of the incidental light just by subtly leaning one way or the other - and thus I prevent the banding by (indirectly!) controlling the exposure settings during filming. Primitive, but it works :)
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1508
Joined: Wed Jan 24, 2007 4:42 pm
Location: Hobart, Tasmania, Australia

Re: Mr 85%. Thoughts on synching.

Postby Robonz » Sat Sep 02, 2017 1:55 pm

Sorry Andrew, you are perfectly correct. The doubles are singles in Arduino. I guess for clarity the word double should not be used. It must have taken you many hours to write all that code.

Cheers
Keith
User avatar
Robonz
Evil Genius
 
Posts: 147
Joined: Sat Aug 12, 2017 7:15 pm
Location: New Zealand

Re: Mr 85%. Thoughts on synching.

Postby Andrew Davie » Sat Sep 02, 2017 5:30 pm

Robonz wrote:It must have taken you many hours to write all that code.


A few, yes :)
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1508
Joined: Wed Jan 24, 2007 4:42 pm
Location: Hobart, Tasmania, Australia


Return to Andrew Davie's Arduino Televisor

Who is online

Users browsing this forum: No registered users and 1 guest

cron