FRC2706 / 2019-2706-Robot-Code

The main robot code for the FIRST 2019 challenge: Deep Space
MIT License
2 stars 0 forks source link

Rcvi laser #161

Closed robertlucyshyn closed 2 years ago

robertlucyshyn commented 5 years ago

Summary of Changes

Note: This is not intended to be merged for Provincials. It has been tested to work on the practice bot, but a some tuning and drive experience would be needed for it to be of use in matchplay. A lot of work has gone into getting the laser rangefinder to work, and I want to make sure this work is not lost. I heard about some rule to the effect that if a piece of code is not made publically available to other teams by the end of a season, then it cannot be reused the following season. I don't know if this means that it has to go into the master branch. If this is the case, this code should be merged prior to the end of the season. Note that this functionality currently does not have a regression test for it. I am hoping that @KyleRAnderson can provide assistance with that regression test when he is available after competition.

This pull request provides the DriverAssistLaser class that, at the request of the driver pressing the "Y" button on the driver controls, will use the Motion Magic class to drive straight ahead and stop in front a target using the distance measured by the LidarLiteHP sensor. This pull request also include the LidarLitePWM driver class for the LidarLiteHP sensor running in Pulse Width Modulation (PWM) mmode.

Relevant constants defined in Config.h are:

TARGET_OFFSET_DISTANCE_LASER: Final distance between robot and target. LASER_DISTANCE_MAX: Maximum distance over which command is ignored (to prevent a runaway robot). LASER_CALIBRATION_OFFSET_CM: Calibration constant (in cm) for LidarLitePWM driver class. (The sensor works in cm but these are converted to feet for the robot code.)

For Deep Space, this functionality would probably work best to fine tune the final distance once the robot is aligned with and within a couple of feet of the target. Using it at longer distances is more difficult because there is the danger that any small misalignment could make the laser go through the target "hole" and give an erroneous distance reading. It also might not be good to approach a Loading Bay because it is made of plexiglass and the sensor apparently does not work well on that material. It would be useful in any situation (or future game) where the robot needs to position itself quickly in front of a broad target.

Testing Performed

Environment: Practice bot Tested that robot will execute of 1-d Motion Magic forward movement up to and in front of a target based upon the distance of the target measured by the laser rangefinder. Also tested that command is ignored is outside the minimum and maximum distance defined in the Config file.

KyleRAnderson commented 5 years ago

Sorry, it's been a while since you originally sent the email @robertlucyshyn but it somehow got buried in my inbox.

I think in this case verifying all the method calls to the talons would both be difficult to set up and difficult to maintain, so without knowing the rest of the situation I would say it would be ok to mock only the MotionMagic class and then make sure that it is constructed and started with:


@Test
public void someTestMethod(@Mocked MotionMagic allMotionMagics, @Mocked MotionMagic magicInstance) {
    new Expectations() {{
        magicInstance = new MotionMagic(args...);
        times = [number of expected invocations];
    }}

    doSomething();

    new Verifications() {{
        magicInstance.start();
        times = [number of expected invocations];
    }}
}

Depending on the exact situation I may come up with a way to do this without mocking, but for now this is ok I think.
robertlucyshyn commented 5 years ago

Ok Kyle that sounds good. Thanks!

Sent from Yahoo Mail for iPhone

On Thursday, April 18, 2019, 4:55 PM, Kyle Anderson notifications@github.com wrote:

Sorry, it's been a while since you originally sent the email @robertlucyshyn but it somehow got buried in my inbox.

I think in this case verifying all the method calls to the talons would both be difficult to set up and difficult to maintain, so without knowing the rest of the situation I would say it would be ok to mock only the MotionMagic class and then make sure that it is constructed and started with: @Test public void someTestMethod(@Mocked MotionMagic allMotionMagics, @Mocked MotionMagic magicInstance) { new Expectations() {{ magicInstance = new MotionMagic(args...); times = [number of expected invocations]; }}

doSomething();

new Vericfications() {{
    magicInstance.start();
    times = [number of expected invocations];
}}

}

Depending on the exact situation I may come up with a way to do this without mocking, but for now this is ok I think. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.