Rc/4.0.0 by kvasios · Pull Request #1 · frankarobotics/franka_toolbox_for_matlab

kvasios · 2025-12-06T17:11:29Z

New Franka Toolbox release 4.0.0 including:

New auto-build system for franka.mtlbx under github release page.
Default build --> libfranka 0.18.2.
FrankaRobot API: Added FrankaRobotSettings class for centralized robot configuration.
FrankaRobot API: New methods for impedance control (setJointImpedance, setCartesianImpedance), guiding mode (setGuidingMode), frame transformations (setEE, setK), and motion control (stop).

Full build with github workflow build-and-release.yml which is activated when pushing tags to the remote.

you can check the outcome of the release process here --> https://github.com/kvasios/franka_toolbox_for_matlab/releases

AndreasKuhner · 2026-02-27T08:13:23Z

common/src/robot_api.cpp

+    // Attempt automatic error recovery to clear any previous error state
+    // This ensures the robot is ready for control even if the previous run ended with an error
+    try {
+        robot->automaticErrorRecovery();


Please remove redundant comments -> I guess the function 'automaticErrorRecovery' explains already what the comment is telling :)

AndreasKuhner · 2026-02-27T08:14:14Z

common/src/robot_api.cpp

    robot = std::make_unique<franka::Robot>(robotIPString);

+    // Attempt automatic error recovery to clear any previous error state
+    // This ensures the robot is ready for control even if the previous run ended with an error


Here as well

AndreasKuhner · 2026-02-27T08:18:36Z

docker/scripts/build_libfranka.sh

Why is all of this necessary?

Wasn't the user able to build the whole thing so far?

The user can still build the project at will by choosing freely any desired build method. These are definitely not a "must".

The story so far regarding this build infra:

These are dev tools developed so we can handle testing and evaluation complexity as the toolbox involves binaries for the matlab/simulink mex front end for Windows and Ubuntu Host PC, combined with the back-end layer (robot_api stuff under common + rpc server) for both Jetson (Franka AI companion) + amd64 targets.

This build infrastructure allow us to drive the github workflows for delivering a standalone "drag-and-drop" final franka.mtlbx which is the standard Matlab Toolbox distribution format.

AndreasKuhner · 2026-02-27T08:22:28Z

docker/scripts/common.sh

Why do we need all of this?

Same answer as previous comment.

AndreasKuhner · 2026-02-27T08:24:52Z

docs/franka_matlab/custom_build.rst

+
+    # Build Cap'n Proto (static libraries with PIC)
+    CAPNP_VERSION="1.0.2"
+    curl -O https://capnproto.org/capnproto-c++-${CAPNP_VERSION}.tar.gz


Why do we need proto?

We opted for a client-server architecture in order to add support for the Franka AI companion (and generally jetson platforms) for our Matlab API (not simulink in this case). Main drive for the capnproto against other alternatives was it's light weight structure, quite simple straightforward and clean API in combination with its delivery of a simple out-of-the-box rpc server framework.

I don't understand it. It doesn't make sense to add support via proto towards the matlab api. Either you can use the matlab api directly e.g. via simulink or matlab or you don't need matlab and go directly via libfranka :)

If we would add support to communicate via protos (or something similar), we would introduce that on a libfranka level.

The problem formulation and the motivation behind this was at the time (~1.5-2y ago):

Windows support if very attractive for Matlab users. Windows has no rt capability (at least adequate for robustly maintaining the FCI 1khz thing). Additionally RT for some workstation setup is painful even for Ubuntu (NVIDIA GPU confict etc).

We do want some high-level Matlab API support for the robot (not libfranka 1khz level rather than just simple joint point to point motion, traj open-loop follow up) as a feature in order for the users to be able to rapid-prototype and evaluate Matlab infra directly on the robot.

Support for the Franka AI companion in conjunction Matlab (client running in workstation PC non rt)

Given 1, 2 and 3 we opted for a server-client architecture for supporting our Matlab API.

This is very similar actually with other popular high-level APIs for the robot in python like polymetis and deoxys control.

This architecture was not introduced with this PR btw and is already active since the release of version 1.0.0.

If things have changed regarding the 1 2 and 3 constraints we can drop support for the high-level Matlab API all together. Or supported only in the case where the Matlab is running in RT kernel Ubuntu Host PC.

Please let me know on how you'd like to proceed on that. In my humble opinion this discussion is outside the scope of the current PR and should be part of the overall project dev roadmap.

Yes of course, that topic is outside of the scope of this :)

I was mostly curious on the 'why'.

AndreasKuhner · 2026-02-27T08:29:06Z

franka_robot/src/franka_robot.cpp


+    // Set Joint Impedance
+    if (!strcmp("set_joint_impedance", cmd)) {
+        if (nlhs != 1 || nrhs != 3)


What is nlhs? Or nrhs?

These are the number of the given return outputs (nlhs) and and the given function arguments (nrhs) that the user has typed in matlab when calling a function. (standard Matlab nomenclature).

Like e.g >> [a,b,c] = matlab_foo(d,e,f,g) would mean nlhs = 3 and nrhs = 4.

Hence some sanity check in this case when the user is calling our Matlab API methods.

AndreasKuhner · 2026-02-27T08:30:37Z

franka_robot/src/franka_robot.cpp

    }

+    // Set Joint Impedance
+    if (!strcmp("set_joint_impedance", cmd)) {


Why do you need to use a strcmp and not just ==?

It's a balance act dealing with the Matlab mex function style which is traditionally C :).

(Yes there is a more recent C++ infra for Matlab mex function but I've faced interoperability issues in the past and still the standard C mex api is the more mature and "standard" framework.)

Based on that e.g for parsing the matlab cmd we do:

char cmd[64];
mxGetString(prhs[0], cmd, sizeof(cmd)))

which "forces us" into the C-style strcmp().

Again "matlaby" mex function idiomatic stuff.

AndreasKuhner · 2026-02-27T08:36:25Z

franka_robot/src/franka_robot.cpp

    }

+    // Set Joint Impedance
+    if (!strcmp("set_joint_impedance", cmd)) {


Where these functions not yet available or why the introduction?

Yep they were not available as part of the Matlab API of ours. The previous version 1.0.0 included a subset of the libfranka available methods. This PR includes these residual functions following the commonly agreed development roadmap of the project.

AndreasKuhner · 2026-02-27T08:43:12Z

franka_robot_server/src/frame_transformations.cpp

+#include <franka/robot.h>
+#include <array>
+
+kj::Promise<void> FrankaRobotRPCServiceImpl::setK(


For what do we have RPC calls?

We opted for a client-server architecture in order to add support for the Franka AI companion (and generally jetson platforms) for our Matlab API (not simulink in this case). Main drive for the capnproto against other alternatives was it's light weight structure, quite simple straightforward and clean API in combination with its delivery of a simple out-of-the-box rpc server framework.

franka_robot/franka_robot_mex.m

README.md

docs/franka_matlab/matlab_library.rst

kvasios added 30 commits November 30, 2025 16:43

introducing docker

2b14633

cross-compilation - docker - work (runntime test pending)

3ff6c70

fixing bundling for cross-compilation

71c78ae

linuxdeploy rep

999896f

cross compilation finetuned

0503d56

fixing c++ comp issue

5a8275c

switching to libfranka 0.18.1

b960f35

fixing arm build for new libfranka 0.18.1

a46e387

build system for latest libfranka works

2526a4d

looking good

707b0ec

default build libfranka 0.18.1

3502051

first attempt for a complete build

ff67b17

fixing find package issue during cross compilation

ca0ee3e

fixing hpp cross-compilation issue

c15d155

fixing issue with arm64 cross-compilation

abb2a8f

libfranka eigen find for cross-comp

426d276

trying to revert changes

c779f79

fixed it seems

456ce7c

fixing build and release yml

38251c9

adding build process for gen1

7330d5d

fixing naming

fdda0d9

fixing packaging workflow

51f1d6a

removing build artifacts from the project

d38ac75

matlab r2023a after all

e3b9506

updating README and docs

e070180

fixing clean up operation regarding gen1-binaries placeholder

344398c

fixing toolbox naming convention

c26001c

removing ci.yml for now

92a2893

new .mtlbx naming format

22bece7

fixing naming convention

fe79dc4

kvasios added 8 commits December 15, 2025 15:24

trimming it down

4934cbc

controllable lifecycle of FrankaRobot()

75fb985

franka robot server

cfd5e14

franka robot c++17 flag for auto bind feature

3e64b7a

updating changelogs

2aa99d7

fixing c++17 flag for windows

e4548c9

fixing release page

9b2bd16

removing artifact

9068307

kmohyeldine requested review from AndreasKuhner, BarisYazici, francando, gomezgu and winkma February 3, 2026 16:07

AndreasKuhner reviewed Feb 27, 2026

View reviewed changes

removing redundant comments

8162348

kvasios force-pushed the rc/4.0.0 branch from df9e0ff to 8162348 Compare March 2, 2026 11:22

kvasios added 3 commits March 5, 2026 17:52

libfranka latest 0.20.5

caf7d1c

fixing changelog libfranka ver

800987c

fixing release workflow for auto libfranka ver referencing

f350d94

gomezgu reviewed Mar 17, 2026

View reviewed changes

franka_robot/franka_robot_mex.m Show resolved Hide resolved

gomezgu reviewed Mar 18, 2026

View reviewed changes

README.md Show resolved Hide resolved

kvasios added 6 commits March 21, 2026 17:34

prompting users regarding custom build

209a27d

fixing compatibility matrix

e404dd6

making the installation script more descriptive

851f65a

more informative install warning message

6023c9f

build process hardening and output checks

71e0762

changing default dist make behavior to ci

468cc55

gomezgu reviewed Mar 24, 2026

View reviewed changes

docs/franka_matlab/matlab_library.rst Outdated Show resolved Hide resolved

removing set guiding mode

fcc1f9d

gomezgu merged commit 9d7c9cd into frankarobotics:main Mar 31, 2026

Conversation

kvasios commented Dec 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants