Understanding variables inside the code

[amilasabljicasojko]

Hello!

I read your paper "Advantages of Bilinear Koopman Realizations for the Modeling and Control of Systems with Unknown Dynamics", and I was trying to figure out your code to be able to use it with my project. I wanted to be sure that I understand names of variables correctly, so I was wondering if you could tell me if the x value in /datafiles/arm-3link-markers-noload-50trials_train-10_val-5.mat file (e.g. train{1,1}.x) is notation for location of the end of each link, just like you used it in your paper, or something else?

Thank you very much in advance! I really like your work and I hope it will be useful to me, too.

[bruderd]

Hello!

Thank you for your question and interest in our work. There is a discrepancy between the names of variables in the paper and in the code. The variable that describes the Cartesian coordinates of the ends of each link as in the paper is actually 'y'.

The only fields of this data struct that are actually used to identify the Koopman models are 'u' (the input) and 'y' (the output). All of the other fields are just included for plotting/animation purposes.

For reference, here is what each variable represents:
-t: time
-alpha: joint angles
-alphadot: joint velocities
-x: alpha and alphadot combined, i.e. x = [ alpha , alphadot ]
-w: end effector load (not used in this paper)
-u: input, i.e. applied joint torques (as in the paper)
-y: output, i.e. location of the end of each link in Cartesian coordinates (called x(t) in the paper)
-params: Collection of parameters, e.g. link lengths, masses, etc.

We apologize for the confusion and thank you for pointing this out! Please let us know if anything else is not clear and we will do our best to explain and/or fix the issue.

Best,
Dan

[amilasabljicasojko]

Dear Dan,

Thank you so much for the clarification, I really appreciate it! This will make it much easier for me to use your code with my system. I will for sure let you know in case I encounter any other problem in understanding your project.

Good luck with your work!

Regards,

Amila

[amilasabljicasojko]

Hello!

I ran again into an issue with understanding variables. In your paper and answer to this issue you say that u is input, i.e. applied joint torques (as in the paper), but in your code you define u as 'Desired joint angle for all joints in each module' (this is what you wrote as a comment in Arm.m, line 211). After plotting both u from train{1,1} and joint angles alpha, I noticed that joint angles follow the trajectory of input u, meaning that indeed u is reference for joints, rather than joint torques.

Now, I am really confused since your paper and your answer don't support my opinion on u being reference joint angles.

I would really appreciate it if you could help me with this issue.

Regards,

Amila

[bruderd]

Hi Amila,

Apologies, you are correct and this is an error on my part! The joint torques applied to the arm are actually proportional to the difference between u and the joint angles (alpha), i.e.

joint_torques = Ku * ( u - alpha )

If you would like to change u so that it represents joint torques instead, you could modify Arm.m, line 212 to be:
input = -kron( u , ones( obj.params.nlinks , 1) ); % vector of all joint torques

Sorry for this discrepancy in the description. I've added a note to the ReadMe file and will update the paper to reflect this difference.

Best,
Dan

[amilasabljicasojko]

Hello Dan,

Thank you so much for your answer!

I have just one more question; is there a reason for using only location of the end of each link as the output in y, and not also velocity of the end of each link?

Regards,

Amila

[bruderd]

Hi Amila,

Great question. The choice of the input and output variables used for system identification is up to the user, so the velocity could have been included if desired.

In our experience, when collecting data for real systems we often don't directly measure velocity. For example, when using a motion capture system to track marker locations, we measure their positions in time, but have to rely on numerical differentiation to get an estimate of velocity. In that case, we could either include velocity estimates, or past position measurements in the output y, as done in this paper (see equations equations (17) and (18) ):
Bruder, Daniel, et al. "Data-Driven Control of Soft Robots Using Koopman Operator Theory." IEEE Transactions on Robotics (2020).

Since the planar arm in this paper is a simulated system we could have easily included velocities, we just chose not to in this case.

Thanks for the question!
Best,
Dan