FTC #14204 Progress Updates #256

Is it? I made a post about not being able to upload code and was told that alpha 5 was not compatible with Systemcore yet.

OpModeRobot doesn't work on Systemcore, which means the ExHub example doesn't. But if you have a plain TimedRobot, it will work. We should have alpha 6 out soon to fix OpModeRobot.

There is a setInverted() method in the A301 class to reverse the motor's direction.

Does that work now?

Does that work now?

It should in REVLib Alpha 3 per the changelog: https://github.com/wpilibsuite/SystemcoreTesting/blob/main/REV.md#revlib-v202700-alpha-3

For me, it is crossed out and hovering over the method says that the method is deprecated. I am on REVLib Alpha 3
setInverted

Disregard, I did a restart and it does not say that now. All good! :D

You'll definitely want to be careful with units. I know that Pose2d is generally expecting to be in Meters, as is essentially all other math (Realistically, this code when we get something implemented will probably use Units to help make this easier. But cool to see it all working.

What is considered 0 for the relative API right now anyways? It doesn't seem clear from the docs I've seen.

0 is whatever position the motor boots up at. It can also be re-zeroed during runtime via a method, but that will of course be lost when the device loses power.

0 is whatever position the motor boots up at. It can also be re-zeroed during runtime via a method, but that will of course be lost when the device loses power.

Is it possible to change this? This seems like a bothersome behavior for teams.

Change what? Starting at 0 or losing the position on power loss?

I think there might be a bit of confusion here between relative and absolute.

Relative is similar to the existing ftc encoders where they start at 0 on boot, because the encoders have no information where they are. But they can track rotations once they’ve started.

Absolute is where the location is always known within 1 rotation cycle of the output shaft. This will always be at a known location, but that location is only known in a single rotation.

I suspect Qwertys original question meant absolute not relative.

Generally, an api to automatically seed the relative encoder based on the absolute encoder at boot up seems like a good idea on paper, but it gets wonky in the reboot case where it’s not known which rotation it’s in for things like an arm. It’s very footgun prone. And if you don’t go more then a rotation, just use absolute.

Especially since it’s pretty easy in code to do this, and you can assign a button to do the reset, I feel like it’s much better to do it in code.

The main thing that might be helpful is an atomic api to do this in firmware. Basically a "set relative to absolute reading" command that in firmware reads the absolute and resets the relative directly to it, without having to worry about the lag between can frames when doing this from code. This command could even take an offset, so if for instance you wanted it to start at 2 rotations plus an offset you could easily do that.

This type of api can be super nice for resetting an arm using just the current spikes against a hard stop. Wait for the current spike, and then reset the encoder. You don’t need to have the arm at an exact location when reset, you just need to be within the range of a single rotation. Which depending on gearing can be a few degrees or even more.

Prerelease 16 allows you to adjust the absolute encoder's output range. And like gearsincorg mentioned, the absolute position shouldn't lose its position across power cycles.

Thanks for the continued testing and updates!

No problem! It's what we signed up for, after all. 😄

I've been trying to use a Limelight 3A to lock to an AprilTag, but can't seem to get my code to work. I'm using the getTXDegrees method and I have set a pipeline, is there something else I need to add to get the Limelight to return a value?

When you say "I have set a pipeline" does that mean that your Limelight is showing up in the web dashboard and you have used that to configure an AprilTag pipeline and verified that it is detecting the tag?

When you say "I have set a pipeline" does that mean that your Limelight is showing up in the web dashboard and you have used that to configure an AprilTag pipeline and verified that it is detecting the tag?

Yes, I was able to configure a pipeline and get it to see the tag in the dashboard.

Thanks. I unfortunately don't have a 3a on hand to test with so may need @bhjelstrom to chime in. I would start with checking isConnected() on your Limelight object to see if the object is actually pointing at the right thing. I'm guessing the 3a needs to use either the empty constructor (for the default name) or pass in the name if you have changed it, even though it plugs in over USB.

You should be able to take a look at the Robot Code Network Tables using either Elastic (to connect, click Settings, select appropriate IP Address mode and make sure the Target Server is Robot Code) or AdvantageScope and verify that there is an entry there for the Limelight and double check what the table name is. As an example, you can see in this example screenshot from Elastic that a webcam plugged into USB0 would need to specify "limelightsc0" as the name (and there are static helper strings for this purpose).
image

Thanks for the info! Our team is on break until kickoff, but when we get back I will find some time to test this.

That really is going to be the major downside of moving to lithium drill batteries. The Dock should have a Low Voltage Cutoff in it, however those are designed to notify the user as the battery dies while they're using the tool. I'm not surprised their design has a parasitic draw while in LVC mode.

I am hopeful that we could get a better designed LVC in the future, but at some point unless its a physical switch holding the full current, theres going to be some draw to power the LVC circuits themselves. So maybe something that can last a week or 2, but I suspect it will be impossible to get something that would last more than a month, without killing the batteries.

The reason the charger says its broken is lithium batteries discharged to far are unsafe to charge. This isn't even at 0 Volts, its generally around 2.8 volts per cell. So if the battery discharged below 14 volts, it's never going to be recoverable. Most LVCs are programmed to be fairly close above the cutoff, as generally these are used in tools where they are actively used, and noticed immediately when dead.

I am hopeful that we could get a better designed LVC in the future, but at some point unless its a physical switch holding the full current, theres going to be some draw to power the LVC circuits themselves. So maybe something that can last a week or 2, but I suspect it will be impossible to get something that would last more than a month, without killing the batteries.

I think a week or two would be a perfectly reasonable amount of time to catch it for an FTC team. Our team has at least 3 meetings in a week during our season.

Idle power consumption of the Floodgate is extremely low:
image

Since (as I remember/understand) the Floodgate was based on the 20v dewalt battery dock (https://www.gobilda.com/gobilda-smart-dock-for-20v-battery-dewalt-20v-max-compatible/), I suspect it likely has similar disabled power draw. I'd consider 0.0005mA to probably be plenty good enough, and a good target for any other vendors' battery docks.

(CCing @Ethan-goBILDA, would you happen to have a current draw spec for the 20v battery dock specifically in low voltage cutoff mode?)

Tons. https://github.com/wpilibsuite/allwpilib/releases/tag/v2027.0.0-alpha-7

See the notable changes in the release notes.

Yay, official Pinpoint support! I'll have to get an autonomous going.

There's also https://docs.wpilib.org/en/latest/docs/yearly-overview/yearly-changelog.html