We got LimeLight detector recognizing the notes reasonably well (thank you for the folks that posted the models!!!)
We also have auto-navigation working reasonably well, including dynamically generated trajectories.
The question I have - what do you think would be good strategies for the notes? The point is - because the detector will generally give you a Positive for the partially visible note, I am not sure that the horizontal size of the target box is a good indicator of a distance from camera to the note (thoughts on that?)
Here are some examples I could think of:
- See the note - turn intake to the note, run towards the note with low, medium or high speed, depending on the possible distance with the intake out and ON.
The downside - for partially visible notes the distance would be perceived larger than it really is. So, the turn needs to be done first and then the run. Also visibility of the note needs to be re-evaluated in case it was missed or disappeared. I have seen that LL3 can do so with 80fps, which is very impressive. We have LL2+, and get about 30-40fps on that with Coral. Not bad, but could be better.
- Just turn towards the note and leave the rest to the drivers
- Indicate there is a note, but do not do anything
Any other strategies you can think of that can automate note pickup?
If you had some luck with the distance detection, and can share the code or at least a strategy, that would be much appreciated as well.
We’re trying to do option 2, just rotate the robot so the intake is pointing at the note, and leave the rest to the driver. I’m wary of letting the robot drive as well, since the note positions are variable, and the robot could get itself into trouble. And testing time during the season is limited.
I do plan on trying to automatically drive to known locations though, like the amp.
Thanks. Yeah, we already tested driving the robot from ANY location to the known ones. That part is working fine now.
All our auto-driving commands for teleop are interruptable (you let go of the button - the robot stops), so we have safety in mind. However, I am still debating whether to pickup the notes.
The point is - our drive in teleop by default is field-centric. So, even if I turn the robot towards the note, that’s not going to do much for the drivers, except they can switch to robot-centric and just drive forward (we have that as well). So, my question is - whether just turning the robot towards the note improves the cycle speed in any way. I mean - it’s interesting feature, but from a usability point of view did not seem that critical. Thoughts?
I think it still helps, assuming the detection range is wide (width wise). So the driver doesn’t have to do that last bit of rotation toward the note, the driver just has to have it sorta facing the right way, and the robot will do the rest. But yeah I understand what you’re saying.
And we’ve done the same for our pathfinding methods, from any point on the field, to known ones. The driver must hold the button, once let go, the robot stops.
We’re using field-centric driving as well.
I do think driver feedback is important though, so that the driver knows if the robot has detected a note and is auto-aiming, or hasn’t detected one, and its in manual mode.
Well, LL2+ could detect a single note in our testing from about 4-5 meters away reasonably reliably. With multiple notes we had a little increase of lag, but not terrible. Also it seemed not to affect detection of at least one of the notes, even if one was partially on top of the other.
How do you feel about medium-speed drive towards the note? We decided not to deal with A* path, so just a straight path. Our intake (over-bumper) is likely to survive a lite-to-medium head-on hit, and has separate protection against side hits. We also moved most major components, such as motors, off it (at the expense of additional belts, less space for electronics etc) to try and make hits less damaging.
We will have SmartDashboard indicators that a note is visible.
Hmm, that sounds alright. I think I’d still want a manual intake button too, just in case the driver wants to intake without the automation.
And I think controller rumbling is more effective in this case, so the driver doesn’t have to glance at the screen to know if the robot detects a note.
We plan on rumbling one side of the controller while the intake button is held if a note is detected, then rumbling the other side when the note is fully intaked and is at the beam break sensor, to indicate to the driver that the intake operation is complete and the driver can release the button.
1 Like
Did not think of that! Forgot that these things can rumble as well. Definitely will try adding that.