Update resolution.h

[ubgk]

High resolution for position, velocity and torque

[stephane-caron]

What's the status of this update?

To me it makes full sense to ignore Q/D currents as we don't use them in motion control. Temperature would be nice to keep for monitoring purposes (e.g. when torque tracking drops, we can look at the temperature to determine whether it is because of thermal throttling).

[ubgk]

Sorry I forgot about this one amidst all other stuff.

It works in it's current state as expected, the number of bits stays constant after all. I will reenable the temperature and check again.

Do you think the voltage would be useful as well? Also, is it reasonable to assume everything is OK if the spine keeps running at 1KHz after the update?

[stephane-caron]

Voltage can be useful to indirectly observe the state of the battery, or to check for electrical failures. If we can it would be nice to keep it too.

Also, is it reasonable to assume everything is OK if the spine keeps running at 1KHz after the update?

Yes, I would look at the following plot:

foxplot([data.spine.clock.measured_period, data.spine.clock.slack], right=[data.spine.clock.skip_count])

If it keeps looking like this:

Then we're good to go.

[stephane-caron]

For example I'm trying to do the performance regression check right in https://github.com/tasts-robots/vulp/pull/62 :wink:

[coveralls]

Pull Request Test Coverage Report for Build 6561111907

• 5 of 5 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 87.885%

---

Totals
Change from base Build 6537279222:	0.0%
Covered Lines:	1654
Relevant Lines:	1882

---

💛 - Coveralls

[ubgk]

So this is what I get with a build using this PR. The timings seem unaffected except for the existing periodic slow downs every ~30 seconds.

I guess as my agent is still unchanged, it's normal that I have slow downs around the ~33 second mark, unlike in #62 right?

[stephane-caron]

LGTM :thumbsup:

The timings seem unaffected except for the existing periodic slow downs every ~30 seconds.

Are those always ~30 seconds apart? That would be good news somehow :laughing: We could investigate on the raspi what process fires up every 30 seconds that throws off the predictability of computation times.

Not saying that we should do it now though. We have no realtimeness issue currently.

[ubgk]

LGTM 👍

The timings seem unaffected except for the existing periodic slow downs every ~30 seconds.

Are those always ~30 seconds apart? That would be good news somehow 😆 We could investigate on the raspi what process fires up every 30 seconds that throws off the predictability of computation times.

Not saying that we should do it now though. We have no realtimeness issue currently.

Roughly, yes. Check out the plots below from late August (before we started playing with the resolution):

I don't have any logs old enough from Upkie v0, so I cannot check to confirm if it's vulp & upkie or something else on the Raspberry Pi.

[stephane-caron]

Interesting regularity :thinking:

[stephane-caron]

Thanks for the changes and checks :+1: