Shooting while driving 😵

[GalexY727]

Oh boy, where do we start...

[GalexY727]

I suppose we can start with a rapid react shooter proved example and also mention a crescendo shooter's theoretical example

Also here's orbit's behind the bumpers for 2022 and a ChiefDelphi thread (or two) on the topic.

[GalexY727]

Don't you worry, I got the resources on lock down

[Jacob1010-h]

Ok, well, let's begin by documenting what has been done already...

Thanks to @Oliver-Cushman, we have a basic implementation already of a command that continuously aims until told not to; however, this probably won't be the final product as we will need to take into account the following pose predicted at the time of the call.

    /**
     * The function prepares a command to fire at a stationary target while moving
     * and continuously aiming until
     * instructed to stop.
     * 
     * If we are currently aiming, toggle aiming to false, cancelling repeated calls
     * to prepareFireCommand
     * If we are not currently aiming, toggle aiming to true,
     * and repeatedly run prepareFireCommand until aiming is toggled to false
     * Allows for toggling on and off of aiming with single button
     * 
     * @param shootAtSpeaker A BooleanSupplier that determines whether the robot
     *                       should shoot at the
     *                       speaker.
     * @param swerve         The "swerve" parameter is an instance of the Swerve
     *                       class. It is used to access the
     *                       current pose (position and orientation) of the swerve
     *                       mechanism.
     * @return The method is returning a Command object.
     */
    public Command prepareFireMovingCommand(BooleanSupplier shootAtSpeaker, Swerve swerve) {
        if (aiming) {
            return Commands.runOnce(() -> toggleAiming());
        }
        return Commands.runOnce(() -> toggleAiming())
                .andThen(prepareFireCommand(shootAtSpeaker, swerve.getPose())
                        .repeatedly()
                        .until(() -> !aiming));
    }

[GalexY727]

The only problem to think about, however, is the added initial velocity that our bot will have after shooting. For example, if we are moving backwards relative to the speaker, we will want to shoot faster to compensate for the fact that we are moving away from the speaker.

[Jacob1010-h]

If we assume that our shooter is up to speed, all it should take is a calculation of the current velocity of the bot and then adjust through interpolation for the next time we take the bot's position (next loop time).

If we are planning on doing this with swerve, though, then we should implement a twist and log to take the next position at t.

@GalexY727 can you post the demos in for easy access (regardless if this is a viable option)

[Jacob1010-h]

The only problem to think about, however, is the added initial velocity that our bot will have after shooting. For example, if we are moving backwards relative to the speaker, we will want to shoot faster to compensate for the fact that we are moving away from the speaker.

I think that shouldn't be that hard, I would like to think about this more once we have a bot, but I would like to make a map of speeds and angles relative to the speaker to interpolate between, based on t

[GalexY727]

Pose::log and Pose2d::exp desmoses

[GalexY727]

Integrating position is as easy as how it is done in discretize, which is just making a twist based upon our swervemodulestates and integrating them by that dt

[GalexY727]

If we found a way to get the initial velocity from the note the moment it leaves the shooter, then we might be able to tell the shooter to go to the speed required to get the note to that desired initial velocity which we then could be able to plug into a calculator like this that finds the required initial velocity/angle for any position on the field.

[GalexY727]

We then take the output of the calculator and subtract away our robot's velocity relative to the speaker to get what extra velocity the shooter needs to fulfill.

[Jacob1010-h]

This seems good, however I never like the idea of putting everything into a table, so I think we could look for a different solution, Ill look at this more tonight.

[GalexY727]

3903165

[GalexY727]

And that concludes my 3 am coding session. @RudyG252 did i do good?

[Jacob1010-h]

who is bro 💀

[Jacob1010-h]

i guess im not looking at this tonight 😭 WTF!

[GalexY727]

I quickly realized the hardest part about this is converting motor rpm to note initial velocity. I hope it's just an AP physics problem. Even if it is, Davis probably wouldn't know 🗿.

[Jacob1010-h]

This was solved a bit ago, we landed on a solution in which we use an interpolation map for the speeds and calculations for the turning of the robot and pivot.