franky-control 1.1.0__cp313-cp313-manylinux_2_28_x86_64.whl → 1.1.2__cp313-cp313-manylinux_2_28_x86_64.whl

{franky_control-1.1.0.dist-info → franky_control-1.1.2.dist-info}/METADATA

@@ -1,12 +1,12 @@
 Metadata-Version: 2.4
 Name: franky-control
-Version: 1.1.0
+Version: 1.1.2
 Summary: High-level control library for Franka robots.
 Home-page: https://github.com/TimSchneider42/franky
 Author: Tim Schneider
 Author-email: tim@robot-learning.de
 License: LGPL-3.0-or-later
-Keywords: robot,robotics,trajectory-generation,motion-control
+Keywords: control,robotics,franka,franka-panda,franka-research-3
 Classifier: Development Status :: 4 - Beta
 Classifier: Intended Audience :: Science/Research
 Classifier: Topic :: Scientific/Engineering
@@ -56,17 +56,17 @@ Dynamic: summary
   </a>
 </p>
 
-Franky is a high-level control library for Franka robots offering Python and C++ support.
-By providing a high-level control interface, Franky eliminates the need for strict real-time programming at 1 kHz,
+franky is a high-level control library for Franka robots, offering Python and C++ support.
+By providing a high-level control interface, franky eliminates the need for strict real-time programming at 1 kHz,
 making control from non-real-time environments, such as Python programs, feasible.
-Instead of relying on low-level control commands, Franky expects high-level position or velocity targets and
+Instead of relying on low-level control commands, franky expects high-level position or velocity targets and
 uses [Ruckig](https://github.com/pantor/ruckig) to plan time-optimal trajectories in real-time.
 
-Although Python does not provide real-time guarantees, Franky strives to maintain as much real-time control as possible.
-Motions can be preempted at any moment, prompting Franky to re-plan trajectories on the fly.
-To handle unforeseen situations—such as unexpected contact with the environment — Franky includes a reaction system that
-allows to update motion commands dynamically.
-Furthermore, most non-real-time functionality of [libfranka](https://frankaemika.github.io/docs/libfranka.html), such as
+Although Python does not provide real-time guarantees, franky strives to maintain as much real-time control as possible.
+Motions can be preempted at any moment, prompting franky to re-plan trajectories on the fly.
+To handle unforeseen situations—such as unexpected contact with the environment — franky includes a reaction system that
+allows for updating motion commands dynamically.
+Furthermore, most non-real-time functionality of [libfranka](https://frankarobotics.github.io/docs/libfranka.html), such as
 Gripper control is made directly available in Python.
 
 Check out the [tutorial](#-tutorial) and the [examples](https://github.com/TimSchneider42/franky/tree/master/examples)
@@ -80,13 +80,13 @@ at [https://timschneider42.github.io/franky/](https://timschneider42.github.io/f
   No more endless hours setting up ROS, juggling packages, or untangling dependencies. Just `pip install` — no ROS at all.
 
 - **[Four control modes](#motion-types)**: [Cartesian position](#cartesian-position-control), [Cartesian velocity](#cartesian-velocity-control), [Joint position](#joint-position-control), [Joint velocity](#joint-velocity-control)
-  Franky uses [Ruckig](https://github.com/pantor/ruckig) to generate smooth, time-optimal trajectories while respecting velocity, acceleration, and jerk limits.
+  franky uses [Ruckig](https://github.com/pantor/ruckig) to generate smooth, time-optimal trajectories while respecting velocity, acceleration, and jerk limits.
 
 - **[Real-time control from Python and C++](#real-time-motions)**
-  Need to change the target while the robot’s moving? No problem. Franky re-plans trajectories on the fly so that you can preempt motions anytime.
+  Need to change the target while the robot’s moving? No problem. franky replans trajectories on the fly so that you can preempt motions anytime.
 
 - **[Reactive behavior](#-real-time-reactions)**
-  Robots don’t always go according to plan. Franky lets you define reactions to unexpected events—like contact with the environment — so you can change course in real-time.
+  Robots don’t always go according to plan. franky lets you define reactions to unexpected events—like contact with the environment — so you can change course in real-time.
 
 - **[Motion and reaction callbacks](#motion-callbacks)**
   Want to monitor what’s happening under the hood? Add callbacks to your motions and reactions. They won’t block the control thread and are super handy for debugging or logging.
@@ -95,24 +95,25 @@ at [https://timschneider42.github.io/franky/](https://timschneider42.github.io/f
   Adjust max velocity, acceleration, and jerk to match your setup or task. Fine control for smooth, safe operation.
 
 - **Full Python access to the libfranka API**
-  Want to tweak impedance, read the robot state, set force thresholds, or mess with the Jacobian? Go for it. If libfranka supports it, chances are Franky does, too.
+  Want to tweak impedance, read the robot state, set force thresholds, or mess with the Jacobian? Go for it. If libfranka supports it, chances are franky does, too.
 
 ## 📖 Python Quickstart Guide
 
-Real-time kernel already installed and real-time permissions granted? Just install Franky via
+Real-time kernel already installed and real-time permissions granted? Just install franky via
 
 ```bash
 pip install franky-control
 ```
 
-otherwise, follow the [setup instructions](#setup) first.
+Otherwise, follow the [setup instructions](#setup) first.
 
 Now we are already ready to go!
 Unlock the brakes in the web interface, activate FCI, and start coding:
+
 ```python
 from franky import *
 
-robot = Robot("172.16.0.2")  # Replace this with your robot's IP
+robot = Robot("10.90.90.1")  # Replace this with your robot's IP
 
 # Let's start slow (this lets the robot use a maximum of 5% of its velocity, acceleration, and jerk limits)
 robot.relative_dynamics_factor = 0.05
@@ -126,20 +127,20 @@ If you are seeing server version mismatch errors, such as
 ```
 franky.IncompatibleVersionException: libfranka: Incompatible library version (server version: 5, library version: 9)
 ```
-then your Franka robot is either not on the most recent firmware version or you are using the older Franka Panda model.
-In any case, it's no big deal; just check [here](https://frankaemika.github.io/docs/compatibility.html) which libfranka version you need and follow our [instructions](installing-frankly) to install the appropriate Franky wheels.
+then your Franka robot is either not on the most recent firmware version, or you are using the older Franka Panda model.
+In any case, it's no big deal; just check [here](https://frankarobotics.github.io/docs/compatibility.html) which libfranka version you need and follow our [instructions](installing-franky) to install the appropriate franky wheels.
 
 ## <a id="setup" /> ⚙️ Setup
 
-To install Franky, you have to follow three steps:
+To install franky, you have to follow three steps:
 
-1. Ensure that you are using a realtime kernel
+1. Ensure that you are using a real-time kernel
 2. Ensure that the executing user has permission to run real-time applications
-3. Install Franky via pip or build it from source
+3. Install franky via pip or build it from source
 
 ### Installing a real-time kernel
 
-In order for Franky to function properly, it requires the underlying OS to use a realtime kernel.
+In order for Franky to function properly, it requires the underlying OS to use a real-time kernel.
 Otherwise, you might see `communication_constrains_violation` errors.
 
 To check whether your system is currently using a real-time kernel, type `uname -a`.
@@ -154,12 +155,12 @@ If it does not say PREEMPT_RT, you are not currently running a real-time kernel.
 
 There are multiple ways of installing a real-time kernel.
 You
-can [build it from source](https://frankaemika.github.io/docs/installation_linux.html#setting-up-the-real-time-kernel)
+can [build it from source](https://frankarobotics.github.io/docs/installation_linux.html#setting-up-the-real-time-kernel)
 or, if you are using Ubuntu, it can be [enabled through Ubuntu Pro](https://ubuntu.com/real-time).
 
 ### Allowing the executing user to run real-time applications
 
-First, create a group `realtime` and add your user (or whoever is running Franky) to this group:
+First, create a group `realtime` and add your user (or whoever is running franky) to this group:
 
 ```bash
 sudo addgroup realtime
@@ -186,18 +187,18 @@ $ groups
 ... realtime
 ```
 
-If realtime is not listed in your groups, try rebooting.
+If real-time is not listed in your groups, try rebooting.
 
-### Installing Franky
+### Installing franky
 
-To start using Franky with Python and libfranka *0.15.0*, just install it via
+To start using franky with Python and libfranka *0.16.0*, just install it via
 
 ```bash
 pip install franky-control
 ```
 
 We also provide wheels for libfranka versions *0.7.1*, *0.8.0*, *0.9.2*, *0.10.0*, *0.11.0*, *0.12.1*, *0.13.3*,
-*0.14.2*, and *0.15.0*.
+*0.14.2*, *0.15.3*, and *0.16.0*.
 They can be installed via
 
 ```bash
@@ -208,39 +209,9 @@ pip install numpy
 pip install --no-index --find-links=./dist franky-control
 ```
 
-Franky is based on [libfranka](https://github.com/frankaemika/libfranka), [Eigen](https://eigen.tuxfamily.org) for
-transformation calculations and [pybind11](https://github.com/pybind/pybind11) for the Python bindings.
-As the Franka is sensitive to acceleration discontinuities, it requires jerk-constrained motion generation, for which
-Franky uses the [Ruckig](https://ruckig.com) community version for Online Trajectory Generation (OTG).
-
-After installing the dependencies (the exact versions can be found [here](#-development)), you can build and install
-Franky via
-
-```bash
-git clone --recurse-submodules git@github.com:timschneider42/franky.git
-cd franky
-mkdir -p build
-cd build
-cmake -DCMAKE_BUILD_TYPE=Release ..
-make
-make install
-```
-
-To use Franky, you can also include it as a subproject in your parent CMake via `add_subdirectory(franky)` and then
-`target_link_libraries(<target> franky)`.
-
-If you need only the Python module, you can install Franky via
+### Using Docker
 
-```bash
-pip install .
-```
-
-Make sure that the built library `_franky.cpython-3**-****-linux-gnu.so` is in the Python path, e.g. by adjusting
-`PYTHONPATH` accordingly.
-
-#### Using Docker
-
-To use Franky within Docker we provide a [Dockerfile](docker/run/Dockerfile) and
+To use franky within Docker we provide a [Dockerfile](docker/run/Dockerfile) and
 accompanying [docker-compose](docker-compose.yml) file.
 
 ```bash
@@ -249,7 +220,7 @@ cd franky/
 docker compose build franky-run
 ```
 
-To use another version of libfranka than the default (0.15.0) add a build argument:
+To use another version of libfranka than the default (0.16.0), add a build argument:
 
 ```bash
 docker compose build franky-run --build-arg LIBFRANKA_VERSION=0.9.2
@@ -261,25 +232,15 @@ To run the container:
 docker compose run franky-run bash
 ```
 
-The container requires access to the host machines network *and* elevated user rights to allow the docker user to set RT
+The container requires access to the host machine's network *and* elevated user rights to allow the Docker user to set RT
 capabilities of the processes run from within it.
 
-#### Building Franky with Docker
-
-For building Franky and its wheels, we provide another Docker container that can also be launched using docker-compose:
-
-```bash
-docker compose build franky-build
-docker compose run --rm franky-build run-tests  # To run the tests
-docker compose run --rm franky-build build-wheels  # To build wheels for all supported python versions
-```
-
-### Can I use CUDA jointly with Franky?
+### Can I use CUDA jointly with franky?
 
 Yes. However, you need to set `IGNORE_PREEMPT_RT_PRESENCE=1` during the installation and all subsequent updates of the CUDA drivers on the real-time kernel.
 
 First, make sure that you have rebooted your system after installing the real-time kernel.
-Then, add `IGNORE_PREEMPT_RT_PRESENCE=1` to `/etc/environment`, call `export IGNORE_PREEMPT_RT_PRESENCE=1` to also set it in the current session and follow the instructions of Nvidia to install CUDA on your system.
+Then, add `IGNORE_PREEMPT_RT_PRESENCE=1` to `/etc/environment`, call `export IGNORE_PREEMPT_RT_PRESENCE=1` to also set it in the current session, and follow the instructions of Nvidia to install CUDA on your system.
 
 If you are on Ubuntu, you can also use [this](tools/install_cuda_realtime.bash) script to install CUDA on your real-time system:
 ```bash
@@ -300,9 +261,51 @@ Alternatively, if you are a cowboy and do not care about security, you can also
 bash <(wget -qO- https://raw.githubusercontent.com/timschneider42/franky/master/tools/install_cuda_realtime.bash)
 ```
 
+### Building franky
+
+franky is based on [libfranka](https://github.com/frankarobotics/libfranka), [Eigen](https://eigen.tuxfamily.org) for
+transformation calculations and [pybind11](https://github.com/pybind/pybind11) for the Python bindings.
+As the Franka is sensitive to acceleration discontinuities, it requires jerk-constrained motion generation, for which
+franky uses the [Ruckig](https://ruckig.com) community version for Online Trajectory Generation (OTG).
+
+After installing the dependencies (the exact versions can be found [here](#-development)), you can build and install
+franky via
+
+```bash
+git clone --recurse-submodules git@github.com:timschneider42/franky.git
+cd franky
+mkdir -p build
+cd build
+cmake -DCMAKE_BUILD_TYPE=Release ..
+make
+make install
+```
+
+To use franky, you can also include it as a subproject in your parent CMake via `add_subdirectory(franky)` and then
+`target_link_libraries(<target> franky)`.
+
+If you need only the Python module, you can install franky via
+
+```bash
+pip install .
+```
+
+Make sure that the built library `_franky.cpython-3**-****-linux-gnu.so` is in the Python path, e.g. by adjusting
+`PYTHONPATH` accordingly.
+
+#### Building franky with Docker
+
+For building franky and its wheels, we provide another Docker container that can also be launched using docker-compose:
+
+```bash
+docker compose build franky-build
+docker compose run --rm franky-build run-tests  # To run the tests
+docker compose run --rm franky-build build-wheels  # To build wheels for all supported python versions
+```
+
 ## 📚 Tutorial
 
-Franky comes with both a C++ and Python API that differ only regarding real-time capability.
+franky comes with both a C++ and Python API that differ only regarding real-time capability.
 We will introduce both languages next to each other.
 In your C++ project, just include `include <franky.hpp>` and link the library.
 For Python, just `import franky`.
@@ -313,7 +316,7 @@ As a first example, only four lines of code are needed for simple robotic motion
 using namespace franky;
 
 // Connect to the robot with the FCI IP address
-Robot robot("172.16.0.2");
+Robot robot("10.90.90.1");
 
 // Reduce velocity and acceleration of the robot
 robot.setRelativeDynamicsFactor(0.05);
@@ -330,7 +333,7 @@ The corresponding program in Python is
 ```python
 from franky import Affine, CartesianMotion, Robot, ReferenceType
 
-robot = Robot("172.16.0.2")
+robot = Robot("10.90.90.1")
 robot.relative_dynamics_factor = 0.05
 
 motion = CartesianMotion(Affine([0.2, 0.0, 0.0]), ReferenceType.Relative)
@@ -340,7 +343,7 @@ robot.move(motion)
 Before executing any code, make sure that you have enabled the Franka Control Interface (FCI) in the Franka UI web interface.
 
 Furthermore, we will introduce methods for geometric calculations, for moving the robot according to different motion
-types, how to implement real-time reactions and changing waypoints in real time as well as controlling the gripper.
+types, how to implement real-time reactions and changing waypoints in real time, as well as controlling the gripper.
 
 ### 🧮 Geometry
 
@@ -365,24 +368,26 @@ In all cases, distances are in [m] and rotations in [rad].
 
 ### 🤖 Robot
 
-Franky exposes most of the libfanka API for Python.
-Moreover, we added methods to adapt the dynamics limits of the robot for all motions.
+franky exposes most of the libfanka API for Python.
+Moreover, we added methods to adapt the dynamic limits of the robot for all motions.
 
 ```python
 from franky import *
 
-robot = Robot("172.16.0.2")
+robot = Robot("10.90.90.1")
 
 # Recover from errors
 robot.recover_from_errors()
 
-# Set velocity, acceleration and jerk to 5% of the maximum
+# Set velocity, acceleration, and jerk to 5% of the maximum
 robot.relative_dynamics_factor = 0.05
 
 # Alternatively, you can define each constraint individually
-robot.relative_dynamics_factor = RelativeDynamicsFactor(velocity=0.1, acceleration=0.05, jerk=0.1)
+robot.relative_dynamics_factor = RelativeDynamicsFactor(
+    velocity=0.1, acceleration=0.05, jerk=0.1
+)
 
-# Or, for more finegrained access, set individual limits
+# Or, for more fine-grained access, set individual limits
 robot.translation_velocity_limit.set(3.0)
 robot.rotation_velocity_limit.set(2.5)
 robot.elbow_velocity_limit.set(2.62)
@@ -406,21 +411,21 @@ print(robot.joint_jerk_limit.max)
 The robot state can be retrieved by accessing the following properties:
 
 * `state`: Object of type `franky.RobotState`, which extends the
-  libfranka [franka::RobotState](https://frankaemika.github.io/libfranka/structfranka_1_1RobotState.html) structure by
+  libfranka [franka::RobotState](https://frankarobotics.github.io/libfranka/0.15.3/structfranka_1_1RobotState.html) structure by
   additional state elements.
 * `current_cartesian_state`: Object of type `franky.CartesianState`, which contains the end-effector pose and velocity
   obtained
-  from [franka::RobotState::O_T_EE](https://frankaemika.github.io/libfranka/structfranka_1_1RobotState.html#a193781d47722b32925e0ea7ac415f442)
-  and [franka::RobotState::O_dP_EE_c](https://frankaemika.github.io/libfranka/structfranka_1_1RobotState.html#a4be112bd1a9a7d777a67aea4a18a8dcc).
+  from [franka::RobotState::O_T_EE](https://frankarobotics.github.io/libfranka/0.15.3/structfranka_1_1RobotState.html#a193781d47722b32925e0ea7ac415f442)
+  and [franka::RobotState::O_dP_EE_c](https://frankarobotics.github.io/libfranka/0.15.3/structfranka_1_1RobotState.html#a4be112bd1a9a7d777a67aea4a18a8dcc).
 * `current_joint_state`: Object of type `franky.JointState`, which contains the joint positions and velocities
   obtained
-  from [franka::RobotState::q](https://frankaemika.github.io/libfranka/structfranka_1_1RobotState.html#ade3335d1ac2f6c44741a916d565f7091)
-  and [franka::RobotState::dq](https://frankaemika.github.io/libfranka/structfranka_1_1RobotState.html#a706045af1b176049e9e56df755325bd2).
+  from [franka::RobotState::q](https://frankarobotics.github.io/libfranka/0.15.3/structfranka_1_1RobotState.html#ade3335d1ac2f6c44741a916d565f7091)
+  and [franka::RobotState::dq](https://frankarobotics.github.io/libfranka/0.15.3/structfranka_1_1RobotState.html#a706045af1b176049e9e56df755325bd2).
 
 ```python
 from franky import *
 
-robot = Robot("172.16.0.2")
+robot = Robot("10.90.90.1")
 
 # Get the current state as `franky.RobotState`. See the documentation for a list of fields.
 state = robot.state
@@ -445,10 +450,11 @@ f_t_ee = Affine()
 ee_t_k = Affine()
 ee_pose_kin = robot.model.pose(Frame.EndEffector, q, f_t_ee, ee_t_k)
 
-# Get the jacobian of the current robot state
+# Get the Jacobian of the current robot state
 jacobian = robot.model.body_jacobian(Frame.EndEffector, state)
 
-# Alternatively, just get the URDF as string and do the kinematics computation yourself (only for libfranka >= 0.15.0)
+# Alternatively, just get the URDF as a string and do the kinematics computation yourself (only
+# for libfranka >= 0.15.0)
 urdf_model = robot.model_urdf
 ```
 
@@ -458,10 +464,10 @@ and [Model](https://timschneider42.github.io/franky/classfranky_1_1_model.html)
 
 ### <a id="motion-types" /> 🏃‍♂️ Motion Types
 
-Franky currently supports four different impedance control modes: **joint position control**, **joint velocity control**, **cartesian position control**, and **cartesian velocity control**.
+franky currently supports four different impedance control modes: **joint position control**, **joint velocity control**, **cartesian position control**, and **cartesian velocity control**.
 Each of these control modes is invoked by passing the robot an appropriate _Motion_ object.
 
-In the following, we provide a brief example for each motion type implemented by Franky in Python.
+In the following, we provide a brief example for each motion type implemented by franky in Python.
 The C++ interface is generally analogous, though some variable and method names are different because we
 follow [PEP 8](https://peps.python.org/pep-0008/) naming conventions in Python
 and [Google naming conventions](https://google.github.io/styleguide/cppguide.html) in C++.
@@ -476,28 +482,37 @@ from franky import *
 # A point-to-point motion in the joint space
 m_jp1 = JointMotion([-0.3, 0.1, 0.3, -1.4, 0.1, 1.8, 0.7])
 
-# A motion in joint space with multiple waypoints
-m_jp2 = JointWaypointMotion([
-    JointWaypoint([-0.3, 0.1, 0.3, -1.4, 0.1, 1.8, 0.7]),
-    JointWaypoint([0.0, 0.3, 0.3, -1.5, -0.2, 1.5, 0.8]),
-    JointWaypoint([0.1, 0.4, 0.3, -1.4, -0.3, 1.7, 0.9])
-])
-
-# Intermediate waypoints also permit to specify target velocities. The default target velocity is 0, meaning that the
-# robot will stop at every waypoint.
-m_jp3 = JointWaypointMotion([
-    JointWaypoint([-0.3, 0.1, 0.3, -1.4, 0.1, 1.8, 0.7]),
-    JointWaypoint(
-        JointState(
-            position=[0.0, 0.3, 0.3, -1.5, -0.2, 1.5, 0.8],
-            velocity=[0.1, 0.0, 0.0, 0.0, -0.0, 0.0, 0.0])),
-    JointWaypoint([0.1, 0.4, 0.3, -1.4, -0.3, 1.7, 0.9])
-])
-
-# Stop the robot in joint position control mode. The difference of JointStopMotion to other stop motions such as
-# CartesianStopMotion is that # JointStopMotion # stops the robot in joint position control mode while
-# CartesianStopMotion stops it in cartesian pose control mode. The difference becomes relevant when asynchronous move
-# commands are being sent or reactions are being used(see below).
+# A motion in joint space with multiple waypoints. The robot will stop at each of these
+# waypoints. If you want the robot to move continuously, you have to specify a target velocity
+# at every waypoint as shown in the example following this one.
+m_jp2 = JointWaypointMotion(
+    [
+        JointWaypoint([-0.3, 0.1, 0.3, -1.4, 0.1, 1.8, 0.7]),
+        JointWaypoint([0.0, 0.3, 0.3, -1.5, -0.2, 1.5, 0.8]),
+        JointWaypoint([0.1, 0.4, 0.3, -1.4, -0.3, 1.7, 0.9]),
+    ]
+)
+
+# Intermediate waypoints also permit specifying target velocities. The default target velocity
+# is 0, meaning that the robot will stop at every waypoint.
+m_jp3 = JointWaypointMotion(
+    [
+        JointWaypoint([-0.3, 0.1, 0.3, -1.4, 0.1, 1.8, 0.7]),
+        JointWaypoint(
+            JointState(
+                position=[0.0, 0.3, 0.3, -1.5, -0.2, 1.5, 0.8],
+                velocity=[0.1, 0.0, 0.0, 0.0, -0.0, 0.0, 0.0],
+            )
+        ),
+        JointWaypoint([0.1, 0.4, 0.3, -1.4, -0.3, 1.7, 0.9]),
+    ]
+)
+
+# Stop the robot in joint position control mode. The difference between JointStopMotion to other
+# stop-motions, such as CartesianStopMotion, is that JointStopMotion stops the robot in joint
+# position control mode while CartesianStopMotion stops it in cartesian pose control mode. The
+# difference becomes relevant when asynchronous move commands are being sent or reactions are
+# being used(see below).
 m_jp4 = JointStopMotion()
 ```
 
@@ -506,19 +521,31 @@ m_jp4 = JointStopMotion()
 ```python
 from franky import *
 
-# Accelerate to the given joint velocity and hold it. After 1000ms stop the robot again.
-m_jv1 = JointVelocityMotion([0.1, 0.3, -0.1, 0.0, 0.1, -0.2, 0.4], duration=Duration(1000))
-
-# Joint velocity motions also support waypoints. Unlike in joint position control, a joint velocity waypoint is a
-# target velocity to be reached. This particular example first accelerates the joints, holds the velocity for 1s, then
-# reverses direction for 2s, reverses direction again for 1s, and finally stops. It is important not to forget to stop
-# the robot at the end of such a sequence, as it will otherwise throw an error.
-m_jv2 = JointVelocityWaypointMotion([
-    JointVelocityWaypoint([0.1, 0.3, -0.1, 0.0, 0.1, -0.2, 0.4], hold_target_duration=Duration(1000)),
-    JointVelocityWaypoint([-0.1, -0.3, 0.1, -0.0, -0.1, 0.2, -0.4], hold_target_duration=Duration(2000)),
-    JointVelocityWaypoint([0.1, 0.3, -0.1, 0.0, 0.1, -0.2, 0.4], hold_target_duration=Duration(1000)),
-    JointVelocityWaypoint([0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]),
-])
+# Accelerate to the given joint velocity and hold it. After 1000ms, stop the robot again.
+m_jv1 = JointVelocityMotion(
+    [0.1, 0.3, -0.1, 0.0, 0.1, -0.2, 0.4], duration=Duration(1000)
+)
+
+# Joint velocity motions also support waypoints. Unlike in joint position control, a joint
+# velocity waypoint is a target velocity to be reached. This particular example first
+# accelerates the joints, holds the velocity for 1s, then reverses direction for 2s, reverses
+# direction again for 1s, and finally stops. It is important not to forget to stop the robot
+# at the end of such a sequence, as it will otherwise throw an error.
+m_jv2 = JointVelocityWaypointMotion(
+    [
+        JointVelocityWaypoint(
+            [0.1, 0.3, -0.1, 0.0, 0.1, -0.2, 0.4], hold_target_duration=Duration(1000)
+        ),
+        JointVelocityWaypoint(
+            [-0.1, -0.3, 0.1, -0.0, -0.1, 0.2, -0.4],
+            hold_target_duration=Duration(2000),
+        ),
+        JointVelocityWaypoint(
+            [0.1, 0.3, -0.1, 0.0, 0.1, -0.2, 0.4], hold_target_duration=Duration(1000)
+        ),
+        JointVelocityWaypoint([0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]),
+    ]
+)
 
 # Stop the robot in joint velocity control mode.
 m_jv3 = JointVelocityStopMotion()
@@ -536,31 +563,46 @@ quat = Rotation.from_euler("xyz", [0, 0, math.pi / 2]).as_quat()
 m_cp1 = CartesianMotion(Affine([0.4, -0.2, 0.3], quat))
 
 # With target elbow angle (otherwise, the Franka firmware will choose by itself)
-m_cp2 = CartesianMotion(RobotPose(Affine([0.4, -0.2, 0.3], quat), elbow_state=ElbowState(0.3)))
+m_cp2 = CartesianMotion(
+    RobotPose(Affine([0.4, -0.2, 0.3], quat), elbow_state=ElbowState(0.3))
+)
 
-# A linear motion in cartesian space relative to the initial position
-# (Note that this motion is relative both in position and orientation. Hence, when the robot's end-effector is oriented
-# differently, it will move in a different direction)
+# A linear motion in Cartesian space relative to the initial position
+# (Note that this motion is relative both in position and orientation. Hence, when the robot's
+# end-effector is oriented differently, it will move in a different direction)
 m_cp3 = CartesianMotion(Affine([0.2, 0.0, 0.0]), ReferenceType.Relative)
 
-# Generalization of CartesianMotion that allows for multiple waypoints
-m_cp4 = CartesianWaypointMotion([
-    CartesianWaypoint(RobotPose(Affine([0.4, -0.2, 0.3], quat), elbow_state=ElbowState(0.3))),
-    # The following waypoint is relative to the prior one and 50% slower
-    CartesianWaypoint(Affine([0.2, 0.0, 0.0]), ReferenceType.Relative, RelativeDynamicsFactor(0.5, 1.0, 1.0))
-])
-
-# Cartesian waypoints also permit to specify target velocities
-m_cp5 = CartesianWaypointMotion([
-    CartesianWaypoint(Affine([0.5, -0.2, 0.3], quat)),
-    CartesianWaypoint(
-        CartesianState(
-            pose=Affine([0.4, -0.1, 0.3], quat),
-            velocity=Twist([-0.01, 0.01, 0.0]))),
-    CartesianWaypoint(Affine([0.3, 0.0, 0.3], quat))
-])
-
-# Stop the robot in cartesian position control mode.
+# Generalization of CartesianMotion that allows for multiple waypoints. The robot will stop at
+# each of these waypoints. If you want the robot to move continuously, you have to specify a
+# target velocity at every waypoint as shown in the example following this one.
+m_cp4 = CartesianWaypointMotion(
+    [
+        CartesianWaypoint(
+            RobotPose(Affine([0.4, -0.2, 0.3], quat), elbow_state=ElbowState(0.3))
+        ),
+        # The following waypoint is relative to the prior one and 50% slower
+        CartesianWaypoint(
+            Affine([0.2, 0.0, 0.0]),
+            ReferenceType.Relative,
+            RelativeDynamicsFactor(0.5, 1.0, 1.0),
+        ),
+    ]
+)
+
+# Cartesian waypoints permit specifying target velocities
+m_cp5 = CartesianWaypointMotion(
+    [
+        CartesianWaypoint(Affine([0.5, -0.2, 0.3], quat)),
+        CartesianWaypoint(
+            CartesianState(
+                pose=Affine([0.4, -0.1, 0.3], quat), velocity=Twist([-0.01, 0.01, 0.0])
+            )
+        ),
+        CartesianWaypoint(Affine([0.3, 0.0, 0.3], quat)),
+    ]
+)
+
+# Stop the robot in Cartesian position control mode.
 m_cp6 = CartesianStopMotion()
 ```
 
@@ -569,42 +611,57 @@ m_cp6 = CartesianStopMotion()
 ```python
 from franky import *
 
-# A cartesian velocity motion with linear (first argument) and angular (second argument) components
+# A Cartesian velocity motion with linear (first argument) and angular (second argument)
+# components
 m_cv1 = CartesianVelocityMotion(Twist([0.2, -0.1, 0.1], [0.1, -0.1, 0.2]))
 
 # With target elbow velocity
-m_cv2 = CartesianVelocityMotion(RobotVelocity(Twist([0.2, -0.1, 0.1], [0.1, -0.1, 0.2]), elbow_velocity=-0.2))
-
-# Cartesian velocity motions also support multiple waypoints. Unlike in cartesian position control, a cartesian velocity
-# waypoint is a target velocity to be reached. This particular example first accelerates the end-effector, holds the
-# velocity for 1s, then # reverses direction for 2s, reverses direction again for 1s, and finally stops. It is important
-# not to forget to stop # the robot at the end of such a sequence, as it will otherwise throw an error.
-m_cv4 = CartesianVelocityWaypointMotion([
-    CartesianVelocityWaypoint(Twist([0.2, -0.1, 0.1], [0.1, -0.1, 0.2]), hold_target_duration=Duration(1000)),
-    CartesianVelocityWaypoint(Twist([-0.2, 0.1, -0.1], [-0.1, 0.1, -0.2]), hold_target_duration=Duration(2000)),
-    CartesianVelocityWaypoint(Twist([0.2, -0.1, 0.1], [0.1, -0.1, 0.2]), hold_target_duration=Duration(1000)),
-    CartesianVelocityWaypoint(Twist()),
-])
-
-# Stop the robot in cartesian velocity control mode.
+m_cv2 = CartesianVelocityMotion(
+    RobotVelocity(Twist([0.2, -0.1, 0.1], [0.1, -0.1, 0.2]), elbow_velocity=-0.2)
+)
+
+# Cartesian velocity motions also support multiple waypoints. Unlike in Cartesian position
+# control, a Cartesian velocity waypoint is a target velocity to be reached. This particular
+# example first accelerates the end-effector, holds the velocity for 1s, then reverses
+# direction for 2s, reverses direction again for 1s, and finally stops. It is important not to
+# forget to stop the robot at the end of such a sequence, as it will otherwise throw an error.
+m_cv4 = CartesianVelocityWaypointMotion(
+    [
+        CartesianVelocityWaypoint(
+            Twist([0.2, -0.1, 0.1], [0.1, -0.1, 0.2]),
+            hold_target_duration=Duration(1000),
+        ),
+        CartesianVelocityWaypoint(
+            Twist([-0.2, 0.1, -0.1], [-0.1, 0.1, -0.2]),
+            hold_target_duration=Duration(2000),
+        ),
+        CartesianVelocityWaypoint(
+            Twist([0.2, -0.1, 0.1], [0.1, -0.1, 0.2]),
+            hold_target_duration=Duration(1000),
+        ),
+        CartesianVelocityWaypoint(Twist()),
+    ]
+)
+
+# Stop the robot in Cartesian velocity control mode.
 m_cv6 = CartesianVelocityStopMotion()
 ```
 
 #### Relative Dynamics Factors
 
-Every motion and waypoint type allows to adapt the dynamics (velocity, acceleration and jerk) by setting the respective
+Every motion and waypoint type allows for adapting the dynamics (velocity, acceleration, and jerk) by setting the respective
 `relative_dynamics_factor` parameter.
-This parameter can also be set for the robot globally as shown below or in the `robot.move` command.
+This parameter can also be set for the robot globally, as shown below, or in the `robot.move` command.
 Crucially, relative dynamics factors on different layers (robot, move command, and motion) do not override each other
 but rather get multiplied.
 Hence, a relative dynamics factor on a motion can only reduce the dynamics of the robot and never increase them.
 
-There is one exception to this rule and that is if any layer sets the relative dynamics factor to
+There is one exception to this rule, and that is if any layer sets the relative dynamics factor to
 `RelativeDynamicsFactor.MAX_DYNAMICS`.
 This will cause the motion to be executed with maximum velocity, acceleration, and jerk limits, independently of the
 relative dynamics factors of the other layers.
-This feature should only be used to abruptly stop the robot in case of an unexpected environment contact as executing
-other motions with it is likely to lead to a discontinuity error and might be dangerous.
+This feature should only be used to abruptly stop the robot in case of an unexpected environment contact, as executing
+Other motions with it are likely to lead to a discontinuity error and might be dangerous.
 
 #### Executing Motions
 
@@ -613,14 +670,15 @@ The real robot can be moved by applying a motion to the robot using `move`:
 ```python
 # Before moving the robot, set an appropriate dynamics factor. We start small:
 robot.relative_dynamics_factor = 0.05
-# or alternatively, to control the scaling of velocity, acceleration, and jerk limits separately:
+# or alternatively, to control the scaling of velocity, acceleration, and jerk limits
+# separately:
 robot.relative_dynamics_factor = RelativeDynamicsFactor(0.05, 0.1, 0.15)
 # If these values are set too high, you will see discontinuity errors
 
 robot.move(m_jp1)
 
-# We can also set a relative dynamics factor in the move command. It will be multiplied with the other relative
-# dynamics factors (robot and motion if present).
+# We can also set a relative dynamics factor in the move command. It will be multiplied by
+# the other relative dynamics factors (robot and motion if present).
 robot.move(m_jp2, relative_dynamics_factor=0.8)
 ```
 
@@ -635,7 +693,8 @@ def cb(
         time_step: Duration,
         rel_time: Duration,
         abs_time: Duration,
-        control_signal: JointPositions):
+        control_signal: JointPositions,
+):
     print(f"At time {abs_time}, the target joint positions were {control_signal.q}")
 
 
@@ -645,7 +704,7 @@ robot.move(m_jp1)
 
 Note that in Python, these callbacks are not executed in the control thread since they would otherwise block it.
 Instead, they are put in a queue and executed by another thread.
-While this scheme ensures that the control thread can always run, it cannot prevent that the queue grows indefinitely
+While this scheme ensures that the control thread can always run, it cannot prevent the queue from growing indefinitely
 when the callbacks take more time to execute than it takes for new callbacks to be queued.
 Hence, callbacks might be executed significantly after they were queued if they take a long time to execute.
 
@@ -660,12 +719,13 @@ from franky import CartesianMotion, Affine, ReferenceType, Measure, Reaction
 
 motion = CartesianMotion(Affine([0.0, 0.0, 0.1]), ReferenceType.Relative)  # Move down 10cm
 
-# It is important that the reaction motion uses the same control mode as the original motion. Hence, we cannot register
-# a JointMotion as a reaction motion to a CartesianMotion.
-reaction_motion = CartesianMotion(Affine([0.0, 0.0, 0.01]), ReferenceType.Relative)  # Move up for 1cm
+# It is important that the reaction motion uses the same control mode as the original motion.
+# Hence, we cannot register a JointMotion as a reaction motion to a CartesianMotion.
+# Move up by 1cm
+reaction_motion = CartesianMotion(Affine([0.0, 0.0, -0.01]), ReferenceType.Relative)
 
 # Trigger reaction if the Z force is greater than 30N
-reaction = Reaction(Measure.FORCE_Z > 30.0, reaction_motion)
+reaction = Reaction(Measure.FORCE_Z > 5.0, reaction_motion)
 motion.add_reaction(reaction)
 
 robot.move(motion)
@@ -722,10 +782,11 @@ with lower priority to ensure that the control thread does not get blocked.
 Thus, the callbacks might fire substantially after the reaction has fired, depending on the time it takes to execute
 them.
 
-In C++ you can additionally use lambdas to define more complex behaviours:
+In C++, you can additionally use lambdas to define more complex behaviours:
 
 ```c++
-auto motion = CartesianMotion(RobotPose(Affine({0.0, 0.0, 0.2}), 0.0), ReferenceType::Relative);
+auto motion = CartesianMotion(
+  RobotPose(Affine({0.0, 0.0, 0.2}), 0.0), ReferenceType::Relative);
 
 // Stop motion if force is over 10N
 auto stop_motion = StopMotion<franka::CartesianPose>()
@@ -763,20 +824,20 @@ Instead, it returns immediately and, thus, allows the main thread to set new mot
 import time
 from franky import Affine, CartesianMotion, Robot, ReferenceType
 
-robot = Robot("172.16.0.2")
+robot = Robot("10.90.90.1")
 robot.relative_dynamics_factor = 0.05
 
 motion1 = CartesianMotion(Affine([0.2, 0.0, 0.0]), ReferenceType.Relative)
 robot.move(motion1, asynchronous=True)
 
 time.sleep(0.5)
-# Note that similar to reactions, when preempting active motions with new motions, the control mode cannot change.
-# Hence, we cannot use, e.g., a JointMotion here.
+# Note that, similar to reactions, when preempting active motions with new motions, the
+# control mode cannot change. Hence, we cannot use, e.g., a JointMotion here.
 motion2 = CartesianMotion(Affine([0.2, 0.0, 0.0]), ReferenceType.Relative)
 robot.move(motion2, asynchronous=True)
 ```
 
-By calling `Robot.join_motion` the main thread can be synchronized with the motion thread, as it will block until the
+By calling `Robot.join_motion`, the main thread can be synchronized with the motion thread, as it will block until the
 robot finishes its motion.
 
 ```python
@@ -785,21 +846,21 @@ robot.join_motion()
 
 Note that when exceptions occur during the asynchronous execution of a motion, they will not be thrown immediately.
 Instead, the control thread stores the exception and terminates.
-The next time `Robot.join_motion` or `Robot.move` are called, they will throw the stored exception in the main thread.
+The next time `Robot.join_motion` or `Robot.move` is called, they will throw the stored exception in the main thread.
 Hence, after an asynchronous motion has finished, make sure to call `Robot.join_motion` to ensure being notified of any
 exceptions that occurred during the motion.
 
 ### <a id="gripper" /> 👌  Gripper
 
 In the `franky::Gripper` class, the default gripper force and gripper speed can be set.
-Then, additionally to the libfranka commands, the following helper methods can be used:
+Then, in addition to the libfranka commands, the following helper methods can be used:
 
 ```c++
 #include <franky.hpp>
 #include <chrono>
 #include <future>
 
-auto gripper = franky::Gripper("172.16.0.2");
+auto gripper = franky::Gripper("10.90.90.1");
 
 double speed = 0.02; // [m/s]
 double force = 20.0; // [N]
@@ -830,12 +891,12 @@ if (!success_future.wait_for(std::chrono::seconds(1)) == std::future_status::rea
 }
 ```
 
-The Python API follows the c++ API closely:
+The Python API follows the C++ API closely:
 
 ```python
 import franky
 
-gripper = franky.Gripper("172.16.0.2")
+gripper = franky.Gripper("10.90.90.1")
 
 speed = 0.02  # [m/s]
 force = 20.0  # [N]
@@ -868,9 +929,9 @@ else:
 
 For Franka robots, control happens via the Franka Control Interface (FCI), which has to be enabled through the Franka UI in the robot's web interface.
 The Franka UI also provides methods for locking and unlocking the brakes, setting the execution mode, and executing the safety self-test.
-However, sometimes you may want to access these methods programmatically, e.g. for automatically unlocking the brakes before starting a motion, or automatically executing the self-test after 24h of continuous execution.
+However, sometimes you may want to access these methods programmatically, e.g., for automatically unlocking the brakes before starting a motion, or automatically executing the self-test after 24h of continuous execution.
 
-For that reason, Franky provides a `RobotWebSession` class that allows you to access the web interface API of the robot.
+For that reason, franky provides a `RobotWebSession` class that allows you to access the web interface API of the robot.
 Note that directly accessing the web interface API is not officially supported and documented by Franka.
 Hence, use this feature at your own risk.
 
@@ -879,18 +940,19 @@ A typical automated workflow could look like this:
 ```python
 import franky
 
-with franky.RobotWebSession("172.16.0.2", "username", "password") as robot_web_session:
+with franky.RobotWebSession("10.90.90.1", "username", "password") as robot_web_session:
     # First take control
     try:
-        # Try taking control. The session currently holding control has to release it in order for this session to gain
-        # control. In the web interface, a notification will show prompting the user to release control. If the other
-        # session is another franky.RobotWebSession, then the `release_control` method can be called on the other
+        # Try taking control. The session currently holding control has to release it in order
+        # for this session to gain control. In the web interface, a notification will show
+        # prompting the user to release control. If the other session is another
+        # franky.RobotWebSession, then the `release_control` method can be called on the other
         # session to release control.
         robot_web_session.take_control(wait_timeout=10.0)
     except franky.TakeControlTimeoutError:
-        # If nothing happens for 10s, we try to take control forcefully. This is particularly useful if the session
-        # holding control is dead. Taking control by force requires the user to manually push the blue button close to
-        # the robot's wrist.
+        # If nothing happens for 10s, we try to take control forcefully. This is particularly
+        # useful if the session holding control is dead. Taking control by force requires the
+        # user to manually push the blue button close to the robot's wrist.
         robot_web_session.take_control(wait_timeout=30.0, force=True)
 
     # Unlock the brakes
@@ -916,7 +978,7 @@ In case you are running the robot for longer than 24h you will have noticed that
 import time
 import franky
 
-with franky.RobotWebSession("172.16.0.2", "username", "password") as robot_web_session:
+with franky.RobotWebSession("10.90.90.1", "username", "password") as robot_web_session:
     # Execute self-test if the time until self-test is less than 5 minutes.
     if robot_web_session.get_system_status()["safety"]["timeToTd2"] < 300:
         robot_web_session.disable_fci()
@@ -940,9 +1002,9 @@ See [robot_web_session.py](franky/robot_web_session.py) for an example of how to
 
 ## 🛠️ Development
 
-Franky is currently tested against following versions
+franky is currently tested against the following versions
 
-- libfranka 0.7.1, 0.8.0, 0.9.2, 0.10.0, 0.11.0, 0.12.1, 0.13.3, 0.14.2, 0.15.0
+- libfranka 0.7.1, 0.8.0, 0.9.2, 0.10.0, 0.11.0, 0.12.1, 0.13.3, 0.14.2, 0.15.3, 0.16.0
 - Eigen 3.4.0
 - Pybind11 2.13.6
 - POCO 1.12.5p2
@@ -953,20 +1015,20 @@ Franky is currently tested against following versions
 ## 📜 License
 
 For non-commercial applications, this software is licensed under the LGPL v3.0.
-If you want to use Franky within commercial applications or under a different license, please contact us for individual
+If you want to use franky within commercial applications or under a different license, please contact us for individual
 agreements.
 
 ## 🔍 Differences to frankx
 
-Franky started originally as a fork of [frankx](https://github.com/pantor/frankx), though both codebase and
+franky started originally as a fork of [frankx](https://github.com/pantor/frankx), though both codebase and
 functionality differ substantially from frankx by now.
-Aside of bug fixes and general performance improvements, Franky provides the following new features/improvements:
+Aside from bug fixes and general performance improvements, franky provides the following new features/improvements:
 
 * [Motions can be updated asynchronously.](#-real-time-motions)
 * [Reactions allow for the registration of callbacks instead of just printing to stdout when fired.](#-real-time-reactions)
 * [Motions allow for the registration of callbacks for profiling.](#motion-callbacks)
 * [The robot state is also available during control.](#robot-state)
-* A larger part of the libfranka API is exposed to python (e.g.,`setCollisionBehavior`, `setJoinImpedance`, and
+* A larger part of the libfranka API is exposed to python (e.g., `setCollisionBehavior`, `setJoinImpedance`, and
   `setCartesianImpedance`).
 * Cartesian motion generation handles boundaries in Euler angles properly.
 * [There is a new joint motion type that supports waypoints.](#-motion-types)
@@ -977,7 +1039,7 @@ Aside of bug fixes and general performance improvements, Franky provides the fol
 * [The `Measure` class allows for arithmetic operations.](#-real-time-reactions)
 * Exceptions caused by libfranka are raised properly instead of being printed to stdout.
 * [We provide wheels for both Franka Research 3 and the older Franka Panda](#-setup)
-* Franky supports [joint velocity control](#joint-velocity-control)
+* franky supports [joint velocity control](#joint-velocity-control)
   and [cartesian velocity control](#cartesian-velocity-control)
 * The dynamics limits are not hard-coded anymore but can be [set for each robot instance](#-robot).
 
@@ -988,4 +1050,4 @@ Please run the [pre-commit](https://pre-commit.com/) hooks before submitting you
 To install the pre-commit hooks, run:
 
 1. [Install pre-commit](https://pre-commit.com/#install)
-2. Install the Git hooks by running `pre-commit install` or, alternatively, run `pre-commit run --all-files manually.
+2. Install the Git hooks by running `pre-commit install` or, alternatively, run `pre-commit run --all-files` manually.

{franky_control-1.1.0.dist-info → franky_control-1.1.2.dist-info}/RECORD

@@ -1,27 +1,27 @@
 franky/__init__.py,sha256=57BsmUytdeqMrhHglwvxMS6CgpAEVPw0KJge8_UTzEA,378
-franky/_franky.cpython-313-x86_64-linux-gnu.so,sha256=4qoW0TnW1ZptBHJ-IviE0nlotsqsHMCHvSNJUAxgU3U,3092313
+franky/_franky.cpython-313-x86_64-linux-gnu.so,sha256=bhLWBKG0iW3A3-HGuKvLVhw63TGz0xCTJmwKRLhnwIw,3092313
 franky/_franky.pyi,sha256=odBnBaM2qGN4mUa8WvFN5SL9aszPgDTsZj5Jb9UkFHk,60047
 franky/motion.py,sha256=TWsx2Ba9iYG9e-OxpuYZlVn1wdzKS-Zvz6ayHT_HYXQ,354
 franky/reaction.py,sha256=cBuHAMek9yH-9Zmwfa0dzz2t5G_1SQEWXNdW7mhhCI8,1519
 franky/robot.py,sha256=NaTNh4PaJshbz44eibvLCMt6O_Ak7TRVjhUR6AGay9A,236
 franky/robot_web_session.py,sha256=rYpnUe4b8xj5JjCYxNRZ0uYz8lL2qfxKglcImFDw24Y,9070
-franky_control.libs/libPocoFoundation-91a48101.so.95,sha256=ayW6qwws-4x4I7Ee3WK4LRRAyaQuTvbGuEBTkjZy7CU,3273833
-franky_control.libs/libPocoNet-9e586dc9.so.95,sha256=KQ6mL1nO9NlXzpp7NcBAKLxC9vjzNd_l9Jy8ldXlotU,2504833
+franky_control.libs/libPocoFoundation-55da614c.so.95,sha256=C9mBkna2m4LazUpeOgAp9-NRNUMDdpBMVeaasVAZzSk,3273833
+franky_control.libs/libPocoNet-18bb01e7.so.95,sha256=rw04unxMioVxQ1Dd01N0pP0hy8kii8uYN7bOQjtrf50,2504833
 franky_control.libs/libboost_filesystem-38deced9.so.1.66.0,sha256=-thu-LYmEDUKnOhQw3njV9C58dVZV12pn_6-KoqDCeI,145241
 franky_control.libs/libboost_serialization-3aa46b41.so.1.66.0,sha256=KpSA9K4iakzd-Mvv5JvPSqxJyMYsVkcIXrUbSlAkiIo,316673
 franky_control.libs/libboost_system-69a6c43e.so.1.66.0,sha256=sd_lA0coUWXm-bluxkOkNrzrxFSAXYDphjPDwBekik8,22905
 franky_control.libs/libconsole_bridge-def124d9.so.0.3,sha256=Eg1wJzVIRG5GQhyr59_qdYgnmhto0orU0j8HW2A0JIg,27297
 franky_control.libs/libfmt-8375f6bf.so.6.2.1,sha256=Z8D_NYG4rsuwMIYP3KfNB95w7vnsPaV5XLm2EnWd9Fk,327441
-franky_control.libs/libfranka-92ddaf43.so.0.15.0,sha256=pVavBW1460_MHqwSDTbwkE5vUfGTOi2PnZjSVQRvwOY,1145681
-franky_control.libs/libpinocchio_default-53a889f9.so.3.1.0,sha256=1us8TU8dwRDiCeB-sUnSx2w_Czcr7E-QC21VVO_ht0g,9255841
-franky_control.libs/libpinocchio_parsers-a0902fb5.so.3.1.0,sha256=hsF6GO3VBJu034O1PxRlQSTyGmFKaEdO1_lN7Z3bbgM,713129
+franky_control.libs/libfranka-ef91489b.so.0.15.3,sha256=eVy59SBbO6LWbJgdmJfiPrZuLYrIRJmxufaGKUXCEPs,1608673
+franky_control.libs/libpinocchio_default-79007ccc.so.3.1.0,sha256=L22h0rzxvI-BfOpnGXX92_tNeo1TGqgLTk0jSwTbNms,9255841
+franky_control.libs/libpinocchio_parsers-75953cdd.so.3.1.0,sha256=csrLN2aHiR_j77t8xTqUloqxcy043HzGG8lFT4K-tAA,713129
 franky_control.libs/libtinyxml-435d1f53.so.0.2.6.2,sha256=BGSkG-zXEYTuGquHhydNow2ufOetDZpEP7MbBZyf6hA,120209
 franky_control.libs/liburdfdom_model-9e7b5a88.so.1.0,sha256=c4cAZ09SHlu-dpMZmwsxC8Ydklm8RzEANxvdJHeh4Ho,187561
 franky_control.libs/liburdfdom_model_state-741cbb83.so.1.0,sha256=NvqLfm2u-YlCihr5GRoUGL6iJMLRHm-RFEmR0he5csM,59105
 franky_control.libs/liburdfdom_sensor-5dbb5bb4.so.1.0,sha256=udrHZ0oYFTf9qwr8hm8rSrBKZDkd1L5yy5tyh10D018,51777
 franky_control.libs/liburdfdom_world-bd943329.so.1.0,sha256=ja9WE45nXtAGUoLpg1T1Hte8BZLldj_WNf9cL3H1RPk,187561
-franky_control-1.1.0.dist-info/METADATA,sha256=O0HKEVVI_VNuEOVFEocwKNl_9oUXK3EssjRIdvLxnHM,40320
-franky_control-1.1.0.dist-info/WHEEL,sha256=wj07yRGyNgfcgMSZOScoYkBkpidoeAzGSgCNSOVFG2E,113
-franky_control-1.1.0.dist-info/top_level.txt,sha256=LdDKRvHTODs6ll6Ow5b-gmWqt4NJffHxL83MRTCv_Ag,22
-franky_control-1.1.0.dist-info/RECORD,,
-franky_control-1.1.0.dist-info/licenses/LICENSE,sha256=2n6rt7r999OuXp8iOqW9we7ORaxWncIbOwN1ILRGR2g,7651
+franky_control-1.1.2.dist-info/METADATA,sha256=0omOMnCsvfoJiVYM-tuxiS_L_Gmqzq09UT46DVB6xn8,41345
+franky_control-1.1.2.dist-info/WHEEL,sha256=wj07yRGyNgfcgMSZOScoYkBkpidoeAzGSgCNSOVFG2E,113
+franky_control-1.1.2.dist-info/top_level.txt,sha256=LdDKRvHTODs6ll6Ow5b-gmWqt4NJffHxL83MRTCv_Ag,22
+franky_control-1.1.2.dist-info/RECORD,,
+franky_control-1.1.2.dist-info/licenses/LICENSE,sha256=2n6rt7r999OuXp8iOqW9we7ORaxWncIbOwN1ILRGR2g,7651