A-10C Altimeter test

[overpro]

The stepper motor is the same one I used in the EMI panel: http://forums.eagle.ru/showthread.php?t=115997

 

 

 

The current unresolved issue is if in-game pointer goes too fast, I can't make the stepper motor catch up.

But it will try to match the position by using the shortest path.

[Dropship Pilot]

Looks nice and smooth. Good job. :thumbup:

 

How do you find the zero position for the needle?

 

Cheers,

DSP

[overpro]

Looks nice and smooth. Good job. :thumbup:

 

How do you find the zero position for the needle?

 

Cheers,

DSP

 

There is a photo reflective sensor, you can see it emits infrared light, at the beginning of the video. The first 6 seconds is the "go zero" process.

[kemz]

Which microcontroller you use?

 

I didn't start to make my project but, I think:

 

You should use subroutin that check if value close to exact value like ** (in this condition indicator of altimeter is right on 0) your stepper motor indicator goes 360 degree, same with visual indicator. According to my observation, fail ratio of real indicator is not much for one tour.

 

Or you can split this check process for every quarter of 360 degre to reduce correction movement of real indicator.

 

I think you tried this but if you did not, you can decrease time delay of your microcontroller to get more accurated value to indicate to steper.

 

** You can compute "exac value" with modular arithmetic:

 

_exacValue = _valueOfFetchedAltitude % 100;

 

Note that _exacValue will be approach to 0. NOT exactly 0.

Because microprocessor would not be catch 0. Because of processor frequency.

 

Regards...

[overpro]

Which microcontroller you use?

 

I didn't start to make my project but, I think:

 

You should use subroutin that check if value close to exact value like ** (in this condition indicator of altimeter is right on 0) your stepper motor indicator goes 360 degree, same with visual indicator. According to my observation, fail ratio of real indicator is not much for one tour.

 

Or you can split this check process for every quarter of 360 degre to reduce correction movement of real indicator.

 

I think you tried this but if you did not, you can decrease time delay of your microcontroller to get more accurated value to indicate to steper.

 

** You can compute "exac value" with modular arithmetic:

 

_exacValue = _valueOfFetchedAltitude % 100;

 

Note that _exacValue will be approach to 0. NOT exactly 0.

Because microprocessor would not be catch 0. Because of processor frequency.

 

Regards...

 

I'm using Arduino Mega2560,

The code check the deviation between stepper motor and visual indicator when the data is received from export.lua, the problem is if the visual indicator's RPM is higher then the stepper motor limitation then I have nothing to do.

[kemz]

I'm using Arduino Mega2560,

The code check the deviation between stepper motor and visual indicator when the data is received from export.lua, the problem is if the visual indicator's RPM is higher then the stepper motor limitation then I have nothing to do.

 

To solve that problem, i think you may keep the current degree of visual indicator status in global variable. I'm in if altimeter indicates 3500ft. then current degree value will be 180 degree or if altimeter=3100 ft visual indicator equals to 36 degree.

 

a basic algo to your sketch:

 

setupt() {}

 

loop{

Altitude(); //take alt degre and send stepper

}

 

Altitude() {

 

//taking visual alt codes

//calculate degree of current alt (simply modular arith.)

if(degree == 0)

resetStepper()

}

 

resetStepper() {

 

//set stepper indicator to 0 degree. **

}

 

**Because you will know current degree of stepper indicator, you can reset your stepper motor. I'm in if stepper current indicator would be 3 degree your resetStepper function will backstep indicator to 3 degre (to left). Or current value equals to 358 degree. Stepper indicator will be rotated 2 degree forward (to right) by resetStepper function.

 

And what are the properties of you stepper? You can use more sensitive stepper model.

 

By the way i use arduno uno (i didn't remember which atmega model) but i can say that arduino is good choice comrade.

 

Regards.

[kemz]

Sorry i just didnt notice to "RPM based problem".

 

You can try this, if difference between visual indicator and real stepper indicator increases (lets say 5 degree), you multiply 2 to current pwm voltage.

 

Or you run stepper motor in full voltage always. (i think 6v for standart servos and steppers) but in this case you will change your algorithm to equalization of degrees between visual and real indicators based.

 

Or as i said, you can use gear wheel to decrease torque and increase speed : )

 

Regards

Edited December 8, 2013 by kemz

[hawk4base]

Did you take the time delay of x ms in acount between DCS output -> input into the io board and the output to the servo?

[overpro]

Sorry i just didnt notice to "RPM based problem".

 

You can try this, if difference between visual indicator and real stepper indicator increases (lets say 5 degree), you multiply 2 to current pwm voltage.

 

Or you run stepper motor in full voltage always. (i think 6v for standart servos and steppers) but in this case you will change your algorithm to equalization of degrees between visual and real indicators based.

 

Or as i said, you can use gear wheel to decrease torque and increase speed : )

 

Regards

 

I'm using Arduino Mega2560 and some other chips including 595 to control all the stepper motors : 12EMI, 2 Hydraulics, 2 Fuel, 1 VVI, 2 Airspeed, 1 Flap, 1 AoA, 1 G, 1 Altimeter, 3 environments = total 27 stepper motors.

If the code put too much time on altimeter then other stepper motors will not move until altimeter reach the target position.

I made a test and the algorithm like this: If the altimeter behind more then 2 steps of the visual needle, then the code will enter into a while loop to try move the needle to the target position:

while( AltimeterPosition != TargetPosition )
{
   AltimeterOneStep(CWorCCW);
   delayMicroseconds( 800 ); // this is the required minimum delay, or the motor will lose steps. 
}

By using this approach I did this test: doing a -60degree deep dive from 30000 feet and when the altitude below 10000 feet the delay appears, Yes, the delay is still there but better then before.

The side effect is this will lead other needles stop, unless altimeter catch up the target position.

 

It seems that move the altimeter to another arduino board is a better choice.

 

I tried the maximum speed of this motor, it's about 0.89 second per round.

[overpro]

Did you take the time delay of x ms in acount between DCS output -> input into the io board and the output to the servo?

Hi Hawk4base,

My currrent export.lua provides data feeds in 20ms interval.

the time for one loop() in my arduino code is around 7~9 ms.

 

Is it to say I need some code/algorithm to compensate this delay? Could you provide some more details on this? Many thanks

[overpro]

Ok, here is an update:

This stepper motor---VID29 has a 125Hz start driven frequency and has a maximum 600Hz driven frequency, that means if I want to make the pointer go full speed, I have to delay 1/125 seconds for the first step and then decrease the delay time for the further steps gradually, until the delay time decrease to 1/600 seconds.

This is the screen capture from the stepper motor's specification:

 

 

 

 

So I have changed the code to this:

  [b] int delayMs = STARTDELAY;[/b]      
   for ( int i= 0; i < abs(step); i++)
   {
       if ( di == 6 )
       {
           di = 0;
       }
       else if ( di == -1 )
       {
           di = 5;
       }
       digitalWrite( 2, (drivePattern[di] & 1) > 0 ? HIGH : LOW);
       digitalWrite( 3, (drivePattern[di] & 2) > 0 ? HIGH : LOW);
       digitalWrite( 4, (drivePattern[di] & 4) > 0 ? HIGH : LOW);
       digitalWrite( 5, (drivePattern[di] & 8) > 0 ? HIGH : LOW);
       [b]delayMicroseconds(delayMs);[/b]
      [b] if (delayMs > FINALDELAY[/b][b])
           delayMs -= 20;[/b]                      //decrease the delay time gradually
   }

The test result is good, at the 30000 feet and do a -90 degree vertical dive the real pointer can catch up the visual pointer all the time.

[kemz]

It seems that move the altimeter to another arduino board is a better choice.

 

I appreciated this. (Or we can use a PIC for only one indicator to decrease cost.)

 

So a question: According to your algorihm, when delay about altitude indicator occures, will other indicators show wrong value? Or after many little delays. Maybe we couldn't notice wrong indicator because indicators (except altimeter and may be clock) are move slowly.

[overpro]

I appreciated this. (Or we can use a PIC for only one indicator to decrease cost.)

 

So a question: According to your algorihm, when delay about altitude indicator occures, will other indicators show wrong value? Or after many little delays. Maybe we couldn't notice wrong indicator because indicators (except altimeter and may be clock) are move slowly.

 

To be precise, other indicators will show wrong (not up to date) value, because they move very very slow while arduino focus on moving the Altimeter needle.

Here is a case: do a -90 vertical dive from 30000, and after below 10000 the engine will stop for some reason, the altimeter needle moves very fast and many EMI needles move towards zero position at the time. But my EMI needles doesn't move. If I can save my plane from dive the altimeter needle will slow down, then my EMI needles can catch up the visual needle in 0.5~1 second.

[cefs]

That sounds like a bug in your code. Maybe have a return statement rather than a break in the path your code takes when the altimeter is moving fast. Just a guess of course, but would be worth following the different paths the code can take and check the values of controlling variables etc. Very impressive so far, inspiring me to get on with my pit.

[Gadroc]

Part of the problem is using loops based on your example code. An arduino sketch calls the loop method over and over and over again. What you need to do is track target, next step time and current positions. Each iteration of the loop check to see if the next step time is here or past and if so step that motor in the right direction then adjust the current position. You can do this with a few motors in series if you want. This also allows you to check for new target positions as well.

 

What will happen with the system as it stands is an escalating blocking scenario. If a new target comes in you'll block all other execution in your "for ( int i= 0; i < abs(step); i++)" delay loop. Which means it has to get all the way to the next target before it reads input again. This means it will not get new smaller incremental changes from other smaller moving needles as you are not processing input during the move. This will make them stutter as they move to new position and then have to wait for all the steps to the large move on the faster moving needle.

 

That being said you will get stutter in motion unless you block as you are or move the stepping code to an timer interrupt (which is where i've gone with the EOS firmware). Now the challenge I have not tackled yet is managing multiple motors in one interrupt is difficult. You can not reliably use microseconds in an interrupt and you need to be very careful how much code you use to loop through motors. You don't get a whole lot of instructions between timer fires at really high speeds on the stepper.

[overpro]

Part of the problem is using loops based on your example code. An arduino sketch calls the loop method over and over and over again. What you need to do is track target, next step time and current positions. Each iteration of the loop check to see if the next step time is here or past and if so step that motor in the right direction then adjust the current position. You can do this with a few motors in series if you want. This also allows you to check for new target positions as well.

 

What will happen with the system as it stands is an escalating blocking scenario. If a new target comes in you'll block all other execution in your "for ( int i= 0; i < abs(step); i++)" delay loop. Which means it has to get all the way to the next target before it reads input again. This means it will not get new smaller incremental changes from other smaller moving needles as you are not processing input during the move. This will make them stutter as they move to new position and then have to wait for all the steps to the large move on the faster moving needle.

 

That being said you will get stutter in motion unless you block as you are or move the stepping code to an timer interrupt (which is where i've gone with the EOS firmware). Now the challenge I have not tackled yet is managing multiple motors in one interrupt is difficult. You can not reliably use microseconds in an interrupt and you need to be very careful how much code you use to loop through motors. You don't get a whole lot of instructions between timer fires at really high speeds on the stepper.

 

Hi Gadroc, it's exactly like you said, the do while loop will block other needles movement, so I'm thinking use another board to control just one Altimeter.

[triise]

Hi, I'm working on my altimeter with a zero-setting stepper motor (VID60 series). But haven't figured out the code yet.

Could you share the code you are using now?

[Warhog]

I have been talking with some rather experienced people who work with steppers a lot at they were telling me that Arduino boards in general do not have the processing power to run more than a couple of steppers at the speed we would need in our cockpits.

 

I was going to suggest that the 84mhz DUE is the Arduino board to use. I purchased a Chipkit UNO32 at 80mhz to see if that would get rid of the problems. But also eliminating the use of digital write will make a big difference. I haven't had time to check this out (the Chipkit that is) as I have been rather involved in retro fitting my ADI with steppers and servo.

 

To deal with blocking movement of motors, the Accel library allows updating multiple steppers simultaneously. I have had three motors running at different speeds and different directions all at the same time so I know it can be done with that specific library.

 

 

To resolve the missing steps issue at high speed, this might be a solution. This is just concept at the moment. Use an Easy Driver board which has step rates that can be changed on the fly. Write code that selects full steps at high speed and micro stepping at slow speed. At middle speeds you would change from half step to quarter step according to the change in speed. I think this might resemble what acceleration does except for a different purpose...smooth motion without loosing steps regardless of speed. I just don't have enough programming experience to write that properly.

 

I know the VID series of steppers will run fast enough as you can see from my previous video. It just when you add all sorts of other stuff into the code it misses steps.

 

That's just my two cents and my observations. Nothing has been tested or confirmed at this point.

 

Tore... Welcome back. Good to see you back at it. As you can see the whole altimeter thing is still a WIP so stay tuned. You can read Adrian's thread on this as well. He was having issues at high speed.

http://forums.eagle.ru/showthread.php?t=145193

 

Here are some videos showing just basic high speed movement with the VID stepper motors.

https://m.youtube.com/channel/UCgWnYKO_dCMUvkMFDg3lOuA

[overpro]

Hi, I'm working on my altimeter with a zero-setting stepper motor (VID60 series). But haven't figured out the code yet.

Could you share the code you are using now?

http://forums.eagle.ru/showthread.php?t=131052

 

Hi triise, you might want to check the code at this thread.