OK, I am satisfied with these for the time being, time now is to apply it to a real system. I have also a few things I want to know:
OK, I am satisfied with these for the time being, time now is to apply it to a real system. I have also a few things I want to know:
...
@@ -1352,4 +1354,17 @@ So, then, next is having target set-points that are not directly related to the
...
@@ -1352,4 +1354,17 @@ So, then, next is having target set-points that are not directly related to the
So! There must be an established way to do this...
So! There must be an established way to do this...
- wrap around 360, test with 'targ 360' key
- wrap around 360, test with 'targ 360' key
- supervisor for offsets / etc ?
- supervisor for offsets / etc ?
\ No newline at end of file
Wondering if this is going to get tricky.
- derivative should also 'wrap' - otherwise there will be a spike between 0.0 and 360.0.
Competing approaches would be
- wrap around 360 in the subsystem, supervisor points to angles around 360
- or, count angle and *revolutions (integer, 32bit)* and track current-pos of these... translate between floating point *target* pos and *revs + angle* with units per step scalar
I think the second manner is actually best, so I'm giving that a shot. First step I take is to translate from rotary measurements -> linear / unrolled-rotary position, wrapping around & incrementing a 'revolutions' count, then I calculate 'real position' with revs * angular_pos.
Just taking a minute to figure out the particulars on this one... `a r i t h m e t i c`