The generally accepted theory is that; the sample/update rate should be 5 to 10 times the bandwidth of the system.
The short version is that the bandwidth is defined as the time taken to reach 63.2% of maximum velocity.
On some of my bigger stuff (2KW+) where I have inertia and friction, I can get great response and stability @500Hz. The industry standard seems to be 1KHz.
Possible improvements with existing limitations:
1) Set the integral to zero. I only ever use it at end of motion for eliminating the position error when precision is required. Here, we want stability.
2) Gain breaks: Try multiple Kp settings; at least one for steady-state and another for motion
3) Increase the Kd to further damp the response.
It's amazing how that works. OMRON PMAC are boasting "fastest in the world", 5-axes in 50 µsecs. I cannot think of an application that could even benefit from this but hey-ho. P2 can better this though
PMAC! I saw brochures for those in the 1990s. It was similar sorts of claims then too - Not that I can recall the actual claims. So Omron has snapped them up at some stage too.
@Rayman said:
Getting that higher rate is something was hoping to avoid…. Lots of murky code to get there…
Start by moving everything not the servo loop out of that cog. Anything that takes time to sequence should be moved out, eg: Put all the sensor query code in another cog.
Then both parts can be computed concurrently. The latest reading from the sensor gets used by the servo loop while at the same time the subsequent reading is being fetched. Double buffered in effect.
@evanh said:
PMAC! I saw brochures for those in the 1990s. It was similar sorts of claims then too - Not that I can recall the actual claims. So Omron has snapped them up at some stage too.
Yeah, Delta Tau (founder: Dimitri Dimitri) was purchased by Omron. The PMAC has always been high-end and in fact it's what LinuxCNC (EMC2) started-out with before they tried to handle real-time in Linux.
Just always been so darned expensive.
The integral term is interesting. Appears like personal preference or application need on whether to use it or not.
In this case, if you push the robot with it off, it rolls a bit forward and then stops.
With I term on and you push it, it will roll forward less and then roll back to original position.
Also need to work on startup though with I term. If it is on and then switch the battery to on, it will go bananas...
Think need some logic in there to not activate the I term until the robot is upright.
Got a wireless keyboard coming today. Going to try to use that to drive it around. That could be fun, if it works.
Wanted to use wireless gamepad, but that would mean switching to FlexProp.
Will probably have to do that at some point anyway to use the C code for the BNO086...
Also, kind of wondering if should just add the caster and be done with it... Probably should, but going to play with this some more 'cause it's way cooler.
@Rayman said:
Also need to work on startup though with I term. If it is on and then switch the battery to on, it will go bananas...
Think need some logic in there to not activate the I term until the robot is upright.
Yup, that behaviour is called Integral Wind Up. And yes, adding logic to hold and/or reset its accumulation is a done thing.
I've done one solution recently where the operator gets to set it manually if they know a good starting level. It has a capture button they can snapshot the level then use it again later.
A system that employs checking for a "bad encoder" stipulates that the integral must be active because this means that the lsb will be wagging. But in our case, the lsb wagging means jumping back and forth, 3.55mm.
@Rayman said:
Also need to work on startup though with I term. If it is on and then switch the battery to on, it will go bananas...
Think need some logic in there to not activate the I term until the robot is upright.
Yup, that behaviour is called Integral Wind Up. And yes, adding logic to hold and/or reset its accumulation is a done thing.
I've done one solution recently where the operator gets to set it manually if they know a good starting level. It has a capture button they can snapshot the level then use it again later.
Great minds think alike: I have the option to zero-out the accumulation or to preserve. I deactivate the integrator during motion and activate it at the end of motion profiling.
To minimise the following error, acceleration and velocity feed forwards are preferred (and work beautifully) because they don't affect loop stability.
I recently retrofitted a machine where I found a label stating that the high speed following error should be set <76mm
By the time I was done, 1000mm/sec had 0.2mm max following error.
That recent system I mentioned is not motion control though. It's pump speed balancing the flow against filling head. The fluid head height being the process value. It's basically a static set point. The purpose is to maintain constant gravitational pressure into the bag being sealed.
I ended up splitting the proportional and integral into separate filters, with proportional operating on a fast IIR filter and integral using an averaging (box) FIR filter that has an operator definable window length. That seemed to provide the needed frequency sensitive tuning without me learning how to do any FFT stuff. It's all in Trio Basic so not super fast.
For giggles, I grabbed a 2KW "Landrive" from AE....£35.
Totally impressed. It has two modes; VFD and actual flux vector. Flux vector is super nice. I stuck it on a Bridgeport mill and talk about a transformation. We no longer change pulleys but have a speed range from zero to twice the original speed.
There is one hell of an opportunity here for a budding entrepreneur.
I'm ordering another but this time I intend to close the position loop on it. Exciting stuff 👍
But that's the neat thing about using the prop; one can get creative. It's a bit slower with the floating point but a heck of a lot faster than TrioBasic. Heck even the Picomite interpreted Basic is three times faster than Trio.
I do similar with dual loop feedback; Proportional and integral from the secondary encoder and velocity control from the encoder in the actual motor.
PS: The main reason why the FIR filter was added is as each bag gets sealed some fluid gets pushed back out and up as the sealing bar pinches to form the closing seal. So the head level surges high momentarily once for each and every pack. We didn't want the pump to be surging in beat with that.
EDIT: However, I think, I never observed it, there was a more unstable oscillation that would creep in without the FIR filter that didn't have anything to do with seal surges. The feed back I've got so far is that pretty much only one window length works. So probably some luck on my part there.
I pioneered 100% electric CNC tube forming. I hold the patent. And this was made possible due to the arrival of flux-vector technology. Servo drives with 40Hp just weren't available at the time. Regular squirrel cage motor (albeit low inertia) all of a sudden behaving like a high performance servo. Today, everyone is making 100% electric CNC benders but servos have caught up.
Comments
In SPI mode, yes; Ray is using serial (115200) which is at 100Hz
The generally accepted theory is that; the sample/update rate should be 5 to 10 times the bandwidth of the system.
The short version is that the bandwidth is defined as the time taken to reach 63.2% of maximum velocity.
On some of my bigger stuff (2KW+) where I have inertia and friction, I can get great response and stability @500Hz. The industry standard seems to be 1KHz.
Hardwood floor is harder to get good compared to carpet.
Been trying a lot of stuff to make it stop oscillating, but nothing works so far...
https://www.youtube.com/shorts/A9auAmAQ2cs
It could be that faster IMU updates would help.
Or, maybe the deadzone of the motors is the problem...
Need to look into this one a bit..
Use the encoder to make it move positionally.
EDIT: Oh, found the link, the encoder is probably too low res
- https://www.parallax.com/product/motor-mount-wheel-kit-aluminum/
Linear resolution:
Integrator is having a fit.
Carpet vs Wood floor: The carpet is having a Kd effect (damping).
Possible improvements with existing limitations:
1) Set the integral to zero. I only ever use it at end of motion for eliminating the position error when precision is required. Here, we want stability.
2) Gain breaks: Try multiple Kp settings; at least one for steady-state and another for motion
3) Increase the Kd to further damp the response.
In one test the update rate was halved by code and the wobble got worse. So, thinking there is some hope that higher update rate will help .
Getting that higher rate is something was hoping to avoid…. Lots of murky code to get there…
It's amazing how that works. OMRON PMAC are boasting "fastest in the world", 5-axes in 50 µsecs. I cannot think of an application that could even benefit from this but hey-ho. P2 can better this though
PMAC! I saw brochures for those in the 1990s. It was similar sorts of claims then too - Not that I can recall the actual claims. So Omron has snapped them up at some stage too.
Start by moving everything not the servo loop out of that cog. Anything that takes time to sequence should be moved out, eg: Put all the sensor query code in another cog.
Then both parts can be computed concurrently. The latest reading from the sensor gets used by the servo loop while at the same time the subsequent reading is being fetched. Double buffered in effect.
Yeah, Delta Tau (founder: Dimitri Dimitri) was purchased by Omron. The PMAC has always been high-end and in fact it's what LinuxCNC (EMC2) started-out with before they tried to handle real-time in Linux.
Just always been so darned expensive.
Getting fast updates from BNO08x looks like a real chore. But, think can adapt code from Adafruit and/or Sparkfun...
Or an exciting adventure!
Another approach is to interpolate the data that you can get.
This technique is quite common. Within the 10ms, generate interpolated way points.
Edit: Scratch that....we need the points in order to interpolate but I wonder if there is a similar solution.
There remains the problem of the massive 3.5mm steps though.
I believe that at standstill we need a low Kp to keep it docile and above a certain threshold of error, we kick up the Kp for response. Zero integral.
The integral term is interesting. Appears like personal preference or application need on whether to use it or not.
In this case, if you push the robot with it off, it rolls a bit forward and then stops.
With I term on and you push it, it will roll forward less and then roll back to original position.
I'm liking the I term for now anyway...
Also need to work on startup though with I term. If it is on and then switch the battery to on, it will go bananas...
Think need some logic in there to not activate the I term until the robot is upright.
Got a wireless keyboard coming today. Going to try to use that to drive it around. That could be fun, if it works.
Wanted to use wireless gamepad, but that would mean switching to FlexProp.
Will probably have to do that at some point anyway to use the C code for the BNO086...
Also, kind of wondering if should just add the caster and be done with it... Probably should, but going to play with this some more 'cause it's way cooler.
Yup, that behaviour is called Integral Wind Up. And yes, adding logic to hold and/or reset its accumulation is a done thing.
I've done one solution recently where the operator gets to set it manually if they know a good starting level. It has a capture button they can snapshot the level then use it again later.
A system that employs checking for a "bad encoder" stipulates that the integral must be active because this means that the lsb will be wagging. But in our case, the lsb wagging means jumping back and forth, 3.55mm.
Great minds think alike: I have the option to zero-out the accumulation or to preserve. I deactivate the integrator during motion and activate it at the end of motion profiling.
To minimise the following error, acceleration and velocity feed forwards are preferred (and work beautifully) because they don't affect loop stability.
I recently retrofitted a machine where I found a label stating that the high speed following error should be set <76mm
By the time I was done, 1000mm/sec had 0.2mm max following error.
Yeah, feed forwards are good at that.
That recent system I mentioned is not motion control though. It's pump speed balancing the flow against filling head. The fluid head height being the process value. It's basically a static set point. The purpose is to maintain constant gravitational pressure into the bag being sealed.
Are you using VFDs on the pumps?
I ended up splitting the proportional and integral into separate filters, with proportional operating on a fast IIR filter and integral using an averaging (box) FIR filter that has an operator definable window length. That seemed to provide the needed frequency sensitive tuning without me learning how to do any FFT stuff. It's all in Trio Basic so not super fast.
Yep. Analogue from the Trio to VSD.
For giggles, I grabbed a 2KW "Landrive" from AE....£35.
Totally impressed. It has two modes; VFD and actual flux vector. Flux vector is super nice. I stuck it on a Bridgeport mill and talk about a transformation. We no longer change pulleys but have a speed range from zero to twice the original speed.
There is one hell of an opportunity here for a budding entrepreneur.
I'm ordering another but this time I intend to close the position loop on it. Exciting stuff 👍
I've never had a drive in my hands with vector mode. But then I've never commissioned anything large either for that matter.
In fact I'd always thought flux vector mode required an encoder. Is that not the case?
But that's the neat thing about using the prop; one can get creative. It's a bit slower with the floating point but a heck of a lot faster than TrioBasic. Heck even the Picomite interpreted Basic is three times faster than Trio.
I do similar with dual loop feedback; Proportional and integral from the secondary encoder and velocity control from the encoder in the actual motor.
PS: The main reason why the FIR filter was added is as each bag gets sealed some fluid gets pushed back out and up as the sealing bar pinches to form the closing seal. So the head level surges high momentarily once for each and every pack. We didn't want the pump to be surging in beat with that.
EDIT: However, I think, I never observed it, there was a more unstable oscillation that would creep in without the FIR filter that didn't have anything to do with seal surges. The feed back I've got so far is that pretty much only one window length works. So probably some luck on my part there.
No flux vector is sensorless.
I pioneered 100% electric CNC tube forming. I hold the patent. And this was made possible due to the arrival of flux-vector technology. Servo drives with 40Hp just weren't available at the time. Regular squirrel cage motor (albeit low inertia) all of a sudden behaving like a high performance servo. Today, everyone is making 100% electric CNC benders but servos have caught up.