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.
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!