> Have you ever wished for a 500 Hz, millimeter-precise linear position sensing system
Kind of, but I'd like an 0.01mm precision please. It can be just a few Hz, I don't need 500 Hz.
Great project though!
Kind of, but I'd like an 0.01mm precision please. It can be just a few Hz, I don't need 500 Hz.
Great project though!
The other side of it though is that you're starting to get down into the "everything needs to be temperature controlled" region as you squeeze that precision number. FR-4 and copper have thermal expansion coefficients around 15-20ppm/C. If I'm doing this mental math correctly, a 5 deg temperature rise would make a 1m long piece of FR4 expand by 0.1mm, or a 10cm piece of FR4 expand by 0.01mm.
[1]: https://www.st.com/resource/en/application_note/an4629-adc-h...
[2]: https://en.wikipedia.org/wiki/Successive-approximation_ADC
On that note: I'm looking for a mouse style camera sensor unit that can export full frame rate raw to a system where I can actually decode such an absolute positioning code.
Anyone got something in the sub-100$ range?
https://ardupilot.org/copter/docs/common-mouse-based-optical...
https://github.com/RCmags/ADNS3080_frame_capture
https://www.pixelelectric.com/sensors/distance-vision/adns-3...
If anyone has explored further how much the timing can be optimized, or maybe there are other mice sensors for with better frame dumping capabilities, I am curious to hear about it as well.
With that said even if you remove all the unnecessary delays data transfer over SPI will likely be a limiting factor for very high framerates. Assuming 4MHz SPI and 32x32 8bpp image that would be at most 500FPS. Few hundred FPS would still be nice, and you might push it a bit higher with increasing frequency but it's probably not possible to push it much further than 1000FPS without MIPI or some kind of other parallel data transfer protocol.
The ardupilot project in sibling comment seems to be using the mouse movement output directly instead of capturing the frame and then doing optical flow analysis on main CPU. The image dump is only being used to verify camera focus.
Tldr: understood that you think you don’t need 500 Hz, but there is a technological limitation why you need that frequency for these systems to work.
The reason these measurements need to be so fast is because the measurement is not absolute but periodic. Meaning that when you measure something it can’t tell you how large it is in absolute terms just how much larger it is than the closest integer period. In mathematical notation you can measure x where the whole distance is k*period+x, where k is an unknown integer, and period is a design parameter. It can’t natively tell you what is the value of k.
So to figure out the whole measurement you need to calculate k. And you can do that by keeping track of it. You know it is zero when they zero out the caliper, and you know that it just increased by one every time there was a falling discontinuity of x. (Meaning that every time x approaches the period and then suddenly drops to a low number it just crossed over one of these period boundaries.) Similarly you decrease k every time x had a positive discontinuity.
And you can only do that trick if the sampling rate is much higher than the speed the caliper is moved. If you sample too slow suddenly the caliper might move multiple whole periods between two samples and the code would loose track of the value of k.