Hello Everyone!

I am trying to determine if the Arduino's default ADC read speed will suffice for my application.

I am attempting to read a linear actuator position via ADC. (I am open to other position sensing options though)

The speed of the motor that I am driving is:
16"/s

(Home made Linear Actuator will post if interest but trying to stay on topic.)

Now what worries me is ADC read rate of the Uno which as I understand from the forums is 9615 Hz

Now after doing some back of the napkin calculations it seems that this ill give me about 0.002" per adc read. So it all sounds good however, in talking to some other arduino users I have heard that with fast motors the uno can "loose the position" of the motor due to this sampling rate.

I should point out that I am aware of some other options that can be done to increase the ADC read rate.

But I will be honest prefer to keep is as simple as possible for now.

Should I be looking at implementing a rack and pinion instead of 2 slide potentiometers?
What other linear sensing options would you recommend?

The almost-10KHz rate is the rate you get when you take ADC samples and just count them. You can't do anything useful with them. As soon as you start doing calculations like motor position, your achieved rate will drop.

There are other ways to do it. analogRead() is intentionally quite slow. But let's not go there right away.

16"/sec is quite fast. The cheap actuators that most hobbyists are using are in the 1-2"/sec range. But it's absolutely not too fast for the Arduino. The limitation is really the resolution of analogRead(). You only have 10 bits, or 1024 possible readings on most Arduinos. So splitting your (unspecified) total travel into 1024 segments, even if it travels that distance in half a second, you would only need 2KHz sample frequency to "see" every single value between 0 and 1023.

Then add noise - the Arduino board isn't a dedicated ADC, so you really won't achieve the full resolution without some noise. The reading from a pot (linear or otherwise) will fluctuate up and down by a few counts. You can use that to your advantage because "oversampling" or "taking lots of readings and averaging them" will increase the achieved resolution. Averaging nine readings of 512 with one reading of 513 tells you you're pretty close to 512.1.

Oversampling is one case where you do want to have reasonably fast ADC readings, so you can quickly grab ten of them. Once again, you are unlikely to need more than the default Arduino speed.

I would turn the discussion around: how fast do you need to read the position to get effective control over your actuator? Can you really send 10,000 different commands to the motor in a second? Certainly not, if you're using the default Arduino PWM speed of 480Hz. (It's different on different pins on different Arduinos.) In my own usage of linear actuators, I never needed more than 100 Hz updates to the motor. This implies that even with oversampling of 10:1, I don't need more than 1KHz ADC sampling. For the slower actuators, something like 10 or 20 updates per second is sufficient.

Morgan,

Thank you for an excellent reply! Quite a bit to digest there as well!!!

So I will attempt to address all the points I can to give the forum a better idea of what I am doing here.

First I had a need for fast linear actuator. As I said it needed to move at least 16"/s and it really only needed to move about 1lb. Now this actuator needed to have speed and position control with a resolution of about 1/10" so pneumatic seemed to be out and most commercial options were out of my price range. hence the DIY motor seen in the photo attachment. It uses a BLDC whose shaft is attached to a ball screw to get me the linear travel I wanted. this BLDC will be controlled with a off the self ESC I was inspired by the video here:How to make a powerful electric actaultor , Linear motor , electric cylinder - YouTube

So with that out of the way…

Position sense:
For the position I am currently looking at about 3-4" of travel thus slide pots are a possibility ( was gong to use 2 of them and average them on the Uno to get the effective tolerance down) I am looking at using an incremental encoder with a rack and pinion but again wanting to keep it simple for now.

I am planning to eliminate the noise as much as possible by as you said taking the average of some read values and implementing a Low pass filter on the hardware side.

From my proposed system requirements it looks like I need to control is about 400Hz, however I should say this has yet to be solidified.

This actuator is meant to mimic human movement so I want it to keep up with the users inputs without impeding it…

I hope that clarifies my overall objective…

Thanks!!!

9kSPS is absolutely fine for position control, 1kSPS is plenty in fact. For current control its another matter, >10kSPS would be desirable for a current control loop, such as the inner loop in a servomotor system,
but that's another story.

cbocatto:
First I had a need for fast linear actuator. As I said it needed to move at least 16"/s and it really only needed to move about 1lb. Now this actuator needed to have speed and position control with a resolution of about 1/10" so pneumatic seemed to be out and most commercial options were out of my price range. hence the DIY motor seen in the photo attachment.

The speed of the motor is irrelevant to position control sampling frequency as the motor will be stationary at the end point of each motion. The acceleration/deceleration rates are more relevant.
With PID loop control faster sampling means lower latency which improves loop stability (meaning more loop
gain can be used to tighten up the response). However a mechanical system like this has a very low
bandwidth unless its ultra lightweight, so beyond a certain point increasing the sample rate gains no
useful improvement. What can improve reponse is having a direct velocity sensor (rather than differencing
position samples).

however, in talking to some other arduino users I have heard that with fast motors the uno can "loose the position" of the motor due to this sampling rate.

Can you elucidate on this? It makes no sense to me.

Optical sensing would work faster and more sure.