# Regarding Loop frequency

Why is it that the loop in the Iterative Robot base runs at 50Hz? What would hypothetically happen if a different frequency was used? Just an educational question, purely theoretical.

Don’t quote me on this, but I believe that it runs at 50hz because that is how often the driver station sends packets to the robot.

If you are using Java or C++, it is entirely possible to create a separate thread that updates at a higher rate, and many teams do so - this is beneficial because a higher update rate gives quicker responses, which is especially important in control loops. Another reason to do this is for more accurate estimations. If you are trying to approximate the integral of a sensor value, say, integrating angular velocity from a gyro to keep track of the robot’s angle, you are going to be using a Riemann sum. Logic dictates that the smaller the value of dt (the higher the sampling rate) the more accurate the results.

Thank you,
Although, what would occur if you set the main loop’s frequency to something high like 200, would that affect control of the robot in anyway?

The main issue would be that you could do less each iteration. With a 50Hz rep rate, you get 20[strike]0[/strike]ms to do what you have to do. With a 200ms rate, you only get 5[strike]0[/strike]ms. It’s also entirely possible that the 50Hz rate is controlled by a hardware timer; I’m not familiar with the internals.

And I concur with Alexander and Jared below that 50 Hz would not be noticeable lag from the controls, though higher rates would be in order for many PIDs and other sensor-driven activities.

Yup. All the important stuff like PID loops in our code were all run separately at 200hz. You don’t really need to be getting info from the driver station more often anyways. I can’t imagine drivers would notice the increase in “framerate.”

20ms and 5ms, respectively.

The roughly 50Hz loop in *Periodic() is called every time you receive a driver station packet. This is great for mapping gamepad inputs to speed controllers and solenoids, but not great for doing timing-sensitive things like PID

control.

It is also worth considering having slower loops. The rate of a given loop should be appropriate for what the loop is measuring and what it is controlling. 50Hz was selected because the human with the joystick and buttons is giving input, and that is a reasonable speed for updating the robot from those inputs. Some control or state machine loops would benefit from running faster, others will work fine if run slower than 50Hz.

You also need to account for the amount of time that a loop takes to execute. Even though a camera can produce an image every 33ms, that doesn’t mean that you can process the image in that amount of time or need to process every frame. So it may be useful to run an image processing loop at 10Hz – be sure to process the most current image and not an old one.

If you want the equivalent of a thread in LV, simply make a parallel loop as shown in Periodic Tasks, or consider making it a Timed Loop if you want less jitter.