I don't understand why you'd do this. This is THE problem machine learning algorithms are made for. They will be better at this than almost anything else, so why bother with all this theory?
Plus this theory suffers from all sorts of problems like singularities, gimbal lock, self-crossing, ... that machine learning either extremely likely won't have, or definitely won't have.
I mean I get it's how it was done before. But at this point, why?
The practical reason is speed and low resources consumption.
It's solving the Inverse Kinematics problem in the order of microseconds.
It's almost a closed form solution.
Typically it needs to be inside an embedded device, where memory is sparse and not allocated.
It will probably be inside the control loop of a "Real Time OS" or chip, because the end effector position is usually what matter. So your commands and PID setpoints are expressed in this basis and you need to transform them into angle commands for your servo-motors 10-100K times per second.
Most machine learning frameworks are not running on real time, which introduce jitter in the command times. Typically the control loop are more around 100hz max. In a cascaded controller fashion, what you typically then do is use slow systems (non-RTOS) with machine learning for high level tasks and transmit the low level commands to the controller given in desired positions, desired velocities, desired acceleration to follow the path planned trajectory, and hope nothing too brutal happen (like your spindle at the end of your arm encountering more resistance, or your robot leg hitting the ground or touching an obstacle) in the hundredths of second before you can get feedback.
Closed-form solution makes verification much easier. There's the design and solution space for an engineering system, and then there's V&V.
Yes, you can just ship it and test it in your customer's environment, but that doesn't scale very well if you have to run 1-2 months of testing every time you deploy to make sure the ML model doesn't give you random bullshit that flings the arm around and wack someone in the head or damage other equipment.
Not to mention, IK is something so well understood that it would be stupid not to use it at least as a start to building an arm motion software. It's also much faster than doing inference on a model.
You have it up-side-down: with ML you can NEVER proove that you won't suffer a gimbal lock or other problem.
So if you have a very fast analytical approach you can simulate different paths in a physics simulator on the chip also as a verification step if needed to reject incorrect movements.
You could then use ML as a fallback if no fast analytical method works and verify that also a quick on-chip physics sim.
Why use machine learning to solve a problem that you already know how to solve? The classical method is easier to derive, run and understand. Any failure cases can be easily reasoned about and can be clearly outlined and ameliorated if needed. Your proposed replacement needs lots of training data, a training cost that needs to be paid for any change in the data, a costlier runtime and unknown failure cases that we can't reason about at all. And if we hit any such failure cases the only thing we can do is change the data and cross our fingers. I don't see why learning-based methods would perform better here.
Great way to tell the 100x engineer apart from the only 10x (full-vibing) engineer.
Less snarkily, I don't know any stakeholder who doesn't believe there's a theory with far fewer parameters and lower energy/materiel needs--- like the equivalent biological neuro-subsystem
(A mosquito evades all kinds of singularities,delivers the payload, looks for food, friends, makes babies, is a joke, isn't a joke, etc)
Learning how things work and have been done before let's you build up intuition to help evaluate the ML model you're building? The article also addresses the short-coming in comparison with ML models for why you might want to take this approach over that.
I don't understand why you'd do this. This is THE problem machine learning algorithms are made for. They will be better at this than almost anything else, so why bother with all this theory?
Plus this theory suffers from all sorts of problems like singularities, gimbal lock, self-crossing, ... that machine learning either extremely likely won't have, or definitely won't have.
I mean I get it's how it was done before. But at this point, why?
The practical reason is speed and low resources consumption.
It's solving the Inverse Kinematics problem in the order of microseconds.
It's almost a closed form solution.
Typically it needs to be inside an embedded device, where memory is sparse and not allocated.
It will probably be inside the control loop of a "Real Time OS" or chip, because the end effector position is usually what matter. So your commands and PID setpoints are expressed in this basis and you need to transform them into angle commands for your servo-motors 10-100K times per second.
Most machine learning frameworks are not running on real time, which introduce jitter in the command times. Typically the control loop are more around 100hz max. In a cascaded controller fashion, what you typically then do is use slow systems (non-RTOS) with machine learning for high level tasks and transmit the low level commands to the controller given in desired positions, desired velocities, desired acceleration to follow the path planned trajectory, and hope nothing too brutal happen (like your spindle at the end of your arm encountering more resistance, or your robot leg hitting the ground or touching an obstacle) in the hundredths of second before you can get feedback.
Closed-form solution makes verification much easier. There's the design and solution space for an engineering system, and then there's V&V.
Yes, you can just ship it and test it in your customer's environment, but that doesn't scale very well if you have to run 1-2 months of testing every time you deploy to make sure the ML model doesn't give you random bullshit that flings the arm around and wack someone in the head or damage other equipment.
Not to mention, IK is something so well understood that it would be stupid not to use it at least as a start to building an arm motion software. It's also much faster than doing inference on a model.
You have it up-side-down: with ML you can NEVER proove that you won't suffer a gimbal lock or other problem.
So if you have a very fast analytical approach you can simulate different paths in a physics simulator on the chip also as a verification step if needed to reject incorrect movements.
You could then use ML as a fallback if no fast analytical method works and verify that also a quick on-chip physics sim.
Why use machine learning to solve a problem that you already know how to solve? The classical method is easier to derive, run and understand. Any failure cases can be easily reasoned about and can be clearly outlined and ameliorated if needed. Your proposed replacement needs lots of training data, a training cost that needs to be paid for any change in the data, a costlier runtime and unknown failure cases that we can't reason about at all. And if we hit any such failure cases the only thing we can do is change the data and cross our fingers. I don't see why learning-based methods would perform better here.
>Why?
Great way to tell the 100x engineer apart from the only 10x (full-vibing) engineer.
Less snarkily, I don't know any stakeholder who doesn't believe there's a theory with far fewer parameters and lower energy/materiel needs--- like the equivalent biological neuro-subsystem
(A mosquito evades all kinds of singularities,delivers the payload, looks for food, friends, makes babies, is a joke, isn't a joke, etc)
Learning how things work and have been done before let's you build up intuition to help evaluate the ML model you're building? The article also addresses the short-coming in comparison with ML models for why you might want to take this approach over that.