Can't get better than 0.88sec? function controlFunction(block) { const max_force=1000000000; const margin=0.01; const friction_comp=0.2; if(block.x
The best you can do is 0.42, see a subcomment I made below. max force is limited to +-50
PID Control Challenges
111–120 of 123 posts
Re: PID Control Challenges
#112Can't get better than 0.88sec? function controlFunction(block) { const max_force=1000000000; const margin=0.01; const friction_comp=0.2; if(block.x
I got 0.4 sec with this:
function controlFunction(block)
{
const maxforce = 100.;
if (block.x < -1.01)
return maxforce;
else if (block.x < -0.01)
return -maxforce;
else
return -block.x - 2 * block.dx;
}
Re: PID Control Challenges
#113Tutorial #3 0.72s
function controlFunction(block) { return -500 * block.x -60 * block.dx; }
Re: PID Control Challenges
#114Earlier quoted context omitted.
And isNan is a BAND and JNE effectively. It's cheap.
NaN is only one of the most obvious. Catastrophic precision loss from cancellation can leave you oscillating for no obvious reason.
Isn't the only reason you might run into this with floating point but not with fixed point for the same task that you basically "waste" 10 bits or so on range which you could instead have used on precision (assuming all quantities of interest can be sufficiently well represented in a single range)?
Re: PID Control Challenges
#115My control systems prof said every engineer has done an inverted pendulum problem in school and nobody in their career has ever been asked to balance an inverted pendulum. So our final was a thermostat instead.
> nobody in their career has ever been asked to balance an inverted pendulum Thats what all those self-balancing scooters are.
And the stair climbing wheelchair.
Re: PID Control Challenges
#116Earlier quoted context omitted.
My inner child of Doc Brown and Wernher von Kerman says, it's time to develop non-newtonian fuel sponges, which would release fuel if squeezed gently and steadily, but behave like solid if things start shaking too much, preventing sloshing.
Or maybe giant syringes? There can't be sloshing if there is no free space because top of cylinder just moves to adjust volume.
Some fighter planes go this. They use a bladder they compress, works the same.
Re: PID Control Challenges
#117Earlier quoted context omitted.
My inner child of Doc Brown and Wernher von Kerman says, it's time to develop non-newtonian fuel sponges, which would release fuel if squeezed gently and steadily, but behave like solid if things start shaking too much, preventing sloshing.
Or maybe giant syringes? There can't be sloshing if there is no free space because top of cylinder just moves to adjust volume.
I believe https://en.wikipedia.org/wiki/MGM-52_Lance used roughly this configuration, with a gas generator pushing the back of the pistons. As I remember, the oxidizer and fuel pistons were physically connected (concentric, with concentric propellant tanks) to simplify getting the mixture correct.
Re: PID Control Challenges
#118Can't get better than 0.88sec? function controlFunction(block) { const max_force=1000000000; const margin=0.01; const friction_comp=0.2; if(block.x
I got 0.4 sec with this: function controlFunction(block) { const maxforce = 100.; if (block.x < -1.01) return maxforce; else if (block.x < -0.01) return -maxforce; else return -block.x - 2 * block.dx; }
Interestingly enough this does not work in every browser. (It worked in Orion, but not in Brave.)
Re: PID Control Challenges
#119Earlier quoted context omitted.
NaN is only one of the most obvious. Catastrophic precision loss from cancellation can leave you oscillating for no obvious reason.
Isn't the only reason you might run into this with floating point but not with fixed point for the same task that you basically "waste" 10 bits or so on range which you could instead have used on precision (assuming all quantities of interest can be sufficiently well represented in a single range)?
Also because when you have operations with very differing range you they end up computed at the worst precision level without regard to the effects. In a fixed point implementation you would make the two scales different types and when doing computation involving both get an opportunity to preserve the precision. E.g. by dividing down the larger range one first rather than letting the smaller range one get crushed by the worst precision
Often these issues can be handled with very careful floating point order of operations (so long as -ffast-math isn't used...) but since its all implicit it's very easy to get wrong, while in fixed point you're forced to confront the scalings of different variables explicitly.
Re: PID Control Challenges
#120Earlier quoted context omitted.
Sure! So in many, if not most, contemporary Information Retrieval (IR) problems, there is a total document set larger than could be explored on an interactive basis and so the data structures get laid out in such a way that with some probability north of a coin, you’ll find “better” documents in the “front” half. This is hand-waving a lot of detail away, so if you’d like me to go into some detail about multi-stage ra…
So basically you're using PID as a metaheuristic to guide an optimization process? (like particle swarm, simulated annealing, genetic algorithms, etc) Or it's more like, it's being used to fine tune the parameters of another search procedure? And in principle you could use a neural net rather than PID (that would encode a surface that matches the latency vs search depth profile that you want) edit: just figured out t…
It can be stated as follows:
The number of documents (denoted as N) to search over consumes resources and increases the overall latency of the search infrastructure. However, the amount of traffic ebbs and flows. Under periods of lower traffic, we likely can increase N to provide good search results without violating latency constraints. Conversely, high traffic periods likely requires lower values of N.
Let's then approximate system strain by p99 (or p99.XXX) latency.
Solution:
Use a PID controller to set N as a function of latency (p99, p99.5, etc.) of the cluster. This leads to the outcome where N reduces when p99 latency starts to spike (resource starvation), and increases when p99 is low.