Alright children, I have a background task for you. We have finally found the source for our problem on our first playoff match at INPLA and our practice match in INMIS. So it is related to the CAN cables that weren’t in all the way on the RIO, but that’s only part of the issue. The fault lays in our code, and it’s a math Util we borrow from someone else. Specifically it’s this line and the while loop directly below it, and REV being REV. When there’s an issue with out CAN bus, the spark maxes can sometimes come back by giving us crap data. And it can either send us one frame of crap data, or it will permanently be giving us crap data.
What does this mean? This keeps track of how many total rotations the encoder has made, and then finds the closest equivalent in a 360 degree turn. Well if the encoder counts are like 2000 counts for example, and we get a crap value of like 10,000,000, then the while loop I linked above is going to take over all our CPU adding 360 at a time to get close to 10,000,000 :)
So, obviously fixing our CAN connection was step one, but this won’t prevent it from happening again, just less likely to happen. We should probably validate the encoder counts vs the cancoder, or just only use the cancoder. Regardless, whatever solution we use, we need to modify that while loop to either not exist, or be bound. Another smarter way we could do this is just do a modulus 360 to get the value we’re looking for? These are just thoughts, we need a better plan, but I want y’all to start thinking about them. We have other things to work on, but we should be fixing this in the background
Alright children, I have a background task for you. We have finally found the source for our problem on our first playoff match at INPLA and our practice match in INMIS. So it is related to the CAN cables that weren’t in all the way on the RIO, but that’s only part of the issue. The fault lays in our code, and it’s a math Util we borrow from someone else. Specifically it’s this line and the while loop directly below it, and REV being REV. When there’s an issue with out CAN bus, the spark maxes can sometimes come back by giving us crap data. And it can either send us one frame of crap data, or it will permanently be giving us crap data.
What does this mean? This keeps track of how many total rotations the encoder has made, and then finds the closest equivalent in a 360 degree turn. Well if the encoder counts are like 2000 counts for example, and we get a crap value of like 10,000,000, then the while loop I linked above is going to take over all our CPU adding 360 at a time to get close to 10,000,000 :)
So, obviously fixing our CAN connection was step one, but this won’t prevent it from happening again, just less likely to happen. We should probably validate the encoder counts vs the cancoder, or just only use the cancoder. Regardless, whatever solution we use, we need to modify that while loop to either not exist, or be bound. Another smarter way we could do this is just do a modulus 360 to get the value we’re looking for? These are just thoughts, we need a better plan, but I want y’all to start thinking about them. We have other things to work on, but we should be fixing this in the background