ATtiny movement detection

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Everyone,

 

I inherited some code from a project where the previous design uses a timer overflow to interrupt the code everyone 1ms.  He then created some software timers to check different functions (temperature sensor, ADC, button presses).  The ADC is used to track a inductive sensor that is used to measure linear motion.  The whole program is a state machine that uses the ADC to determine what state the device is in (position wise) and turns on an output signal and corresponding LED.  There are four of these possible states and generally we're looking mostly for a transition of state 1 to state 3 (skipping over state 2).  The problem I am having is to make sure that state 2 isn't activated while going from 1 to 3 and I am kind of stuck.  At first I was trying to do a time based schema but that woudn't obviously work because the device can move whenever it wants and can be easily early or late to determine the state.  The current approach is to use an average of the ADC value and compare the current average to the previous average and if they're greater then a certain value we can determine that the state has changed and the device may have stopped.  This works much better but still has some blips come through.  We tried to make sure we disabled the timer interrupt when updating states to make sure no new data is injected but nothing.  Any other ides on how to handle this?  We currently take 10 samples and the software interrupt is 11ms for the ADC values.   

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I doubt anyone here is psychic - very difficult to advise without actually seeing the code that makes the state 1, (state 2), state 3 transitions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fair point, Code is like below:

//New value from timer interrupt and storing the ADC value
if(ADC_New){
    //If previous is 0 to start, set it to an ADC value
    if(ADC_Previous){
        //if the current - previous value > threshold, we're still moving
        if(abs(ADC_Val - ADC_Previous) > ADC_Threshold){
            ADC_Count = 0;
            ADC_Sum = 0;
        }
        //If we hit the samples, do the average
        if(ADC_Count > ADC_Samples){
            ADC_Current = ADC_Sum/ADC_Count;
            if(ADC_Current < state2){
                //state 1
            }else if(ADC_Current => state2 && ADC_Current < state3){
                //state 2
            }else if(ADC_Current => state3 && ADC_Current < state4){
                //state 3
            }else{
                //state 4
            }
        }else{
            ADC_Sum += ADC_Val;
            ADC_Count++;
        }
    }else{
        ADC_Previous = ADC_Val;
        ADC_New = FALSE;
    } //ADC_Previous
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this a SW algorithm question, or a hardware / sensor signal question?

 

I.E.  Does the sensor adequately, (accurately, reliably, and quickly), detect that the object is in one of four states?

How fast can an object transition states?

How long does the object remain in State 2, if it goes through that state, as it progresses from State 1 to State 3?

Leading to:  Can a once / 1 mSec sample rate adequately detect an object's pathway, (be it State 1 to State3 directly, or State 1 to State 2 to State 3)?

 

The ADC can certainly obtain readings faster than 1 Sample / 1 mSec.

 

Is your system sampling the object's position fast enough to make the pathway decision that you wish to make?

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The object is able to transition from state 1 to 3 in 200ms so that is the speed we're looking for.  Its a linear motion so you could equat that it would speed ~66ms per state.  The ADC is set at 125khz and free running and the timer interrupt happens every 11ms to get the new value.  We take 10 samples before we door the average and update the state.  Those all are ideal though.  The real world numbers come in more at right around 200ms.  The issue of the intermittent state is either that we're sampling too fast that it is detecting the middle change while moving but it thinks its not moving.  Or the algorithm isn't good enough to determine movement and the right state. 

 

Thanks,

Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cl10Greg wrote:

else if(ADC_Current => state2 && ADC_Current < state3){

what language is this with the =>

(does that mean >= ) ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem I am having is to make sure that state 2 isn't activated while going from 1 to 3 and I am kind of stuck.

 

I might have this totally wrong, but what I envision thus far is:

 

 

So, some more questions:

 

Is the position monotonically increasing, i.e. does it ever "back up"?

 

What defines "State 2"?

If it stops for ___ mSec at State 2 (Position 2), does that mean it entered State 2, and didn't go directly from State 1 to State 3?

What is if just slows down for a bit, but doesn't stop?

 

Is State 2, (Position 2), well defined, or does that mean that the object stopped anywhere along the line from State 1 to State 3?

 

Is the position / averaged reading reported as the averaged ADC value, or simply as the object being located at Position 1,2,3, or 4?

 

I don't read C, so it would help to see your Algo as a flow chart or in pseudo code.

 

Without yet knowing the above it would seem that you likely need both position (ADC) readings, and velocity (change in position / time) data, to determine if the object "Stopped" at State 2.

 

Do you need to flag that the object is in State 2 immediately when that happens, or only know that information once it reaches State 3?

 

I don't quite know what constitutes a valid: "The object entered State 2" yet.

But it seems that you might want an array of ~ 18 Averaged position readings, and an array of ~ 17 Velocity values, (i.e. (Position N+1) - (Position N)   ).

The "time" for the velocity is immaterial as you are obtaining averaged position readings once every 11 mSec, so the Delta ADC readings (Delta Position Readings), provides the "velocity" information.

 

Once you have a well defined definition of "The object entered State 2", then scanning the array for the event's occurrence should be straight forward.

 

JC 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yea typo.  >=

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It completes the travel to the end and stops before it will cycle back to the start position. 

The states are ADC values stored into memory.  They are calculated when you teach the device. 

 

I think the slowing down is the problem you mentioned.  Since it is checking the difference against a threshold, if it slows down it could dip under that threshold for a few cycles and cause the state.

 

State 2 is well defined

 

The average is an accumulator of the ADC value until the counter is exceeded and then is does the average by the accumulation/counter and then clears both

 

Just when it reaches the end point and is not moving.

 

The array now might be a good idea.  Let me look into that.  Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 a state machine that uses the ADC to determine what state the device is in (position wise) 

Well, that could be your downfall..The ADC itself should not define the current state.  What if you need to add a button or other things to change some of the states? 

The state should be its own entity & not simply the ADC value:

state_of_warming_up

state_of_filling_tank

state_of_spin_cycle

state_of_wait_for_nickel

 

Each of your states will have rules (conditions) for what is allowed to change to other states...that may be the adc value...or something else entirely, or even some complex combo. Some states might not even show the adc at all in their conditions.

state_of_spin_cycle:

    if button3==true   ===>state_stop_spin

    if ADC>load_limit  ===>state_sound_alarm

 

state_of_wait_for_nickel:

  if changer==nickel   ==>state_open_trap_door

  if changer==dime and button4==true  ==> state_sound_alarm

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!