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.
interesting concept, so what your saying is the faster speed between the inertial sensor and the brain will lead to the robot micro correcting during auton thus creating a problematic auton?
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.
The reason I am asking is my son is interested in trying to do position tracking by integrating acceleration. A higher sample rate would be helpful in that regard.
I am aware that this may still be a futile exercise, but it could also be a great learning experience over the summer.
This seems like one of the times where it is beneficial to collect data faster than your control output refresh rate.
Your point is good, but I would say you always want the option of being able to collect faster samples if you have the processing ability to handle them.
The problem of overcorrection/over adjustment can be lessened by, perhaps, taking a moving average of the samples, and only recalculate your control loop every 5. This would help to minimize outliers.
Generally, as long as you can handle it, more data is better IMO
I’m thinking that in most cases, the robot’s reaction time would far overshadow the communication time so far as you don’t have several seconds of communication lag.
I think that faster communications would lead to denser vexnet radio, resulting in more lost connections at competition.
Even with a higher sample rate, the sensor is probably not good enough for a double integration. You will get a lot of error because it’s just a consumer level accelerometer.
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…
