Help with gauge altimeter

[Adrian_gc]

Hey guys, I'm Adrian, I need help with my altimeter, I connected the VID60-02 engine and the IR emitter as you can see in the pictures, the truth is that it works, but only if it descends or ascends at a moderate speed, the problemIt comes when I make a descent from 30,000 feet almost sharply, altimeter needle keeps spinning at full speed but starts getting to have desynchronize 1 turn unless the simulator or so. the code I am using is the one that happened to me Warhog, and connections I have done as you can see in the photographs. Can you tell me why that desynchronization? Thank you very much.

 

Code:

// include AccelStepper library

#include <AccelStepper.h>

 

// include DcsBios library

#include <DcsBios.h>

#include <Servo.h>

 

// DcsBios-related declarations

DcsBios::ProtocolParser parser;

 

#define STEPS_PER_REVOLUTION 240

#define ZERO_OFFSET 0

 

AccelStepper stepper; // Defaults to AccelStepper::FULL4WIRE (4 pins) on 2, 3, 4, 5

int currentStepperPosition = 0; // current stepper position (in steps, from 0 to STEPS_PER_REVOLUTION-1)

signed long lastAccelStepperPosition;

 

void setup()

{

Serial.begin(250000);

 

pinMode (12,INPUT); // LOW when in zero position, HIGH otherwise

 

 

// set up stepper motor for zeroing

stepper.setMaxSpeed(1000);

stepper.setSpeed(500);

// run clockwise until we detect the zero position

while (digitalRead (12)==1) {

stepper.runSpeed();

}

 

// add zero offset

stepper.runToNewPosition(stepper.currentPosition() + ZERO_OFFSET);

 

// tell the AccelStepper library that we are at position zero

stepper.setCurrentPosition(0);

lastAccelStepperPosition = 0;

// set stepper acceleration in steps per second per second

// (default is zero)

stepper.setAcceleration(1000);

 

}

 

void loop()

{

// handle DcsBios communication

while (Serial.available()) {

parser.processChar(Serial.read());

}

DcsBios::PollingInput::pollInputs();

 

// move stepper motor

stepper.run();

}

 

void onDcsBiosWrite(unsigned int address, unsigned int value) {

if (address == 0x107e) {

digitalWrite (13,1);

unsigned int alt100ftValue = (value & 0xffff) >> 0;

 

// convert data from DCS to a target position expressed as a number of steps

int targetPosition = map(alt100ftValue, 0, 65535, 0, STEPS_PER_REVOLUTION-1);

 

// adjust currentStepperPosition to include the distance our stepper motor

// was moved since we last updated it

int movementSinceLastUpdate = stepper.currentPosition() - lastAccelStepperPosition;

currentStepperPosition += movementSinceLastUpdate;

lastAccelStepperPosition = stepper.currentPosition();

 

if (currentStepperPosition < 0) currentStepperPosition += STEPS_PER_REVOLUTION;

if (currentStepperPosition > STEPS_PER_REVOLUTION) currentStepperPosition -= STEPS_PER_REVOLUTION;

 

int delta = targetPosition - currentStepperPosition;

 

// if we would move more than 180 degree counterclockwise, move clockwise instead

if (delta < -(STEPS_PER_REVOLUTION/2)) delta += STEPS_PER_REVOLUTION;

// if we would move more than 180 degree clockwise, move counterclockwise instead

if (delta > (STEPS_PER_REVOLUTION/2)) delta -= STEPS_PER_REVOLUTION;

 

// tell AccelStepper to move relative to the current position

stepper.move(delta);

}

}

 

Pictures:

[Boltz]

Sounds like your stepper motor just isn't fast enough to keep up with sharp descents

[Warhog]

I don't think that's it Calum. I have had that little motor just screamin so I don't think speed is an issue. I think it has to do with something in the code or the lack thereof. I expect Ian will be able to decipher that much better than myself.

 

I do have a question though... Adrian which shaft did you use on the VID60, the inner shaft or the outer plastic shaft. One shaft is used for the minute hand and the other for the hour hand. This motor was originally designed to run a clock.

[Adrian_gc]

Hi guys, the motor is the VID60-02, and the shaft that i am using is the inner shaft, no plastic. I can confirm that if i descend the a-10c with 15-25 degress it go perfectly from 30.000 to 0 ft...but if i put the plane 90 degrees down,,,the pointer begin to be in a total desynchronization.

 

I don´t know if i can change the speed of the stepper motor to more fast !!! but i feel that is not enought fast to 90 dregress descent. After do this descend and fly stable,,,,the pointer needle continuous desynchronization until i reset the Arduino.

Edited July 17, 2015 by Adrian_gc

[FSFIan]

When you are talking about total desynchronization, do you mean that the physical pointer starts to lag behind the sim but eventually catches up again if you resume level flight or does it stay out of sync until you reset the Arduino?

 

If it does catch up again, the software does what it is supposed to do and you simply need to increase the maximum stepper speed (change the number in the stepper.setMaxSpeed(1000) line).

 

If it does not catch up again, it's either a hardware or a software problem. In that case, please decrease the max. speed until the problem happens at slow descents / climbs that have worked flawlessly before and see if you get a permanent desync or if it catches up again given enough time.

 

If the pointer catches up eventually at lower max. speed values but goes out of sync when you increase that value, the most likely cause is that your pointer is either too heavy for the stepper or mounted in a way that can slip during acceleration.

[Adrian_gc]

Ok i am going to try to change the speed to max....wich value is the max for the VID60-02 ? Now is set on 1000.

[Warhog]

I can not find a data sheet for this motor but as its close to the the VID28 series maybe we can use that as a rough guide. The max speed is 500 Hz but the data sheets suggests it be run at 200Hz for increased longevity. I believe that translates to 2000 for the setMaxSpeed in the code.

 

I would be careful and only increase in small increments as there is no confirmation as to Max Speed of this motor and you don't want to fry it.

 

Can anyone else verify this data???

 

BTW Adrian, congratulations on getting the Altimeter up and running. Well done :thumbup:

[bnepethomas]

Hi Guys

 

I've seen the Vid motors start missing steps if you try and move them too fast. They aren't engineered to move things quickly.

cheers

 

Peter

[Mike Powell]

I can not find a data sheet for this motor but as its close to the the VID28 series maybe we can use that as a rough guide. The max speed is 500 Hz but the data sheets suggests it be run at 200Hz for increased longevity. I believe that translates to 2000 for the setMaxSpeed in the code.

 

I would be careful and only increase in small increments as there is no confirmation as to Max Speed of this motor and you don't want to fry it.

 

Can anyone else verify this data???

 

BTW Adrian, congratulations on getting the Altimeter up and running. Well done :thumbup:

 

The data for the Switech X-25 series is similar. A 200 Hz driving frequency is the maximum without the use of acceleration and deceleration sequences. If you use accel/decel you can build up to a 600 Hz driving frequency. However, this is only true when the motor is spinning without the mass of a pointer. Once you add the pointer the rotational inertia increases and the dynamic limits shift downward.

[Warhog]

I have been wondering about the affects of acceleration and deceleration lately as I'm working on several gauges at the moment.

 

In a situation like CNC, accel/decel is required because you are generally moving from a stopped position to another fixed point and then doing an operation. In a gauge like an altimeter or VVI, the pointer is always moving to a new position but it never really stops at that position because another new position is sent from the simulator. Its always in a state of motion so why would you need to accelerate to another position. In fact it should move (accelerate) at the same rate as the gauge in the simulation. Now think about this for a minute...the gauges in the simulator already simulated acceleration or deceleration. If they didn't, their movement would look rather odd. All we are doing is repeating exactly what those gauges do. If they start moving slowly and speed up, the DCS-BIOS export values reflect this and our gauges repeat the same motion at virtually the same time. So why do we need to include an acceleration factor in the code.

 

The critical value as I see it is "speed" and setting the speed close to maximum will allow our motors to move as fast as the simulators gauge is moving. Right now the gauge is being held back by a governor... the max speed you set in the code. If you don't let the motor move as fast as the simulators gauge it will always lag behind instead of following the motion of the simulator.

 

I would also reason that if one did in fact introduce acceleration into the code then you would, in fact, be altering values that are coming from the simulator to match whatever the acceleration tables generate.

 

The point to remember here is that our gauges are there just to repeat exactly what we would see in the cockpit as to the speed of the pointer and its position and its acceleration or deceleration etc. All that has already been factored in to what you see in the cockpit to make it look real. There is no need to have it recalculated again.

 

And that's my story and I'm stickin too it.:smilewink:

Edited July 18, 2015 by Warhog

[FSFIan]

Correct, the role of limiting the acceleration in the Arduino side is mostly to protect the motor (because to drive it at maximum speed safely -- without negatively affecting the usable lifetime of the part -- may require adhering to some maximum acceleration).

 

Keep in mind that while DCS simulates the acceleration, we don't get that data from DCS. Instead, we get the current pointer position (but no information about whether it is speeding up or slowing down).

 

In an ideal case, we would get 30 updates per second from DCS, which would be 33 ms apart. In the real world, at least on my PC that barely manages 27 FPS, the updates can be 33 to 80 ms apart. I assume that the Arduino-side acceleration profile also helps to mitigate the negative influence of this non-constant sample rate.

[Adrian_gc]

Hey guys, I've finally changed the line velocity step by step and yet is still awaited from the needle simulator engine I upload a video of what happens. See if you can lend a hand to me. The code setting is the ogirinal. With the rate in 2000, 1500, 3000 ... etc does exactly the same and the needle is balsa wood, very light and glued.

 

https://www.youtube.com/watch?v=y97ISWnap1Q

[FSFIan]

Take a close look at 1:14. The pointer has completed several successful rotations at the same speed before, but in that one the motor stutters and is visibly missing steps.

 

Check the wiring. Make sure that all connections are soldered securely and that no wire is longer than it needs to be. Make sure the Arduino has a good power supply (verify it is between 4.75 and 5.25 V, some USB ports provide less!) and that you have decoupling capacitors. See if you can provoke the error by wiggling the wires around.

 

You can also try to move the needle so it is glued on in the middle, to rule out problems with an unbalanced load.

[Warhog]

Hi Adrian

 

Sorry not to respond faster. Been under the weather for the last couple of days.

 

I watched the video and can confirm that the issue is lost steps. You can hear it and see when it happens on my CNC mill although it seldom happens. But its quite evident when it does and it pretty much screws my work piece.:mad:

 

So why does that happen:

 

1. Speed is set to fast.

2. Noise is being picked up from something/somewhere

3. Its driving too much weight

4. Friction...the shaft is rubbing on something.

 

I ran some tests and made some videos because of your problem. These tests use a sketch I wrote just to determine the max speed of a stepper under its operational conditions. I set it to run at a specific speed and move it 20,000 in one direction and 20,000 steps in the opposite direction. If it doesn't stop at the same point on each set of rotations then there is a problem with lost steps. This is what I use to determine if the motor can do what I want it to do. If it can't then I move to a stronger motor such as a Nema series as you can see here.

 

#include <AccelStepper.h>

#define HALF4WIRE 8

// Motor pin definitions
#define motorPin1  2     // A1 
#define motorPin2  3     // A2 
#define motorPin3  4     // B1 
#define motorPin4  5     // B2 

// Initialize with pin sequence IN1-IN3-IN2-IN4 for using the AccelStepper with 28BYJ-48
//AccelStepper stepper; // Defaults to AccelStepper::FULL4WIRE (4 pins) on 2, 3, 4, 5

AccelStepper stepper1 (HALF4WIRE, motorPin1, motorPin2, motorPin3, motorPin4, true);

void setup() {
 stepper1.setMaxSpeed(1500.0);
 stepper1.setAcceleration(300.0);
 stepper1.setSpeed(1500);
 stepper1.moveTo(20000); //250 full rotations @ 48 steps each = 12,000 steps

}//--(end setup )---

void loop() {

 //Change direction when the stepper reaches the target position
 if (stepper1.distanceToGo() == 0) {
   stepper1.moveTo(-stepper1.currentPosition());
   delay(500);
 }
 stepper1.run();
}

 

The first video illustrates the VID60 running at a speed of 2000. You see how fast it runs :surprise:. ... But it stalled.:( ........

nb: Please understand that this is my very first video ever and I need to work on composition as this vid is not very good. They will get better though.

 

The next video shows the motor running at a speed of 1000. Its running much faster than in your demonstration video. It does 75 revolutions and ends up at the same spot in each direction. Its been running for the last 30 minutes and I haven't see any change in where it stops.

 

This tells me no steps are lost and its fine to use this motor for this application. I never actually tried this before. I just assumed they would work based on what I saw in other forums where this motor was used successfully.

 

Adrian, I have some ideas for you to try. I just recently wrote this test code, which you saw used in the videos I linked. But its different than the original code you are using. Its based on a half step code. That may help with your issue. So try these changes...

 

1. Change the code to Half4wire instead of full4wire

2. Set speed to 1000

3. Set acceleration to 300

 

Please report back the results.

 

We are all wanting/trying to learn the idiosyncrasies of using stepper motors for gauges in this forum so this will be a valuable exercise and a good learning experience for all.

 

 

PS. I just added this video using a VID60 motor for the drum display on the speed indicator.

 

[kadda]

Hey guys, I've finally changed the line velocity step by step and yet is still awaited from the needle simulator engine I upload a video of what happens. See if you can lend a hand to me. The code setting is the ogirinal. With the rate in 2000, 1500, 3000 ... etc does exactly the same and the needle is balsa wood, very light and glued.

 

https://www.youtube.com/watch?v=y97ISWnap1Q

 

i can may be help with that, in my case the line of sketch for controling the motor with the joystick were making it react exactly like you said it was with yours, so in my case i added a function for the button that s in the joystick so it can make the motor move only when the button is pushed in the same time i move the stick, may be you need to modify a little the lines controling the zeroing detector ...