Sebastian Kuzminsky wrote:
> That's the right file. It's in the
> hm2_encoder_instance_process_tram_read() function. That function gets
> run for each encoder channel, every time through the servo loop. The
> comment on line 832 introduces the fix to the "velocity spike when
> reversing dire
The document looks useful to me. please feel free to add it on master.
Jeff
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S.
On 11/01/2010 09:54 PM, Jon Elson wrote:
> Chris Radek wrote:
>>I think Seb started with that code and improved it
>> to get the good results we have from hostmot2 now. You might want to
>> browse the git history to see what he did?
>>
>> The changes 84e73cbd534 and especially fed9d8e5a58 look
Peter C. Wallace wrote:
> Sure, ultimately you want to test with real world signals but when debugging
> its good to reduce the number of variables or at least have good control of
> them...
>
I added a number of internal variables to the exported pins so I could
Halscope them,
this made deci
Chris Radek wrote:
> On Mon, Nov 01, 2010 at 12:13:36AM -0500, Jon Elson wrote:
>
>
>> One quirk, which I think is inherent in the way that HAL component
>> encoder.c works,
>> and which I copied,
>> is that a dithering encoder gets the wrong velocity.
>>
>
> When Seb K was working on th
On Mon, 1 Nov 2010, Jon Elson wrote:
> Date: Mon, 01 Nov 2010 11:18:06 -0500
> From: Jon Elson
> Reply-To: EMC developers
> To: EMC developers
> Subject: Re: [Emc-developers] pid with derivative inputs
>
> Peter C. Wallace wrote:
>>
>>
>> One good sa
On Mon, Nov 01, 2010 at 12:13:36AM -0500, Jon Elson wrote:
> One quirk, which I think is inherent in the way that HAL component
> encoder.c works,
> and which I copied,
> is that a dithering encoder gets the wrong velocity.
When Seb K was working on the hostmot2 driver, one of the kinds of
wro
Peter C. Wallace wrote:
>
>
> One good sanity check on the velocity output is to setup your hardware step
> generator for quadrature mode and set a constant velocity but randomly
> changing directions(and ~infinite acceleration). Another good test is just a
> slow velocity ramp. The advantage is
Andy Pugh wrote:
> This sounds like a problem related to the one I am having with my
> resolver converter, and one possible solution would be a tracking
> filter (
There was a chip made by ST, the L290, a quadrature to voltage converter.
It decoded the quadrature into + and - moves, and then had tw
On Mon, 1 Nov 2010, Jon Elson wrote:
> Date: Mon, 01 Nov 2010 00:13:36 -0500
> From: Jon Elson
> Reply-To: EMC developers
> To: EMC developers
> Subject: Re: [Emc-developers] pid with derivative inputs
>
> Well, after an AMAZING amount of fooling around with barely
On 1 November 2010 05:13, Jon Elson wrote:
> One quirk, which I think is inherent in the way that HAL component
> encoder.c works,
> and which I copied,
> is that a dithering encoder gets the wrong velocity. The first count of
> the dither gets
> the right velocity, as there was no movement for
Well, after an AMAZING amount of fooling around with barely one page of
code, I finally
have MOST of the velocity estimation working in the ppmc driver. I'm
still not sure it is right, though.
One quirk, which I think is inherent in the way that HAL component
encoder.c works,
and which I copie
OOps, sorry,
I found it. I had disabled the if-true part of code, but the else was still
getting executed and zeroing out the value!
Jon
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Cr
Well, before I can do anything with velocity estimation, I need to just
get the
scaled velocity pin exported. I added a couple more elements to the encoder
structure :
hal_float_t *vel; /* output: scaled velocity */
hal_float_t min_speed;/* parameter: min speed for velocit
Chris Radek wrote:
> However I think you might find it faster by staring at the code
> you've added. Look closely wherever you dereference a pointer to
> make sure that the pointer points where you think. Remember that
> array[...] is also a pointer dereference.
>
I commented out all changed s
On 30 October 2010 15:48, Chris Radek wrote:
>> Default Trap Handler: vector 14: Suspend RT task dfab4800
A *pointer in the headers that is used without a kmalloc, hal_malloc
or the ppmc equivalent of tram_register?
DAMHIK
--
atp
--
On Sat, Oct 30, 2010 at 12:32:50AM -0500, Jon Elson wrote:
> Jeff Epler wrote:
> > On Tue, Oct 26, 2010 at 08:29:52PM -0500, Jon Elson wrote:
> >
> >> I wonder if we could get this committed to the development head?
> >>
> >
> > This is now availble in the "master" branch for all to enjoy.
Jeff Epler wrote:
> On Tue, Oct 26, 2010 at 08:29:52PM -0500, Jon Elson wrote:
>
>> I wonder if we could get this committed to the development head?
>>
>
> This is now availble in the "master" branch for all to enjoy.
>
I've been working on putting the velocity estimation into my hal_ppm
On 27 October 2010 06:34, Jon Elson wrote:
> I may have to look at the hostmot2 code to see how
> they do it there.
I made a patch to add velocity to the Motenc driver, but there is no
timestamping there so it is just as brain-dead as the one built-in to
PID.
(Also the patch has never been tri
> Jeff Epler wrote:
>
> what you don't see in the picture is the difference in the noise.
> Without the improved velocity estimate, there's a sickly hum or honk
> coming from some part of the machine resonating
Why not post some sound clips?
Jeff Epler wrote:
>>>
> On Tue, Oct 26, 2010 at 08:29:52PM -0500, Jon Elson wrote:
>
> Actually, the modified pid is intended to be entirely compatible with
> the original pid without any ini/hal changes. The way I accomplish this
> is a little bit gross (it treads on a hal implementatio
Jeff Epler wrote:
>
> what you don't see in the picture is the difference in the noise.
> Without the improved velocity estimate, there's a sickly hum or honk
> coming from some part of the machine resonating
Yes, the Y axis of my minimill has a Japan Servo disc motor, and it
produces a
very annoy
> > http://emergent.unpy.net/files/sandbox/pid-trad.png
> > http://emergent.unpy.net/files/sandbox/pid-bettervel.png
> > (green/cyan trace: cmd, fb; purple trace: feedback-deriv from encoder
> > based on timestamps; tan trace: pid error; scales all the same as before)
> >
> > Note that with
I tried this on my little circuit board milling machine and it can make
a difference there as well.
I retuned with the hostmot2 high-quality velocity estimate, and then ran
with and without it. The new tuning parameters I ended up with were
Component Pins:
Owner Type Dir Value
Jeff Epler wrote:
> It's been mentioned many times, most recently by Jon Elson, that it
> would be nice if pid could take a better velocity estimate than the one
> it gets by performing a two-point numeric differentiation of the error
> term.
>
> I got around to implementing this and testing it ver
There are actually two patches required.
http://emergent.unpy.net/files/sandbox/0001-pid-read-command-feedback-only-once.patch
http://emergent.unpy.net/files/sandbox/0002-pid-accept-external-command-deriv-feedback-deriv.patch
pid-read-command-feedback-only-once should be applied first.
Jeff
It's been mentioned many times, most recently by Jon Elson, that it
would be nice if pid could take a better velocity estimate than the one
it gets by performing a two-point numeric differentiation of the error
term.
I got around to implementing this and testing it very lightly on
servo-sim. It l
27 matches
Mail list logo
