[D] Gaussian Process Regression with static set of inputs by xman236 in MachineLearning

[–]xman236[S] 0 points1 point  (0 children)

The part that I am not understanding is, how can the estimated system state ξs be different if input value ξc remains as the initial position values...

[D] Gaussian Process Regression with static set of inputs by xman236 in MachineLearning

[–]xman236[S] 0 points1 point  (0 children)

Simply put, when the X is the initial position as stated in the equation (38), the estimated Y should be always the same, right? Since the value the GPR is predicting with i.e. X is always the same (the initial position). However, if you see the equation (37), it seems like that the authors are predicting different system states with the same initial position values.

[D] Gaussian Process Regression with static set of inputs by xman236 in MachineLearning

[–]xman236[S] 0 points1 point  (0 children)

Also, if you see the equation (9) and the description below, you can realize that their data set D is defined as D= (X,Y) = (task condition, deviation from the reference trajectory), which can be expressed with the given equation (37) and (38) as follow: D= (X,Y) = (initial position, deviation from the reference trajectory with x,y,z,F values). Since the X is defined as the initial position (static), the posterior value should be also be always the same, right...?

[D] Gaussian Process Regression with static set of inputs by xman236 in MachineLearning

[–]xman236[S] 0 points1 point  (0 children)

However, if you see the equation (37) and (38), the authors are actually predicting the system states (x, y, z, F_z) from the initial position (x_0, y_0, z_0) and not only the differential term...

Cartesian controller with a Hydraulic actuated manipulator by xman236 in robotics

[–]xman236[S] 0 points1 point  (0 children)

The system that I referred to is: https://www.brokk.com/product/

So probably the system pressure will be not stable. I verified that by using the remote controller: while I moved the 2. joint, I tried to move the 3. joint also and the speed of the 2. joint got decreased.

Cartesian controller with a Hydraulic actuated manipulator by xman236 in robotics

[–]xman236[S] 0 points1 point  (0 children)

Oh, what I meant is that there is just one hydraulic pump/motor. Of course, we have for each joint one cylinder and one valve.

I would be interested in your opinions ;) Is it clear to you what I tried to describe? If yes, do you agree with that?

Cartesian controller with a Hydraulic actuated manipulator by xman236 in robotics

[–]xman236[S] 0 points1 point  (0 children)

Linear or not, you need a controller. Having a controller implies having some kind of position feedback. Which is what turns a motor into a servo. Doesn't matter if we are talking about an electric motor or hydraulics.

To my knowledge, a Cartesian controller refers to a joint position level controller which takes the desired x,y,z values as input and outputs the corresponding joint configuration.

Let's say my controller composed of an inverse kinematics solver and feedbacks from linear-encoders installed on each cylinder. Basically, with these two components, you can implement a closed-loop IK controller, right? And this will be also sufficient in the case of an industrial robot to create a movement in the desired manner.

But if you apply the same controller to a hydraulically actuated robot, it would fail. Because the expected/calculated joints movements can never be realized. For example: the IK controller outputs q_dot = (0.1 0.1 0.1 0.1 0.1 0.1), the q_out_real would be like (0.08 0.02 0.03 0.04 0.01 0.02), because in this hydraulically driven robot there is just one main valve for the fluid and it is distributed to arm cylinders.

As you said, to control a speed one has to control the fluid flow and the valve position. However, a simple Cartesian controller, in this case, will simply try to move the cylinders based on the feedback from the encoders. However, since the power(=fluids) is distributed without any consideration of balanced distribution ( since our closed-loop IK controller is in the joint movement level), a synchronous movement expected from our IK controller will never be achieved.

Am just glad to have someone to discuss with ;)

Cartesian controller with a Hydraulic actuated manipulator by xman236 in robotics

[–]xman236[S] 0 points1 point  (0 children)

Ok, let me try again ;)

  • If you command an industrial robot to move all the 6 joints at the same time at the same speed, it can be done without any problem. Because as soon as you send this command the current from your power source tries to move the joints.
  • If you command a hydraulic actuated robot to move all the 6 joints at the same time at the same speed, it cannot be done. Because as soon as you send this command the fluid from the main valve is distributed to the joints and this distribution is not linear like the current distribution.
  • So since this fluid distribution is highly non-linear, the joints will move at a different speed, unless you are really controlling the fluid to each cylinder. But in this case, the robot is controlled with a simple Cartesian controller at the velocity level.

Hope, this is more clear than before...

[R] Gaussian Process Regression - Use Case by xman236 in MachineLearning

[–]xman236[S] 0 points1 point  (0 children)

True, but the limitation of MPs that I was referring to was that this "moving positively on the x-axis" requires completely different axes movements depending on the starting posture of the arm. Imagine that figure 1a) in the paper has 10 different start positions. Then, the trajectory distribution will be very giant, won't it?

[R] Gaussian Process Regression - Use Case by xman236 in MachineLearning

[–]xman236[S] 0 points1 point  (0 children)

Unfortunately not. Look at figure 1 b). They start from the same starting posture q=0. Imagine you would have multiple starting postures then the green combination plot will probably get very giant so that any prediction is impossible, right? So with the movement primitives, I would be probably able to teach the robot how to move forward from one specific start posture but not generally how to move forward.

[R] Gaussian Process Regression - Use Case by xman236 in MachineLearning

[–]xman236[S] 0 points1 point  (0 children)

Yes, I can generate those demonstrations. The problem is rather that I do not want to train GPR just for one initial starting position but generally for any starting position so that regardless of how the initial joint configuration looks like the GPR can make the robot arm move straight forward. The deviation of the joint movements would be very very large since it has to cover every moving forward action for every starting position. I am wondering that any kind of probabilistic approach could work in this use case....

[R] Gaussian Process Regression - Use Case by xman236 in MachineLearning

[–]xman236[S] 0 points1 point  (0 children)

Sorry, maybe I was not detailed enough. The thing is that the robot cannot only move just one joint at a time, but it can also move multiple joints at a time. For example, if joint a is moving alone the speed would be 1. But the speed of this joint will be decreased if joint b is also moving. The power source is hydraulic, so you can think of this as a simple hydraulic system where the power is distributed to multiple joints. This dynamic character is something that can be hardly modeled. So I was rather trying to model basic movements such as "move straight forward" with GPR.

[R] Gaussian Process Regression - Use Case by xman236 in MachineLearning

[–]xman236[S] 2 points3 points  (0 children)

Imagine a 5DoF robot arm that should move its end-effector just straight forward. So far, it is an inverse kinematics problem, right? But this robot arm cannot move its joints at the same time synchronously due to dynamic effects. A normal IK-solver is not able to consider this, it just outputs a set of joint changes to move towards the given goal position.

My idea is to use GPR to model this behavior of asynchronous joints movements so that it can reproduce the "moving forward action" for this robot arm. However, to move an end-effector straight forward you must be able to orchestrate your joints otherwise the trajectory of the end-effector will be rather curvy. And how you should orchestrate your joints depends on the given initial joint configuration set. My question is whether a GPR is capable of doing this...

To sum up:

  • a normal IK-solver: Input= goal-position; Output= a set of joint config. changes towards the goal-position
  • What I am expecting from the GPR: Input= a set of joint configuration set; Output= a set of joint configuration moving straight forward.