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

Stability observer #88

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
Open

Conversation

stefanscherzinger
Copy link
Contributor

@stefanscherzinger stefanscherzinger commented Sep 29, 2022

Motivation

The stability of the cartesian_force_controller and the cartesian_compliance_controller depends on the environment's stiffness and varies with each use case. While feeling natural and responsive in free motion, the robot's sensitivity normally is decreased in contact to remedy oscillations. Users thus often set the controller gains conservatively low for the worst case, i.e. loosing some of the possible sensitivity in free motion.

Approach

Frequency domain-based stability observers could automatically detect oscillations (before they become apparent to the user's eye and touch) and decrease the controller gains adequately. Here's a very promising approach that does this directly on the force-torque sensor signals. Let's see if we can integrate this into the cartesian_controllers.

Steps

  • Write a Python node that listens to the sensor topic
  • Perform FFT on a respective window and compute the stability indices from the paper
  • Check whether to increase the virtual model's end-effector mass (currently not exposed as dynamic parameter) or decrease the error_scale. Another alternative is increasing the joint damping. Or link_mass.
  • Test this on a real URe robot

@stefanscherzinger stefanscherzinger added enhancement New feature or request ROS1 labels Sep 29, 2022
@stefanscherzinger stefanscherzinger changed the title Stability observer: Reactivate after rebase Stability observer Nov 4, 2022
@stefanscherzinger stefanscherzinger changed the base branch from devel to master July 12, 2023 13:38
The first idea is to use a prototype implementation in Python with good
support for FFT computation in numpy.

We currently listen on force-torque sensor signals and test different
computations on the incoming data.
This makes sure that our FFT computations use the sensor rate that we
actually achieve with our performance.
Also clarify some variables.
That's now robust when the sensor values contain only zeros.
It's stable now for sensor callbacks with an arbitrary rate.
We need to drop the zero-frequency term.
According to the `numpy` documentation, the zero-frequency term is the
*sum of the signal*.  That's not what we want.
The range of frequencies and the amplitudes now look meaningful for test
data.
This is the latest state I was working on.
I remember that things were not as straight forward as expected and that
I questioned whether the paper's theory could actually work on my
system.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request ROS1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant