Conversation
- added new constant for alternative l4 position (not interchangable w/ regular l4 position) -- the arm position is the same mod 2pi but it is positive - unclear if arm will slam into reef during auto...
- does NOT wait for elevator to be done to move the arm - DOES wait for arm to be in a safe position to move the elevator (I think this does not slow down regular usecase -- intake --> L4 foward)
|
Will this work if (for each coral) we want to swing forward as we drive toward the reef and over the top as we drive away? |
|
No not atm... (I can make it work probably!) Why would we want to do that? |
|
Right now we go over the top so that we can lower the arm before we start driving. If we want to do that with the forward arm, we'd have to support this. Otherwise we have to wait a bit when driving backwards to lower the arm. Plus it would be more robust in general if we could think of a way to support this. Ideally we don't want to limit what motions we can do upfront, if strategy dictates we do all otherwise (this is a good lesson for next). The more important reason: https://youtu.be/w48aiSdYu-c?feature=shared |
|
If 581's code is public they might be useful to look at. |
|
Schedule for testing/improving @amzoeee |
2 participants
I guess I should make a PR about this...
Basically just made a different RobotState for L4 "forwards" that has a positive arm position so it'll move forwards. and changed the logic for getting to that specific RobotState to not include the "arm can only move outside of the frame perimeter when elevator is done" check for speed :>
See my comments on the issue; I'm not convinced that this optimization is super worth atm
needs to be tested because I don't know if it'll run into the reef...