CTRE Phoenix 5.14.1 performance improvements?

ctre
#1

A new Phoenix update was released today:

The release notes only state “performance improvements”: https://www.ctr-electronics.com/downloads/release_notes/RELEASE_NOTES

Anyone have any insight into what has actually changed? It seems rather odd to be getting a library update in the middle of competition season with only “performance improvements” without anything expanding on that.

I did a diff of the Java API source - basically no changes except to the docs for BaseMotorController#set, and declaring a new JNI function that doesn’t seem to be used.

We are experiencing a lag issue in our code
#2

Just posted.
https://phoenix-documentation.readthedocs.io/en/latest/blog/blog-perf.html

Took me longer to write the blog post than first thought- it ended up being more comprehensive than I originally planned - but I think that’s better for teams.

4 Likes
#3

As I read the blog post, I could not help but wonder if some of the timing issues could be attributed to multiple vendors using the CAN bus. Different protocols could theoretically cause timing issues or worse noise on the bus.

Thank you for being mindful of our needs and trying to find a fix.

Thus far we have not seen noticeable issues, but are still periodically getting the watchdog not fed error. We have 9 ctre devices (5 talons, 2 Victors, the pdp, and the pcm) and 3 spark maxes on the CAN bus.

Another hypothesis is that perhaps the increased use of cameras has put a strain on the CAN bus. While I know the Rio should be better than this, I think both the beagoebone and raspberry pi share the CAN bus with the network controller.

I am not an engineer mind you so this is merely conjecture.

1 Like
#4

Perhaps you could help the community determine what conditions might cause calls to NetComm to slow down to several milliseconds. You mention you have a number of various CAN devices.

There’s also an open issue about solenoid calls potentially being slow. Likely related, given the PCM is also a CAN device:

The large majority of cameras don’t have a CAN bus connection (in fact, I’m not aware of any that do).

Neither the Beaglebone Black nor the Raspberry Pi come with anything to connect to a CAN bus.

1 Like
#5

Thank you. We will keep an eye on behavior and share anything we learn. Also, thank you for the observation about the PCM. This is our first year running Pneumatics and though we know it is on the CAN bus, I did not think it would be too much of a potential conflict. It is good to know to be aware.

The beaglebone black does have CAN bus logic on p9 24 and 26, but only the logic. One has to add the circuit. On the beaglebone blue, they included the circuit as well. I was totally mistaken about the pi though, they do have hats that add one though.

#6

Omar,

Has CTRE looked at using the Netcomm stream session calls to improve performance? It essentially returns an array of matching frames. If you set the ID/mask so it returns all CTRE frames, you would only have to call netcomm once per control period, for all devices. Unfortunately there is no equivalent for sending frames, so you still need individual calls for Set.

Also, could you add an output to report the timestamp of data when it is returned? I know the library outputs an error when the frame is “too old”, but reporting the actual timestamp would be nice.

Andrew

#7

This update appears to have massively improved performance for our specific setup. I’ve been scratching my head all season for why Phoenix CAN calls took so long (compared to our setup last season) and this update has been a huge improvement. Using a barebones program, this update has turned get calls from taking 0.4-3.8ms to often less than 0.2ms!

#8

Your setup last year should take the same amount of time or less if using any of the Phoenix releases from this season, notwithstanding the again improved results with the recent release.

Perhaps you are calling more getters than previous seasons, or have more Phoenix devices? I have no reason to think our stuff would be slower this season than last season. Unless your program has some fundamental changes compared to last year (threading strategy or higher CPU for other reasons).

#9

When comparing between seasons, it is certainly possible that my CPU usage this season is much higher and causing the issue (though I believe my actual ‘get’ calls have remained about the same and my threading strategy has not changed much).

Perhaps there is something with my setup that has drastically slowed things down but that this update largely counteracts. The only solid data I have is the difference between early season and now (though it could have been due to WPILIB/roboRIO image). Either way I was very happy to install the update and see my thread sit at a consistent 10ms instead of 20ms. Thanks for all the work you put into software + support :smile:

#10

Thanks for this update! We were receiving nearly continuous loop messages before, and now we get just a few. Not only does it clean up the log, but it also makes us feel a lot better!

#11

Just be be clear, we don’t have to update the firmware on the talons, correct?