Advanced Shooter Behavior
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Domain
- robotics
Research direction
The issue names no files, tests, or entry points. Start by locating the robot's cowl and flywheel controls, then review how distance and ball trajectory are currently handled. Done would require a validated shooting model or lookup table that reliably reaches the upper goal across relevant distances and settings.
Written by the indexing model from the issue text.
Description
This is gonna be a toughie, how do we get the ball to the upper goal? Once again, Pratham, Shawn, and Kenneth have some theoretical equations (and so does Andrew/Ryan) for this problem, but there are a few things we need to get right before this happens. We need to somehow accurately know what angle the ball will release from the robot based on the cowl angle and the flywheel speed, which is not as linear as one would hope (or at least, it wasn't on M14). An idea I had for this was to use something like this (https://markrober.store/products/40mph-speed-square-blanket) to record data (like in slow motion video) about the ball's trajectory based on cowl and flywheel speed, then create a table or hopefully a nice equation to find the ball's angle. While this is technically empirical, it would be actual data instead of just guess and check, and could give something genuinely useful. Of course, we also need to accurately know the distance from the target for this to be useful information.
I wouldn't want to do this, but if this is inaccurate enough, we might have to do the good ol' look-up table converting from distance to cowl angle and flywheel speed based on empirical testing. I would love to actually have some sort of sophisticated approach to this, because this would allow for much easier shooting while moving implementation, but this is a very real possibility.
- Dominant language
- LabVIEW
- Stars
- 2
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from MARSProgramming/M15
-
better method/nice to have
Difficulty 4/5 3-5 days Newbie friendliness 30/100
MARSProgramming/M15#17 ·
-
vital
Difficulty 3/5 1-2 days Newbie friendliness 42/100
MARSProgramming/M15#16 ·
-
vital
Difficulty 3/5 1-2 days Newbie friendliness 35/100
MARSProgramming/M15#15 ·
-
vital
Difficulty 3/5 1-2 days Newbie friendliness 25/100
MARSProgramming/M15#14 ·
-
vital
Difficulty 4/5 3-5 days Newbie friendliness 25/100
MARSProgramming/M15#13 ·
All issues in MARSProgramming/M15
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
status:needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
PX4/PX4-Autopilot#28776 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
gazebosim/gz-sensors#662 · 1 comment ·
-
diff_drive_controller keeps warning about a timed-out velocity command while the robot is parked Open
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
ros-controls/ros2_controllers#2619 ·