Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare alternative (external) PID controller implementation #262

Closed
PeterBowman opened this issue Sep 19, 2022 · 4 comments
Closed

Prepare alternative (external) PID controller implementation #262

PeterBowman opened this issue Sep 19, 2022 · 4 comments
Assignees

Comments

@PeterBowman
Copy link
Member

I was wondering if moving the position/velocity control loops out of the embedded iPOS firmware would be both possible and beneficial, mostly in terms of things we cannot achieve today (i.e. impedance control and compliance). It is my guess that the "slow" iPOS control loops, i.e. 0.5-1 ms, are probably fast enough for our needs. For this new implementation, I am considering a 5 ms comms/control loop basing on available CAN bandwidth. Torque/current control shall remain handled by the embedded "fast" loop (0.05-0.1 ms).

Related issues:

New interface implementations are expected for:

Additional tools should be developed for obtaining friction and PID parameters. If done right, perhaps the simulator could yield similar results in case testing on the real joints renders difficult.

@PeterBowman
Copy link
Member Author

I am introducing a buffer class for storing high-frequency commands. This will be an intermediate layer between the commands sent to the robot through the YARP network ("slow" pace) and the commands sent to the iPOS via CAN bus ("fast" pace), using linear interpolation to ensure certain degree of smoothness (cf. #254). In the embedded PID implementation, this need not to pose any difference as users may still adjust the sender's period to the internal preconfigured --syncPeriod, which will bypass any interpolation and buffering. In the external PID implementation, though, control loops are always expected to run fast according to the selected --syncPeriod, while incoming commands need not to stick to it, and will commonly arrive at a slower rate. Said rate doesn't need any preconfiguration and, though not recommended, may vary. The buffer helps therefore to decouple the strictly regular CAN transmit rate imposed by --syncPeriod from any external source of command targets arriving at a (usually) different pace.

@PeterBowman
Copy link
Member Author

I am introducing a buffer class for storing high-frequency commands.

Implemented and backported to master at 3a8f15b, also documented at roboticslab-uc3m/teo-developer-manual@8e31a11.

@PeterBowman
Copy link
Member Author

PeterBowman commented Jan 13, 2023

Done at f5009c6. A few thing I'd like to check next:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

1 participant