--- In bestinc@yahoogroups.com, "nicholas.seward" <nicholas.seward@...> wrote:
>
> --- In bestinc@yahoogroups.com, "tagrimley" <tgrimley@> wrote:
> >
> > A couple comments ...
> > I've not looked at your code but I want to comment about the use of floating
point numbers; you may have noticed that everything in the BEST library was
written using integers - that was not a random/evil choice :) First, the
floating point numbers are going to slow down the update process significantly.
Second, there are inherent resolution issues both in reading the stick position
(which I realize you're not doing) and in setting the servo position (which you
actually set by setting a pulse width).
> > As Joel pointed out with his example of the oscillating piano wire problem,
sometimes the fix to the control issue sits outside the controller (even though
it'd be better to eliminate the problem at the source).
> >
> > Terry
> >
> >
>
> Terry,
> I agree I shouldn't have used floating point numbers. The optimal solution
would probably be to use the full range of int to specify servo positions and
then convert it back to the 0-1023 range at the last minute. Although, you have
to agree my proof of concept would have been obfuscated if I had done a
processor friendly version. Since I didn't have means to debug and I was too
worried about accidental overflow I went with floating point numbers but even so
a better choice would have been to go with a long if I was afraid.
>
> I also agree with you that this is a little overkill. The main problem as I
see it is if you want to have the servo swing from one extreme to another over 2
seconds you would have to increment the servo_positon by 9 each tick. This
would not be nearly as smooth as incrementing by 1 each time but the tick
doesn't change often enough. I am liking the inner loop method without use of a
real time clock more and more.
I (Joel) wrote this typo a couple posts ago:
> "A ~90 degree servo swing for an input of 0-1000 is ~0.9 degree each"
Make that 0.09 degrees each, so moving a servo_position by 9 would be 1 degree
= 1/90th of full swing. These servos probably don't support more accuracy that
1 degree anyway. (Notice I'm now advocating the opposite position as I took
before.)
Regarding obfuscated code: IMHO, The redundancies in both the BEST lib and
Nicholas' code make it harder to read. One of the refactorings that makes my
code short is to move the in>out comparison to the inside.
Regarding teaching emphasis:
- Float emphasizes the concept, and allows for loop time variation.
- Otherwise we can assume, ie take as a constraint that limits other
methodologies, that loop time is short and mostly repeatable.
My next steps:
- The key in -this- programming exercise was to keep a new variable of current
output setting, independent of desired (input) setting.
- Next step is to control the desired settings other than directly from input.
I'm assuming this is what split-stick has to do. I'll want to look at it this
week, or my proto-bot won't have good control of its 7-9 outputs based on just 4
inputs.
- Once we can track time, and current/this/next states, we have the basis for
statemachines.
--Joel