We are all excited about new parts and interfaces and making the existing interfaces faster.
Because faster is better right? Teresajude posted this:
Which is a great question. We have this super fast hardware that we paid millions for after waiting forever, so I want to see some scorched silicon happening.
But lets think about time vs data. Early in my robot life I used a device that gave you data about every 20 milli second, about 50 times a second. And you think thats slow since you can get server lag times at that speed but the packet is going across the USA, 2000 miles vs 5 feet.
The question should be, is it fast enough, do I care? A robot with 4" wheels on a motor that runs 100 RPM moves 100 feet in a minute and 1.6’ or 20" per second. If I get a reading from a device 50 times a second, I get a reading every 1/4". So at a 50Hz reading, I get a number every 1/4".
You can make a change every 1/4". Think about the wheels, floor tiles and the friction, the mass of the robot and it’s center of mass. Changing something every 1/4" could be overkill. Within the parts that we have, any big change is going to be fighting the robot to make that change. At 100hz it’s every 1/8th inch
If you ask for data, you should use it. Moving a robot around a 12’ area is much different than a car (88 ft per second) or a space craft (5 MILES per second).
I’d rather save CPU cycles now and not get data as fast, and use them later for the new LIDAR, short distance ultrasonic, and the infrared that measures robot to robot distance. That lets me do on the fly route planning.
I’m saying that there is a limited amount of useful correction that can go on. Increasing the sample rate sounds good, but at some point you have far more samples that you can actually use.
I got a PM asking what about shooters trying to dial in a speed? I’d be using a PID to do that but I don’t think I’d need more than 50 samples a second to get it there. I have to deal with inertia to speed it up and down. Get the speed sample, decide how much to change, change it, wait for the motor to react, wait for the flywheel react, get another sample. 50 times a second is a lot of possible knob turning by the PID.
You are right in general. I’d add a general rule of thumb that the smaller the system, the faster it needs to act. It is easier to build a huge self-balancing robot (think Segway) than a small one (IQ balancer or similar-sized toys).
Physics is somewhat slow for large/heavy objects
Having said that, teams often use 200rpm cartridges and you need to take into the account all the latencies in the control loop (sensing, receive, algo picking up the values, computing output, those being picked up by the motor MCU, …). Great programmers would be able to take the available physics into account and already shoot at the expected,extrapolated future (that’s pretty much what the Kd does in PID already), but working with the best signal you can get has other benefits besides tight control loop.
You can use the excess bandwidth for oversampling, more advanced filtering and whatnot…