Does anyone know if the Java classes for the TalonFX are thread safe?
I don’t have a direct answer to your question, but Is there something specific you’re looking to do that we can focus on?
Well, for example, if I want to call getSelectedSensorPosition from two different threads, do I need to do it inside a synchronized block?
Again, I don’t have a solid answer for you on that, but I’m inclined to say yes. Perhaps one of the CTRE devs can chime in to answer
I was just about to ask the same question haha
I just wrapped my entire robotPeriodic method in a thread to prevent some overruns since python is pretty slow and my period is 0.01s. All it does it update odometry (calls getSelectedSensorPosition) and post some stats to the networktables. It seems to work ok. If it were to set motor speeds I’d expect some issues though.
FYI that’s probably not a good idea to have odometry potentially desynced, just testing stuff ^
Because of the GIL, isn’t it counter-productive to add threads?
Do you need multiple threads? You can add periodic functions that run at different frequencies if you need something to run faster.
Yes, Phoenix was designed to be thread-safe.
In Phoenix 5 all getters from the same object share the same lock, so just be aware calling a getter means blocking other getters on the same object. (This usually isn’t an issue since the getters return quickly).
In Phoenix Pro there are no object locks, the libraries are thread safe down to the CAN interface level.
2 Likes
While it’s true that Python is slow, most of the time it should be Good Enough. If you’re having loop overrun issues there might be something silly you’re doing – or something silly that our library is doing. Worth reporting a bug if you can isolate it to a small piece – without bug reports we can’t make it better!
This is very likely and I’m not sure if it actually helps at all.
It does help in the case of quick debugging using print() though since there is an I/O operation happening. Whenever I print something, I often get overruns which are mitigated by wrapping the print in a thread:
def print_async(*args, **kwargs) -> None:
"""print in a new thread"""
Thread(target=print, args=args, kwargs=kwargs).start()
So like I said, not a good idea to wrap the entire robotPeriodic method in a thread, but it could be beneficial in c++ or Java.