We’re at our first event right now and we’re realizing that we may need to beef up the zeroing on our swerve drive.
Right now, our sweve drive only has relative encoders, witch seem to work fine for accuracy and repeatability, but its our zeroing thats giving us a headache.
We’re using rev controllers, automatic zero-on-limit is on their trello board but not in the lib yet. So we’ve been polling over CAN to retreive when the optical switch is closed. Our main issue stems from the delay/polling time.
If we spin the optical flags on the swerve module too quickly, then we tend to miss them while polling, to counteract this we’ve made the flags much wider to reduce the time in auto spent zeroing, we’ve got a ‘good balance’ of about 3 seconds max to zero all the modules but it cuts some time out.
We’d like to move the flags much faster, the optical switch is faster than our oscilliscope can register and we imagine that the rev encoder port is pretty fast too. We’re looking for advice on things to try, we’re attempting to implement an absolute encoder but its so late in the season.
Right now we’re looking at using a timer to increase the CAN polling during zero, even if it means high can util during that time. I think i recal either CTRE or REV having a CAN priority system/packet streaming?
Would appreciate any and all input, this is our first year trying swerve drive and I think we are learning so much!
That’s unlikely to help much. The issue is that you have to wait on the controller to send its data frame, which is nondeterministic and may have occurred anywhere between 0 and 20ms in the past relative to the current robot loop iteration.
The only way to fix this would be to have a feature to synchronize data frame timing across controllers, perhaps indexed on the RIO heartbeat. That’d be on vendors to implement.
Thats exactly right, running the loop faster with a timer was a thought since we can go quicker than 20ms but it would be risky and might flood the can.
We were hoping rev would implement the trello board feature, and allow us to configure for zero-on-limit where the controller dosent need to send the data back but can do it on its own but it seems like thats not happening and idk of another workaround.
If you are at event right now, it may be very hard to get this to work in time. You might want to consider manually orienting them to whatever you consider “zero” before each match, and then just have the software assume that you’ve started at zero. This will be annoying, and something you need
To remember to do each time, but should work just fine until you have time to implement a better approach
This is what we ended up doing for this event. Right now as long as the module is closing the zero sensor, it dosent move it just asumes you’ve lined it up. Thats how we got thru this comp
2019 i think.