# Tag Info

10

In control theory, we refer to this as "open-loop control", which emphasizes the lack of a feedback loop. The wikipedia article has several examples of open-loop control.

8

In classical position control, the feedback controller only cares about the position error and is tuned to minimize it. This is done by using very high gains, i.e. if there is even a small position error, the controller counteracts by applying very high torques to the joints. It does not matter if there is a person or a concrete wall in its path; just ...

5

Can you set up the problem so that the quantities you care about (e.g. power) are more explicitly represented? Reasoning physically, where could the power go? Accelerating masses, including rotation Pushing against gravity, electromagnetics, other potentials Stretching springs and whatever Dissipation through friction You say "optimize power ...

4

Your intuition is partially correct in the sense that you ought to go with position control implemented via velocity commands resorting to a kinematic (not dynamic) model of the manipulator. This can be explained by inspecting one of the easiest policy used for inverse kinematics, $$\dot{\mathbf{q}} = \mathbf{J}^{-1} \cdot \left( \mathbf{x}_d - \mathbf{x}(\... 4 You can view impedance control as having more control over the force resulting at the end effector, than in position control. In position control, the goal is to get to the reference position no matter what, even if it needs the maximum force of the motor. In impedance control, you control the ratio between force and velocity. Even if the robot deviates from ... 3 Don't disengage your controller. The purpose of a controller is not only to steer your system to the desired setpoint according to a predetermined dynamical response but also to counteract potential external factors that may impede this task. Think of a disturbance that will drive the system far from the setpoint once it has been reached. Thus, the ... 3 I've gotten stuck in a rut with grasping what the "U" control signal actually refers to in the physical system But you've written what it is already!$$ \dot{x} = Ax + Bu $$It's whatever the input to your system is. Maybe it's speed, or thrust, or acceleration. It's the thing that is exciting your system. I'm looking at your equations and I don't ... 3 First, isolate the second order from the other terms:$$ a \, \ddot{x}_1 + b \, \ddot{x}_2 =- c \,\dot{x_1} - d \,\dot{x_2} - e + u_1 \\ f \, \ddot{x}_1 + g \, \ddot{x}_2 = - h \,\dot{x_1} - i \,\dot{x_2} - j + u_2 $$Then, put it in a matrix form:$$ \left[\begin{matrix}a&b\\f&g\end{matrix}\right]\left[\begin{matrix}\ddot{x_1}\\\ddot{x_2}\end{matrix}...

3

First of all, you have to define real-time. Is it "motion control real-time" or "instant messaging chat app real-time". For the first one, ROS is not a good option. In theory yes, but in practice, the advantage of ROS, the ready made ROS nodes for interfacing with robots, path planning, interfaces to different sensors are largely only ...

3

I can add one more point to RowanP's excellent list: the servo's PID is unreliable, not because of a defect, but because it is mistuned for your application. Recall that tuning a PID control is arcane, if not entirely a black art. The servo manufacturer tuned the control PID coefficients for some use case, perhaps moving RC aircraft control surfaces. That ...

3

I came back to this question and thought a bit more about it because of your bounty - typically the bounties are offered from a point of desperation, and I hate that feeling myself. I think probably your code is fine, in looking at it. There are things that I'd do differently, like scaling your PID output by the time step, but you could distribute that ...

2

You could always employ conditional expressions that are clear and explicit. Instead, if you like compact forms, you may implement saturation as below: w = w_fb + min(hi, max(low, w_ff)); where hi and low are the upper and lower bounds of the saturation.

2

As Ugo Pattacini said, the experiment must be rethought taking into account the dynamics of the ball. In this case, your system will have 4 states: current $j$, angular velocity $\omega$, ball height $h$, and ball speed $s=\dot{h}$. As pointed out, the dynamics of $s$, neglecting viscous friction and other aerodynamic effects, can be modeled as $\dot{s}={T\... 2 In newer versions of Matlab (I can't remember when this change was made) you can define symbolic variables as a function of time, like syms rho(t) alpha(t); Symbolic constants are anything defined not as a function of time, like: syms k1; Then you can define your expression for v without needing to declare v itself as symbolic: v = k1*rho*cos(alpha); ... 2 I assume that you'd aim to place the poles in$-0.5 \pm 0.2 \cdot i$for stability reasons. In the s-domain, the transfer function is: $$\frac{\Phi_c}{\Phi}=\frac{K_p}{s^2+K_ds+K_p}.$$ Computing the closed-loop poles, hence the roots of the characteristics polynomial$s^2+K_ds+K_p$, gives you: $$\begin{array}{cc} K_d=1 \\ K_p=1.16/4 \end{array}.$$ 2 Chuck's answer is spot on. Anyway, if you want to derive the reason mathematically, you can start off from the most common form of a PD controller where we employ a setpoint-weighting for the derivative part: $$u(t) = K \cdot \left( e(t) - T_d \cdot \dot{y}(t) \right).$$ The Laplace transform of a feasible$D$term is thus: $$D(s) = -\frac{sKT_d}{1+sT_d/N}... 2 The code is computing the gradient of the cost, which is jerk squared, not the gradient of the jerk. The comment there is misleading! As written, it seems the code is implementing the chain rule of$$ c = j^\top j  \frac{\partial c}{\partial q} = 2j\frac{\partial j}{\partial q}$2j$is set to temp_j and you can see how the partial of jerk w.r.t q is ... 2 You are confusing the “robot + controller” with the robot itself. Every physical system has dynamic properties. As shown by your first equation, the dynamics are related to joint accelerations, velocities, and positions (embedded within the matrices). The desired state has nothing to do with how the physical system responds to its state variables. That ... 2 This looks like a common angle wrapping mistake. I am assuming you're defining your angles between -180° ($-\pi$) to +180° ($\pi$). Let's say your current heading is -170°. And you desired heading is 170°. The error in angle is: 170 - (-170) = 340, so your robot has to do almost a full turn to get to the desired heading. Since you're defining your angle in ... 2 output signal from the controller (i.e. a velocity value) is proportional to the error value I think there is some confusion here. In a standard velocity control loop, the controller output cannot be the velocity itself, by definition. Instead, the velocity is the feedback, whereas the controller output is most likely the voltage applied to the electrical ... 2 I think you've got a conceptual issue here with your PID setup. You mention both: a PID controller that takes as input the current distance between the second robot and the first one and using the error, e(t) provided by the PID A PID controller accepts an error as an input and tries to drive that error to zero. If you are providing an absolute position ... 2 First, you need to get rid of the damping matrix C as it transforms kinetic energy into heat. Second, you should make the mass matrix as small as possible. (lightweight construction). After that you can think about the best way to distribute the mass that you cant get rid off by taking the desired movements into account. 2 Weird motion I'm pretty sure it happen because you make wrong implementation on orientation control. Orientation of end-effector There are 4 main representation of end-effector orientation which is axis angle, rpy (expanded into 6 types), euler angle (expanded into 6 types) and unit quarternion. Normal jacobian derived freshly from forward kinematic ... 2 It's explained on the video description: In this research, a methodology for sensor-less full body active compliance was used on a 6-DOF RSS (Rotary-Spherical-Spherical) parallel manipulator. The manipulator can detect and comply with the external forces on any part of its body without using any explicit force/torque sensor at the joint or the end-effector. ... 1 On the theory side, this is related to the Nyquist Sampling Rate, which is how frequently you must measure a single to get an accurate reconstruction of it's peaks / valleys. Not suprisingly, Nyquist as a name appears all over some fundamental results in optimal control like the nyquist stability theorem. I suspect the insight you are looking for is right ... 1 Generally, for small movements (or steps), most servos are torque limited to prevent overshoot and oscillations. If you change the input pulse timing by 20uS, the motor will not reach full torque before it starts braking the motor to stop. The motor torque is also throttled at the end of the desired motion to prevent overshoot of the target position. Even ... 1 grbl has a trapezoidal velocity profile. It has an acceleration limit (so a ramp on the velocity), but does not set a jerk limit. Jerk limiting would be probably an overkill for stepper-motors. However, grbl does use smooth stepping on for the stepper motors, this reduces the stepping frequency induced vibrations. Source: here 1 A disturbance yaw rate of$-0.1, \text{deg/s}\$ seems way low. Are sure that in steady-state there won't be any cause external to your copter (very low airflow?) justifying it? Imbalance between the RPMs provided by the motors (max current not reached) ❌ The open-loop response of different motors will certainly vary because of the variability of the building ...

1

It would be much better to determine a fixed sample rate for your controller. A really rough rule of thumb is that whatever the settling time you need out of the loop once it is operating in the linear regime, your sampling interval should be between 10 times and 100 times less than the settling time. Put another way, the sample rate should be 10 to 100 ...

1

Real signals have noise. Because noise happens on a per-sample basis, you wind up with a derivative that is constantly fluctuating. A derivative gain acts on this fluctuation and feeds it to the motor, resulting in the noise or jitter you observe.

Only top voted, non community-wiki answers of a minimum length are eligible