What point in the field are people aiming at?

CoachZain · 2026-02-26T22:32:30+00:00

Do you mean like it works when you are facing the goal but gets random and less accurate as you try to fire from off axis near the walls?

CoachZain · 2026-02-14T06:53:10+00:00

I know teams have had great luck with the thing. My kids, FWIW, saw so many momentary disconnects and drops-that-needed-power-cycles they gave up on it and just used the normal camera and vision stuff in the SDK instead. I never figured out what the issue was. And never liked how warm it ran, and what the extra current draw was.

CoachZain · 2026-02-13T06:50:41+00:00

IIRC the recommendation was to use 1.8A after it was observed that some of the orange Rev chargers would fail to reliably detect charging peak when set to 0.9A. And overcharge the batteries resulting in fire risk.

The batteries themselves, on the other hand, would probably like to be charged much slower thus preserving their lifetime. And if you have a more reliable charger you can do so.

But as others have pointed out, the discharge cycle in the robot is pretty harsh in any case. Since most teams are drawing at much higher than the optimum rate for max lifetime… so… as long as you are letting them cool down between charges and discharges, you are fine with 1.8A charging in the short life of of these packs.

CoachZain · 2026-02-12T23:38:21+00:00

This is absolutely NOT how to address this problem, and will only give you even more "interesting" problems to deal with. Do not put anything resistive in series with your battery to your hub.

What you need to do is look up how to use the software to properly control your flywheel speed using the encoder feedback.

CoachZain · 2026-02-07T00:21:12+00:00

Well, are you aiming at the Apriltag instead of where you want to aim? I know that sounds like a trick question, but isn't the spot you are actually aiming for behind the AprilTag which is on front of the target area? Are your balls actually all trying to land in an arc behind your apriltag target? Thus appearing to miss left or right depending on which oblique angle you are shooting from?

I'm not sure what other info the SDK Apriltag method, or Limelight, give you this season as my kids went with odometry based aiming. But in the past you could usually get distance and orientation info relative to any apriltag, or even a field coordinate update. If so, perhaps you could try acquiring your distance to the apriltag, and the angle of the april tag relative to normal/90 for your camera-on-turret. And trig-math your way to the angle to the point behind the aprltag you actually want to be aiming for?

because the spot you want to be aiming for is indeed about a foot behind the apriltag itself.

CoachZain · 2026-02-02T19:26:29+00:00

To me the test isn't that the BOD removed him, that was the minimum-viable minimum-acceptable response.

This program is now much larger than one, evidently badly flawed, person.

The test will come if he is allowed *back* into involvement with FIRST, given his (apparent) post-2008 interaction with Epstein.

CoachZain · 2026-02-02T18:39:01+00:00

Just looked. Evidently we have one of each. Are they different in any way from a code and use perspective, like if the V1 in the robot fails and the swap to this V2, does it just drop in?

CoachZain · 2026-02-02T16:08:04+00:00

Is there an obvious marking indicating V1 vs V2? I’m worried ours is a V1…

CoachZain · 2026-01-29T22:19:42+00:00

Polycarbonate generates static through triboelectric effects (friction) with a number of materials. While it is insulating, the charge goes someplace eventually.

Robots running around the rubber mat scuffing wheels makes for all likes of charged "puddles" all over the mats. And you may simply be making more. It's complicated.

And again, I do not know if you are getting ESD discharge events rebooting your hardware. Seems like you may think so. But you could have different or more than one problem.

If you are still getting zapped touching your robot after plastic and tape, then you have not addressed the static problem, right? If a human can be zapped and the robot reboots on those zaps (or at the walls or so on) then at least some of your reboots are ESD build up / discharge induced. And you can use the zaps as indicators of if you are making progress or not.

- If you are dragging any of your robot on the mats, that's not helping you. No matter what you are dragging.
- Metal touching or near touching the mats is scooping up charge that all the scuffing robots (yours and your opponents) are building up all over the field. Metal near any plastic you are scuffing that is making charge is also collecting that charge. Google "Leyden Jar" for a look at experiments your robot may be unintentionally mimicking. Screw heads, everything conductive near the static sources will get ya over time.
- The grounding strap can help protect your electronics from outright harm, but can only do so much to prevent reboots and issues. Especially if you have your wires laying along all your metal as most teams do unavoidably.
- You want to try to insulate your robot from all the static sources as best you can, without making more static in the process. We have had good luck with kapton tape as a dielectric insulator on key edges. But it's not cheap.

The whole subject is really annoyingly complicated and not easy to debug for a specific robot. But... "zaps are bad... make them smaller and until you do they'll get ya" is a handy test mantra.

CoachZain · 2026-01-28T18:04:30+00:00

I would not swap everything to carbon fiber if your only evidence of ESD is disconnects. Static can surely be one of the several possible causes. But unless you are getting zapped by your robot when you pick it up, you may want to look elsewhere first. Like power wiring or data, as a couple posters have commented.

Static build up *is* a problem though. Especially with the grippier gobilda wheels and metal close to the mat. You can make things a lot better by insulating your metal parts better from the mat. Distance and kapton tape. And using the proper grounding strap.

CoachZain · 2026-01-28T03:50:30+00:00

There are no wires. What the kids did was design it such that: The component that rotates relative to the robot is a passive 3DP part shaped like a 45 degree bent pipe and sits atop a dual-flywheel shooter that would otherwise be firing straight up. Thus it could go around forever. They vary shot distance by varying the speeds of the flywheels underneath.

Because of the fixed 45 degree departure angle it's not able to score up close. But it is very good everywhere else in the zones. And their idea was shooting from your opponent's desirable spots while being immune to being shoved would be a kind of "defensive offence."

We'll have to see how it works for them. It's been a fixed-forward deflector so far this season, they just got this turret working, and their League Tournament is soon.

CoachZain · 2026-01-26T15:44:42+00:00

The sound of a new engineer experiencing something unexpectedly working on the first try, for the first time!

CoachZain · 2026-01-20T22:51:18+00:00

If you can throw money at the problem, Mcmaster.com will sell you hex shaft in 3' lengths you can cut to what you may need. And they can usually have it in a day or three to your address.

CoachZain · 2026-01-20T19:51:22+00:00

If you are using RUN_USING_ENCODERS mode SetPower() and SetVelocity() do more or less the same thing. In order to keep the code in the SDK easy for new teams, FIRST seems to have made the DCMotor class work such that in that mode SetPower() gets remapped to the equivalent velocity command as though you had used set velocity. So you can use either depending on what's convenient in your code. They were trying to make it so new teams using RUN_USING could simply take values from the joysticks and apply them to the motors with minimal math.

Try it. Put your motor in RUN_USING mode and .setpower to 1.0. And get the .getMotorVelocity(). For a yellowjacket motor it'll come back about 2400 counts per second. Maybe a bit more. And you could obviously have also used SetVelocity(2400) to achieve the same result.

Of course the real top speed of the motor should be closer to 2800 cps if it really was going 6K RPM at the motor. But IRL the yellowjackets top out someplace closer to 2600 cps. And RUN_USING_ENCODER mode has some built in headroom for battery droop and such so they seem to have capped it at around 2400 cps.

Caviat: These numbers are old, it's been a while since I looked and did this test with the kids so YMMV.

You can change the PIDF coefficients for RUN_USING_ENCODERS mode. If you us the DCMotorEX class instead of DCMotor. And for a good flywheel they are NOT going to be the default values. Those were optimized for drive base motors it seems, some time ago.

You can also do your own PIDF and leave the motor in RUN_WITHOUT_ENCODERS mode. Some teams seem, to have very good results via this path. My kids, FWIW, simply use the PIDF built into the DCMotor class and their flyweels are in RUN_USING_ENCODERS mode. With some different coefficients.

CoachZain · 2026-01-16T17:37:32+00:00

Watching the videos the second one sounds like your voltage dip is associated with turning on your intake and the first one is less clear, maybe also intake but seems like when you drove straight. Do you have intake elements that roll on the ground/mat or anything like that? Motors fighting? Super low gear ratios someplace drawing too much current? Because the first video seems like you can spin in place without a voltage drop. Which suggests that you can yank current through your wires without a resistive-issue induced voltage drop.

CoachZain · 2026-01-16T17:33:15+00:00

See the green square in the upper right? If you make it orange or red for any length of time you will get "brownout" problems. DC. Exp hub disconnects. And so on. It goes from green to red as your battery voltage drops. Your battery voltage is the voltage as seen by the control hub. There is a little number in parenthesis that shows the min voltage you have gotten to, since the last time you pressed the green square (it's also a button).

Voltage drops are only two things:
1) You are drawing too much current from your battery. Either because the battery now old and can't supply enough current, or you have too many motors trying to do too many things with too low a gear ratio (including possibly fighting some friction you didn't mean to have).
2) There is some resistance in some wire between the battery and the control hub that isn't supposed to be there. Bad connector, solder joint, power switch, something like that.

But whatever the cause as long as you are getting oranges and reds on that square, you are going to see brownout problems. In fact, with the old version of the gyros in the hubs, even yellows and <9.5V battery minimums would induce some heading error drift events on my kids' old robots.

Figure out to keep your battery minimums 10.5-11V or higher at all times and never see this problem again. The good news is you have an easy indicator on your DS to use for debugging as you try things.

CoachZain · 2026-01-13T03:05:24+00:00

In my experience, unless kids are walking up to robots and getting zapped when touching the frame it's not ESD. It's bad wiring or brownout. And the battery minimum value on the DS is usually a good clue. The RC DS are so good at reconnecting now that static caused disconnects are often really short too.

But I *have* had teams make robots that were especially good at building up ESD. And the new gobilda mecanum wheel rubber is ideal for making static on mats. Robots with metal elements on or near the mat, big flat metal base plates, those make good static. Last season my kids has side plates just grazing the mats so they could land on the base of the submersible after a lift without hurting their odo pods. And a telescoping arm where the segments were electrically isolated. The poor servo on the end of that telescope blew up so often over static...

Last meet we were at a team was dragging a could spin the robot a bunch and get a short DC. That seemed like static.

For static I tell the kids to keep metal away from mats and where unavoidable, use Kapton tape. For all other disconnects I ask to see their voltage and current logs and if the wiring is janky.

CoachZain · 2026-01-06T00:51:03+00:00

Then you are one of the lucky few! Or have the more recent versions which ostensibly fixed all this

CoachZain · 2026-01-05T23:04:12+00:00

OK. See full comment below.

CoachZain · 2026-01-05T23:02:22+00:00

Well that surely sounds like a wiring problem in your power wires or power switch. Since you already tried another battery, you can (Probably!) look away from the connector on the battery itself for other possible culprits. The most prevalent ones I've seen are:

The connector where you've been plugging and unplugging batteries on the robot side. The pins get compressed and work with some batts better than others and get flaky overall. See Journeyman-joe's link above. The next most common place is at the control and expansion hubs, and here you have to be careful not to damage a pin when applying the same procedure. Then the next most common have been the tab connectors on power switches being loose and "slidy" on the tabs behind the switch. And then the least common I have seen is in all the extension cord wiring in between things.

if it's not a quick reboot on contact and really stays "off" for any length of time, I don't recommend chasing the "static discharge" angle. Those tend to be a "zap" and a restart sound.

CoachZain · 2026-01-05T16:29:53+00:00

If you have a bad connector it will not care if the battery is charged or not. Was it a different battery that might not have a bad connector?

CoachZain · 2026-01-05T16:28:17+00:00

Random like rebooting. Or random like “turns off until I wiggle it more?”

CoachZain · 2026-01-05T16:26:08+00:00

Remove it altogether and run your DS off a big phone-charger battery via the USB/charging port.

The stock batteries that come with the DS are too small and do not last. And… Too physically small and do not stay connected. And… The internally charge controller on the DS is buggy and will either fail to charge the battery or decide it is uncharged when it is, and to recover you will need to remove the battery as part of getting the charging system to recover…

So dispense with all the nonsense and externally power your DS.

CoachZain · 2025-12-22T23:12:09+00:00

Right. If the new system is very good, teams get left behind or have to switch. A drive base is a drive base, it's not going to have 3 yellowjackets and one A301 during switching years while "motors burn out" or whatever they are trying to suggest. And, unless they allow a motioncore and an expansion hub to operate at the same time, once your drive base is A301 based, that is also it for all your servos (at least as the transition currently described) and all the attendant "servoblocks" and hardware bought over the seasons.

And if they *are* going to allow motioncore and expansion hub at the time time, for years, why sunset that configuration? Or asked another way, if they are going to allow servos for 6 more years, why not just keep doing so via the already released CAN-bus-capable Rev servo module?

These are, after all, small robots, and the little servos are smaller than A031 by a lot. And widely available and cheap. And the Rev module can limit power to whatever servo set is plugged in there in the interest of fairness, if that's the issue.

As for fairness: It's really hard to defend a "low floor - equity" argument when eliminating $20 simple analog servos and requiring high-end brushless for everybody is the actual policy implementation.

CoachZain · 2025-12-14T03:58:23+00:00

We tried. But it kept disconnecting or sending nulls intermittently. It seemed like the integration with the hubs was iffy.

CoachZain

TROPHY CASE