Not sure if this is a bug in phoenix/the canivore firmware or if it’s a problem with our device. So, I was wondering if anyone else has been experiencing this issue.
Basically, the first time that the robot is enabled after code starts running, the CANivore will stop communicating with all devices on its network for a few seconds, then continues normally. This doesn’t happen after subsequent enables, just the first one.
So, for example, if we enable the robot and immediately try driving, the robot will remain stationary for a few seconds then start driving once communication resumes. This happens regardless of the device. Our CANdle LEDs will turn off on loss of signal and then come back on a few seconds later as well.
Everything works properly before the first enable as well. We can read sensor values, control the LEDs, etc.
I’m not able to reproduce this.
Could you provide a list of devices that are on your CANivore bus?
Could you also try running one of our examples? I connected a CANdle to my bus and ran the CANdle example myself. I never see the status LED indicate no-communication when I enable from it.
We have 11 TalonFXs, 6 CANCoders, and one CANdle. I’m not sure if its technically “no communication” or if it just stops sending commands to the devices. Next time we are with the robot I can try seeing if we still get sensor readings during this period or if it stops communicating both ways. I can try one of the examples as well, but this has been an issue for a while even with simpler code on a test drive train. Also noticed this when our code for the CANdle was essentially just copied from the example.
Edit: Another thing, we are using “*” for the bus name in code, not sure if this could be part of the issue, but I will try hard coding the device name as well.
Quick update, I was able to reproduce this using the differential drive example.
The CANivore name you use in API doesn’t affect this, we’re working on figuring out the cause right now.
While we wait for a potential issue, is the work around to redeploy code each time? As you can imagine, we’re in the throes of troubleshooting and don’t need this to be a red herring for us.
The issue I see is that the first time you enable after deploying code, the motors will turn for a split second, neutral-out for about a second, then continue. Subsequent enables don’t cause this behavior, so the workaround should be to do a dummy enable after deploying code.
I’m working on figuring out exactly when this occurs to pin down a cause right now.
I was able to reproduce this without any CTRE references at all, it looks like this can occur if you use a WPILib drivetrain class and perform string concatenation from my testing.
I put up a WPILib issue here
It looks like the robot itself disables for a second on enable, which should affect all motor controllers. If you have more insight let us know here or in the issue tracker.
That’s super weird. Thanks for your help with this. Although, I feel like it has to be more than the robot disabling itself because of how our LEDs on the CANdle were working. When this issue occurs, the LEDs turn off from LOS. They work fine while disabled normally. Instead of the robot disabling, could it be freezing the whole robot code application, causing the LEDs to turn off since they aren’t receiving any commands anymore?
The requirement for string concatenation is whats really messing with my head… all i can think of is that WPILib adds a JVM flag that changes the string builder implementation (I think…? I’m not certain what that flag does). If this is reproducible in C++ as well, then im at a complete loss.
So perhaps a workaround here is to do some random string concatenation in robotInit to get the initial invoke out of the way, then anything done on enable should be fine?
Depends on whether the delay is incurred once for any string concat or once for each unique string concat. We wouldn’t be able to work around the latter.
