During a poster presentation at NASA's Goddard Space Flight Center, one
of the interns presented her work on optical absolute position encoders.
Her prototype used a image sensor capable of 18,000FPS, and resolving
to absolute positioning. I was given a copy of the poster and writeup
and permi
On 6 August 2015 at 18:32, EBo wrote:
> During a poster presentation at NASA's Goddard Space Flight Center, one
> of the interns presented her work on optical absolute position encoders.
> Her prototype used a image sensor capable of 18,000FPS, and resolving
> to absolute positioning.
Did it work
I would like to read that please.
-- Original Message --
From: "EBo"
To: emc-developers@lists.sourceforge.net
Sent: 2015-08-06 19:32:31
Subject: [Emc-developers] research on optical encoders
>During a poster presentation at NASA's Goddard Space Flight Center, o
On Aug 6 2015 11:45 AM, andy pugh wrote:
> On 6 August 2015 at 18:32, EBo wrote:
>> During a poster presentation at NASA's Goddard Space Flight Center,
>> one
>> of the interns presented her work on optical absolute position
>> encoders.
>> Her prototype used a image sensor capable of 18,000FPS,
On 7 August 2015 at 12:23, EBo wrote:
> Possibly, but I cannot tell from the information Renishaw published in
> that brochure.
I think that the target is a barcode. The head can see enough barcode
to tell exactly where it is on the code sequence to within one bar,
then looks at the absolute posi
I assume they use a De Bruijn sequence <
https://en.wikipedia.org/wiki/De_Bruijn_sequence> with perhaps a manchester
encoding to guarantee frequent edges.
All you have to do on startup is to see N bits. That will tell you the
absolute position. Then interpolate some bit edges using a camera of
ap
On 7 August 2015 at 23:52, Kenneth Lerman wrote:
> What edge resolution can I get with a cheap camera/microscope?
In theory OCR could read the numbers on an absolutely standard angle
scale. Then use the number positions to get better accuracy
--
atp
If you can't fix it, you don't own it.
http:
On Aug 7 2015 4:16 PM, andy pugh wrote:
> On 7 August 2015 at 12:23, EBo wrote:
>> Possibly, but I cannot tell from the information Renishaw published
>> in
>> that brochure.
>
> I think that the target is a barcode. The head can see enough barcode
> to tell exactly where it is on the code sequen
On Fri, 7 Aug 2015, EBo wrote:
> Date: Fri, 07 Aug 2015 17:13:25 -0600
> From: EBo
> Reply-To: EMC developers
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] research on optical encoders
>
> On Aug 7 2015 4:16 PM, andy pugh wrote:
>> On
On Aug 7 2015 4:52 PM, Kenneth Lerman wrote:
> I assume they use a De Bruijn sequence <
> https://en.wikipedia.org/wiki/De_Bruijn_sequence> with perhaps a
> manchester
> encoding to guarantee frequent edges.
>
> All you have to do on startup is to see N bits. That will tell you
> the
> absolute
On Aug 7 2015 5:32 PM, Peter C. Wallace wrote:
> On Fri, 7 Aug 2015, EBo wrote:
>
>> Date: Fri, 07 Aug 2015 17:13:25 -0600
>> From: EBo
>> Reply-To: EMC developers
>> To: emc-developers@lists.sourceforge.net
>> Subject: Re: [Emc-developers] research on optic
Am 08.08.2015 um 04:00 schrieb EBo:
> On Aug 7 2015 5:32 PM, Peter C. Wallace wrote:
>> On Fri, 7 Aug 2015, EBo wrote:
>>
>>> Date: Fri, 07 Aug 2015 17:13:25 -0600
>>> From: EBo
>>> Reply-To: EMC developers
>>> To: emc-developers@lists.sourcef
>>> Reply-To: EMC developers
> >>> To: emc-developers@lists.sourceforge.net
> >>> Subject: Re: [Emc-developers] research on optical encoders
> >>>
> >>> On Aug 7 2015 4:16 PM, andy pugh wrote:
> >>>> On 7 August 2015 at 12:23, EB
i, 07 Aug 2015 17:13:25 -0600
>> >>> From: EBo
>> >>> Reply-To: EMC developers
>> >>> To: emc-developers@lists.sourceforge.net
>> >>> Subject: Re: [Emc-developers] research on optical encoders
>> >>>
>> >>
t;> On Fri, 7 Aug 2015, EBo wrote:
>>>>>
>>>>>> Date: Fri, 07 Aug 2015 17:13:25 -0600
>>>>>> From: EBo
>>>>>> Reply-To: EMC developers
>>>>>> To: emc-developers@lists.sourceforge.net
>>>>>> Subject: R
>>> Am 08.08.2015 um 04:00 schrieb EBo:
> >>>> On Aug 7 2015 5:32 PM, Peter C. Wallace wrote:
> >>>>> On Fri, 7 Aug 2015, EBo wrote:
> >>>>>
> >>>>>> Date: Fri, 07 Aug 2015 17:13:25 -0600
> >>>>>> Fr
On Sat, 8 Aug 2015, Nicholas Mc Guire wrote:
> Date: Sat, 8 Aug 2015 10:02:00 +0200
> From: Nicholas Mc Guire
> Reply-To: EMC developers
> To: EMC developers
> Subject: Re: [Emc-developers] research on optical encoders
>
> On Sat, 08 Aug 2015, Julian WIngert wrote:
>
&
; >>> Am 08.08.2015 um 04:00 schrieb EBo:
>> >>>> On Aug 7 2015 5:32 PM, Peter C. Wallace wrote:
>> >>>>> On Fri, 7 Aug 2015, EBo wrote:
>> >>>>>
>> >>>>>> Date: Fri, 07 Aug 2015 17:13:25 -0600
>> >&g
>
> I think the trick the Resolute encoder uses is this: the image is captured in
> a perhaps sub microsecond flash of the LED, and then the "image" can be
> shifted out of the sensor at a leisurely rate. The specifications sort of
> suggests this (very fast capture (ns) time, but only multi KHz ma
I think you can get access to this sensors images directly. Does this
sensor allow you to download the images directly? I also could not find
the number of pixels are but I've read a guess of 30x30.
On Aug 8 2015 4:37 AM, Julian WIngert wrote:
> Reading the datasheet:
>
> http://datasheet.oct
As I wrote, frame capture is implemented.
Even accesible via USB of some mice...
On 9. August 2015 01:18:26 MESZ, EBo wrote:
>I think you can get access to this sensors images directly. Does this
>sensor allow you to download the images directly? I also could not
>find
>the number of pixels a
Do you have a list of mice, or one or two to start looking into, with
frame capture? I've only heard about this feature in hacked versions.
On Aug 8 2015 5:22 PM, Julian Wingert wrote:
> As I wrote, frame capture is implemented.
> Even accesible via USB of some mice...
>
> On 9. August 2015 01:1
On Sat, 08 Aug 2015, Peter C. Wallace wrote:
> >
> > I think the trick the Resolute encoder uses is this: the image is captured
> > in
> > a perhaps sub microsecond flash of the LED, and then the "image" can be
> > shifted out of the sensor at a leisurely rate. The specifications sort of
> > sugg
A median filter shall be a good start here
On 10. August 2015 08:40:02 MESZ, Nicholas Mc Guire wrote:
>On Sat, 08 Aug 2015, Peter C. Wallace wrote:
>
>> >
>> > I think the trick the Resolute encoder uses is this: the image is
>captured in
>> > a perhaps sub microsecond flash of the LED, and then
On Monday 10 August 2015 02:40:02 Nicholas Mc Guire wrote:
> On Sat, 08 Aug 2015, Peter C. Wallace wrote:
> > > I think the trick the Resolute encoder uses is this: the image is
> > > captured in a perhaps sub microsecond flash of the LED, and then
> > > the "image" can be shifted out of the senso
Since everything is in motion, how will this interact with the PID or
other timing loops? I wonder if that would be sufficient to filter out
the vibration.
On Aug 10 2015 1:04 AM, Julian Wingert wrote:
> A median filter shall be a good start here
>
> On 10. August 2015 08:40:02 MESZ, Nicholas M
On 10 August 2015 at 12:38, EBo wrote:
> Since everything is in motion, how will this interact with the PID or
> other timing loops? I wonder if that would be sufficient to filter out
> the vibration
I suspect that it would.
If not, then a DPLL (possibly with the accelleration matched to the
ma
On Mon, 10 Aug 2015, Nicholas Mc Guire wrote:
> Date: Mon, 10 Aug 2015 08:40:02 +0200
> From: Nicholas Mc Guire
> Reply-To: EMC developers
> To: EMC developers
> Subject: Re: [Emc-developers] research on optical encoders
>
> On Sat, 08 Aug 2015, Peter C. Wallace wrote:
28 matches
Mail list logo
