0

I am making analog speedo and rpm gauge for both a bike and a car using x27.168 stepper motors and AX1201728SG motor driver. I have encountered quite a problem with showing data that is not constantly updated (or at least as often as would be needed for stepper movement to be smooth).

Because data is coming at intervals that are quite long, steppers rush to next value, then they have to wait for next value to come in when they start moving again. That makes movement look jerky. The library I am using for this (SwitecX12 by Guy Carpenter) supports acceleration/decelleration table, but tweaking this to be too slow would make the needle less responsive when it has to travel larger distance. Its also not practical as I cant hope to cover all cases. I need to somehow take into consideration when next value is expected to arrive and time the movement of stepper to this, so that it reaches its goal at about the time next value is available. But here's when complicated part comes in: if next value is further down, then stepper must not stop at current value as that would again look as a jerk but must continue, adjusting speed only slightly over period of time unnoticeable to human eye

I need some advice on how this is usually done. If I try displaying my data on real car gauges its exactly as I want it to be, so there must be some kind of algorithm behind it. Is there any known algorithm/way of doing this, any implementation, anything that would help me with making this?

Help is much appreciated! Thanks!

Terraviper-5
  • 191
  • 3
  • 14
  • Does the 'real gauge' display work acceptable even with your very slow updates? – Spehro Pefhany Nov 22 '20 at 00:21
  • @SpehroPefhany Yes, it does, I didnt want to post videos in original question but I can show you the difference here https://www.youtube.com/watch?v=y7T9y9YlisA Please do not make any assumptions on delay here, because all were synced in video editor to be able to compare them easier and notice the differences. Also the first one was not calibrated so it shows a tiny bit less than other two. All three were fed the exactly same data – Terraviper-5 Nov 23 '20 at 22:23
  • It sounds like your real problem is that you're using a diagnostic output while the real instruments are using a proprietary data feed. – Chris Stratton Nov 29 '20 at 13:12

1 Answers1

0
car         VS.    meter
velocity           position
acceleration       velocity

So you need a trajectory planner for your meter so that it moves to the position (car velocity) with a certain velocity (car acceleration) with maximum motor acc/dec. As the meter will always lag VS. the real value it won't cause jerky movement.

EDIT: A simple digital RC filter

k=Tsample/RC, in your case Tsample is 180ms and RC shall be approx. 350ms, so k=0.51

k, input, y, y_old : float;

y = y_old + k*(input-y_old); 
y_old = y;

You do execute this at every received new value (each 180ms).

Marko Buršič
  • 23,562
  • 2
  • 20
  • 33
  • Unfortunately I only have access to current car rpm and speed every 180ms :/ So there is not much data to calculate any accelerations/decelerations from. I expect some amount of lag, but more than 250ms is undesireable as human starts to notice it, at least for rpm meter – Terraviper-5 Nov 23 '20 at 22:31
  • Then you do only need a digital low pass filter, to make it less responsive to changes. It's called IIR or FIR filter, IIR is very simple to implement and would give you good results without big efforts. – Marko Buršič Nov 23 '20 at 22:57
  • Thanks for suggestion. I have read about those filters. If I understand correctly, IIR filter if for realtime data, but works by delaying the output, which, in this case, would be quite large since values are only in 180ms intervals. I have examined the VW cluster a bit more in detail and there doesnt seem to be much of a delayed response, max 30ms. Also if change in RPM is less than 40 it doesn't even respond, probably to eliminate those small jerks. The speedo on the other hand does respond even to change of 1. I have also tested the moving time of the needle. – Terraviper-5 Nov 29 '20 at 00:23
  • For RPM it goes from approx 500ms if moving for 40rpm and up to cca 1200ms if moving for 5000rpm at once, while for speed its similar, 500ms for 1 and 1200ms for 100km/h difference. Plotted data is a bit erratic but resembles some kind of logarithm function a bit. Acceleration is also a lot faster than deceleration, a lot of time is spent decelerating. I have also quickly tested what happens if I change value back to original before needle has finished moving, and it seems like in this case it doesnt use normal deceleration but same speedy change as for used for acceleration – Terraviper-5 Nov 29 '20 at 00:23
  • So it would have a rising time approx 1500ms for max. range. The rise time is approx 4x the 1st order IIR filter constant -> \$T\approx 350ms\$ – Marko Buršič Nov 29 '20 at 10:39