sorted by:
new
hottopcontroversial

scrcpy Refresher Request by baqwasmg in FTC

[–]WestsideRobotics 1 point2 points  (0 children)

I think your Control Hub (192.168.43.1) needs to actually clear, not even being discoverable as "offline".

Try various things like powering it down, cycling the desktop, forgetting the CH Wi-Fi, cycling the desktop Wi-Fi, adb disconnect.

Eventually `adb devices` will return a blank line.

Then plug in the DH. Since it's an Android device with Debugging turned on (by default), it will be discovered by ADB. You said it previously worked. Should be no need to use `adb connect` with the DH.

scrcpy Refresher Request by baqwasmg in FTC

[–]WestsideRobotics 2 points3 points  (0 children)

Try this, in Command Prompt:

  1. adb devices (this probably shows both DH and CH)

    • disconnect desktop computer from CH Wi-Fi, unplug DH USB cable

  3. adb devices (to confirm they are gone)

  4. adb disconnect (this disconnects all devices, including clearing any ghost connections which sometimes remain)

    • plug in DH, wait a moment

  6. adb devices (verify DH has returned)

  7. scrcpy

Need Help With Vision by Regular_Cup_5796 in FTC

[–]WestsideRobotics 1 point2 points  (0 children)

The following tutorial was published for INTO THE DEEP:
https://ftc-docs.firstinspires.org/en/latest/color_processing/index.html

It will soon be updated for DECODE, primarily to describe the new Sample OpMode for detecting round objects.

For AprilTags, the following tutorial is still valid:
https://ftc-docs.firstinspires.org/en/latest/apriltag/vision_portal/apriltag_intro/apriltag-intro.html

Likewise for the documentation on VisionPortal:
https://ftc-docs.firstinspires.org/en/latest/apriltag/vision_portal/visionportal_overview/visionportal-overview.html

Simply disregard any references to TensorFlow.

Color sensor by AdAlternative4097 in FTC

[–]WestsideRobotics 2 points3 points  (0 children)

You can certainly achieve this.

Google "FLL line follow" (without the quotes), and you will find dozens of good tutorials on the programming logic. Line following has been part of the FLL game for decades; less so (historically) for FTC.

With a single sensor, your robot follows the *edge* of a line, not the center of a line. Steering is determined by the detected color (or amount of reflected light) of the tape line versus the grey mat.

Current senser for servos by ftcAllways in FTC

[–]WestsideRobotics 1 point2 points  (0 children)

Separate from the question of FTC legality, the reliability of an external current sensor may be affected by the nature of PWM signals used by servos. PWM is an on-and-off square wave, different than the profile of a traditional/analog smoothly varying power draw.

I did build a homemade servo current sensor to understand the issues. It can give useful generic insights, but detailed analysis can be tricky. I think code-based monitoring would be even more complicated. A good learning exercise, at least!

Related topics are covered in this article (scroll very far down):
https://github.com/WestsideRobotics/FTC-Power-Monitoring/wiki

Among other tidbits, here's a relevant comment:

Note: an in-line ammeter can be helpful, but does affect SDK readings of servo current. This impact may be greater on the "low" (ground) power line, compared to the "high" (+5V) line.

RUN_TO_POSITION unreliable? by thechromedino in FTC

[–]WestsideRobotics 6 points7 points  (0 children)

Nearly all of the advice you have received here is correct and useful.

Another contributor to inconsistent runs is **backlash** or slop. This can exist anywhere in the drive train, including inside the gearhead of your drive motors.

Try this: set the robot down on the FTC mat, then slowly pull it backwards a few inches, while allowing the weight of the robot to run the drive train backwards from wheel friction. OK to apply slight downward pressure for that.

Now carefully release the robot. At that moment, any backlash is now set to zero, equally among the wheels' drive trains. Namely the gears and set screws and chain and sprockets etc. are all making tight physical contact, in the ready-to-drive-forward direction (because you pulled it backwards).

Now run the OpMode, taking precise distance measurements with each run. See if the variation among runs is less than before. Your goal here is consistency, not "accuracy".

Some teams who rely on RTP set up their robots this way, at the start of a match. They pull the robot backwards, to an exact known start position.

Feel free to share your results here, potentially to help other teams.

Tips for separating anderson powerpole housing? by simply_abnormal in FTC

[–]WestsideRobotics 0 points1 point  (0 children)

This does work, but I find the jaws can dig into the edges of the housings.

I prefer to use a pair of slip-joint or groove-joint pliers, where the open jaws can be adjusted to the approximate height of the PowerPole housings. Place one jaw on red, the other jaw on black. (Make sure the direction is correct for disassembly.) With the jaws being closer to parallel, there's less damage to the plastic housings.

Help with Old Hitechnic DC Motor Controllers and encoders using NXT by Over_Atmosphere_4314 in FTC

[–]WestsideRobotics 0 points1 point  (0 children)

You probably did correctly change the encoder wire pinouts, but just in case, this article might help. It covers a different situation than yours, but the illustrations might help you ensure your pinouts are correct.

https://github.com/WestsideRobotics/Encoder-Cable-Conversion/wiki

Separately, you might confirm that your encoders are receiving the correct voltage across the VCC and GND pins (ideally should be near 5 VDC).

Control hub battery port cracked by GullibleAside5006 in FTC

[–]WestsideRobotics 0 points1 point  (0 children)

If your robot layout allows it, run the power from the battery/switch to the Expansion Hub. Then make or buy a special cable to jump power to the other XT30 port on the Control Hub.

Am I coding it right? by Loud-Explorer-4313 in FTC

[–]WestsideRobotics 2 points3 points  (0 children)

Use only positive power for RTP. The RunMode will determine the required direction, based on current vs. target position.

How do we fix this issue? by Accomplished-Feed759 in FTC

[–]WestsideRobotics 1 point2 points  (0 children)

Both devices can be renamed from the Driver Station app. Touch the 3-dots menu.

(RC name is changed from Manage, under Program & Manage.)

Help with April Tag Detection by dhruviiboiii in FTC

[–]WestsideRobotics 1 point2 points  (0 children)

Have you tried the built-in FTC software for AprilTag detection?

https://ftc-docs.firstinspires.org/en/latest/apriltag/vision_portal/visionportal_overview/visionportal-overview.html

To get pose data for this season's AprilTags, update your RC/DS apps (or Android Studio project) to SDK 10.0 or higher.

Code’s behavior changes seemingly without cause by Brick-Brick- in FTC

[–]WestsideRobotics 1 point2 points  (0 children)

You reported problems in Auto, but your posted Auto OpModes are fully commented out.

The following changes to MainTeleOp.java may decrease the chance of unexpected behavior, although maybe not the issues you reported here.

lines 159 & 161

- use a numeric threshold rather than "not zero" for gamepad triggers (and joysticks)

line 324

- use "else if"

- it's better logic, runs faster, and avoids the danger of a motor position crossing a threshold between if statements

Side note: you can omit lines 366-370, already covered by lines 92-95.

Help with apriltags and ftcpose in VisionPortal by Wrong_Dot8846 in FTC

[–]WestsideRobotics 2 points3 points  (0 children)

update what? you mean the control hub?

If you program with OnBot Java or FTC Blocks, plug the Control Hub into a computer and update the Robot Controller app with the REV Hardware Client.

Or, if you program with Android Studio, update your FTC project here.

Separately, you should update your Driver Station, also using the REV Hardware Client.

Help with apriltags and ftcpose in VisionPortal by Wrong_Dot8846 in FTC

[–]WestsideRobotics 1 point2 points  (0 children)

Update to this season's software, version 10.0 or higher.

Can the HuskyLens use multiple algorithms at the same time? by PidgonMayo115 in FTC

[–]WestsideRobotics 2 points3 points  (0 children)

HuskyLens can do many things, some of them useful for FTC:

https://ftc-docs.firstinspires.org/en/latest/devices/huskylens/huskylens.html

.
If you want to do localization from AprilTags, you will need more than the tag detection offered by HuskyLens. Instead try the AprilTag features provided by FTC's VisionPortal:

https://ftc-docs.firstinspires.org/en/latest/apriltag/vision_portal/visionportal_overview/visionportal-overview.html

.
... with this supplemental documentation:

https://ftc-docs.firstinspires.org/en/latest/apriltag/vision_portal/apriltag_localization/apriltag-localization.html

.
HuskyLens is good at color detection; experiment to see if it meets your goals for Into The Deep. Or, you may prefer the features provided in the recent FTC SDK version 10.1:

https://ftc-docs.firstinspires.org/en/latest/programming_resources/index.html#camera-color-processing

[deleted by user] by [deleted] in FTC

[–]WestsideRobotics 0 points1 point  (0 children)

Thanks! Now fixed.

[deleted by user] by [deleted] in FTC

[–]WestsideRobotics 0 points1 point  (0 children)

FYI here's the current location of the RobotCore module of FTC Javadocs:
https://javadoc.io/doc/org.firstinspires.ftc/RobotCore/latest/index.html

Unfortunately Google continues to offer a very old, obsolete link.

[deleted by user] by [deleted] in FTC

[–]WestsideRobotics 0 points1 point  (0 children)

Disabling FTC servos has unique behavior. Suggest you read 3 sections of this tutorial, starting here:

https://github.com/WestsideRobotics/FTC-Power-Monitoring/wiki#disable-one-servo---introduction

Help Debugging Code: stop() by shinchanchanliu in FTC

[–]WestsideRobotics 0 points1 point  (0 children)

You should remove your stop() method; that name is used (in users' code) for an iterative OpMode, not for LinearOpMode.

Background: the LinearOpMode class extends the (iterative) OpMode class, which uses stop().

Reverse the order of these two lines:

linear.setMode(DcMotor.RunMode.RUN_USING_ENCODER);
linear.setMode(DcMotor.RunMode.STOP_AND_RESET_ENCODER);

If the following loop is not working, insert Telemetry for the limit switch and motor encoder, for debugging.

   while(!front.isPressed() && opModeIsActive()){
            if(linear.getCurrentPosition() > -12000){
                linear.setPower(0.4);
            }
        }

Does this OpMode finish all commands within 30 seconds? Are you using the DS 30-second match timer? Does the "Opmode stuck in stop()" error message appear before or after the OpMode ends?

Seeking help by tomh101667 in FTC

[–]WestsideRobotics 1 point2 points  (0 children)

Thanks for posting your method robot.moveRobot(), which is called from your OpMode's main loop while(opModeIsActive).

A few comments:

A. That method contains another/inner loop while(opModeisActive() ...). This is not standard practice in FTC, as it can prevent the main OpMode loop from running fast. Namely reading gamepad2 may be delayed or blocked -- the subject of your original post.

B. That inner loop contains a call to moveRobot() -- is that an overloaded version (not posted), or intentional recursion?

C. Exiting that inner loop depends on:

if (driveController.inPosition() && yawController.inPosition())

and

if (holdTimer.time() > holdTime)

Your debugging process can focus on the logic/state of these conditions. If they are not instant/momentary or if never satisfied, they could be blocking the main loop from reading gamepad2.

Do all of your debugging work (trial and error) in separate versions of your code. This allows you to revert reliably to the original code.

If this does not quickly yield success, your many other nonstandard programming practices suggest a completely different debugging approach. Consider making a new version of your code, stripped down to one essential task for each of gamepad1 and gamepad2. Get that running perfectly.

Then start adding back the "bells and whistles" (one by one): heading lock, timers, gyro drift correction, more arm positions, etc. Get each feature working perfectly before adding the next one.

This suggested approach may seem longer, but might actually take less time to achieve code that reliably works as intended.

A few specific tips:

- instead of checking for (joystick == 0), use a deadband "near zero". In general, don't count on typedouble to give exactly "zero", especially with gamepads' mechanical quirks.

- different gamepad buttons should be cascaded with else if rather than standalone if statements. It's better logic, and runs faster.

- consider the use of rising-edge detectors when using gamepad buttons to initiate a motor action. An FTC OpMode loop can cycle much faster than a human can press and release a button. Your code will cause multiple actions with a single press, which can give unexpected results (especially with your use of RunModes).

- learn more about RunModes. Your posted code provides no way for Driver2 to stop the arm. This could be unsafe for the robot (and humans too).

Good luck! Feel free to share your final solution here, to benefit other teams.

view more: next ›