@@ -517,3 +517,34 @@ The maths-ey way to do this is to convert to cartesian coordinates, given the th
I guess doing this like that isn't too aweful, tho it's expensive. It would be awesome to have a faster method later on, but there probably better filters (like a kalman) make more sense than just a big ol' average.
I can imagine taking the measurement spreads: if any were larger than 20 ticks, I could sweep through that set and add the enc_count to the lo vals, then average. Or I could just do this for any reading < 31 ticks, as these are the small ones in *this particular window* but then I have that crawling window issue for measurements really ~ around 31 ticks. Might just be prettier to take a real circular average.
Here's the circular average:
```cpp
floatx=0.0F;
floaty=0.0F;
for(uint8_ts=0;s<CALIB_SAMPLE_PER_TICK;s++){
enc_as5047->trigger_read();
while(!enc_as5047->is_read_complete());// do this synchronously
floatreading=enc_as5047->get_reading();
x+=cos((reading/(float)(ENCODER_COUNTS))*2*PI);
y+=sin((reading/(float)(ENCODER_COUNTS))*2*PI);
// this is odd, I know, but it allows a new measurement to settle
// so we get a real average
delay(1);
}
// push reading, average removes the wraps added to readings.
I'm getting some strange intervals back, seems like the 'bad interval' is showing up in three chunks, though it should be one span of angles. I think the best way to debug this would be to plot the whole thing out... or I *could* try straight printing it all back on the serport... maybe I'll try that before building a whole packet-transmission-of-hella-floats thing.
Yeah this looks all kinds of wrong.
Borked, indeed. Will check tomorrow. Errors just before the BI (nan, so our of index somewhere?) and the BI looks close but not quite there.