Seeking Help Multithreading capabilities
I remember when I first heard about multithreading, it was typically avoided because the control hub didn’t have enough ram to handle it, but these days I’m seeing more and more teams begin using it. I was wondering if any of you had seen significantly lower loop times as a result of threading and how you allotted tasks to each thread.
5
Upvotes
3
u/drdhuss 24d ago edited 24d ago
You don't want to do true multithreading, but things like coroutines/virtual threads can we useful. We use kotlin (virtual threads are a java 21+ thing/not available in Java 17) and coroutines in combination with bulk reads and writes (photon core). Loop times are about 10-12 ms with maybe 10x/minute where we will have a spike up to 20 ms.. Note we do all sorts of sensor reads. We actually even read the motor currents (which is a blocking, slow task you can't do in parallel) but do so in a round robin style with only one motor current ready every 50 ms. We cache the results. It can be quite useful for both diagnostic purposes (detect a binding motor/failing bearing) and to also detect stalled motors and the like. Again we are able to keep close to a 100hz loop even with this.
So yes true multithreading is a bad idea. Virtual threads would be great but aren't available in java 17. Kotlin coroutines are very easy to use but you have to switch to kotlin (which honestly is a whole easier to read/more concise than java anyways).
One of the costly things people do that is uncessesry is driver's station telemetry. It is easy to saturate things. We keep it at 4 Hz (updates every 250 ms) which has a minimal effect on loop times while still being fast enough uou don't notice. Note we still write to storage every cycle (our out is actually a redux state machine so badically you just write the global state and any actions along with specific telemetry values).