FTC #14204 Progress Updates #256
Replies: 15 comments 37 replies
The Systemcore beta 10 image here is compatible with WPILib alpha-5. |
|
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. |
|
We converted one of our Power Play demo bots to use Systemcore! It is working very well. |
|
We have received our 8 A301s! We have not done anything with them yet. It will most likely be another week until we can start really testing them as we are running an FTC camp all next week. First steps will be updating the firmware and testing them with code. |
|
We are starting to build an A301 chassis. It will be an 8 motor drivetrain. |
|
Over this past week, we have finished building the A301 drivetrain, and coded it in field-centric! There was no setDirection method for the A301s that I could find to reverse them, so it made our mecanum code look a little more jumbled using negative signs for power. The IMU was a little confusing at first, but the documentation hovering over the MountOrientation fixed that immediately. One extra thing I've noticed is that the RioLog says you've lost connection to the robot even if you are still connected. This confused me when I was first trying to upload code. We made a video where we have the chassis driving around down here: |
|
There is a |
|
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 |
|
Disregard, I did a restart and it does not say that now. All good! :D |
|
Today we have successfully ported the Pinpoint V2 driver to Systemcore! It was a little challenging porting it manually, but we have tested it and it is working well. I have the driver attached here for anyone who wants to play around with it. Fair warning, getPosX and Y methods return millimeters. |
|
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. |
|
I noticed that the REV Color Sensor V3 has built in support, so I am going to mess around with that at our next meeting. |
|
I was messing with the setAbsolutePosition methods after updating our A301s today, and there are a couple things I find odd.
I do really like the customizable speed for setAbsolutePosition though, that could be useful. |
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. |
MicrosoftTeams-video.4.mp4
Our robot "Woody" is alive! All of the mechanisms are working, we are trying to add some automation with commands now, and a camera for heading lock. Headed to CRI this weekend so progress will be halted. We will be showing off this robot at CRI.
|
|
CRI Feedback We took Woody to CRI, and showed it off to other teams in the pits and on the practice field. We even had a clip towards the beginning of the Sunday livestream of us talking about it! We got some feedback about how teams feel of the new system.
Overall I think there was a lot of good feedback here. People were very excited about the new control system, but were worried about the A301s, particularly the servo mode. |
|
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. |
If you are using AbsolutePosition mode, the motor should be retaining it's zero position reference through power cycles. If it's not, you should report the specific actions you are seeing. |
|
On Saturday, we ran our A301 bot in matches at Robot Rumble at the Raceway! We were able to use the same battery for 2-3 matches without any performance issues. After talking with the FTA about the Driver Station App, I think it would be good to have initialize options for OpModes so teams can have mechanisms move before auto starts. We did have a leaving autonomous program using a SequentialCommandGroup. We also had some people come talk to us about the system itself. They were excited about the potential of the Systemcore and Motioncore themselves. I heard multiple times about the nice new wiring. Everybody we talked to was concerned about the A301s. People liked the idea of 20 motors but not the idea of them being the only legal actuator. |
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? |
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). |
|
Thanks for the info! Our team is on break until kickoff, but when we get back I will find some time to test this. |
|
Robot Rumble At the Raceway |
|
I came into our building today to mentor our FLL team a little bit. When I was done with that I went to test the Limelight on our A301 bot and found that the power switch was left on with a battery inside. The battery charger says the battery is broken. I know this is a basic battery dock for our testing, but it can not work like this for FTC teams. Accidentally leaving a robot on for a prolonged period of time is not an extremely rare circumstance for teams and the Systemcore/battery dock should have some way to at least try and prevent this from happening. Especially with how expensive the new batteries are. |
|
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 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: 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?) |
|
What sort of features does WPILib Alpha 7 add? |
|
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. |
Uh oh!
There was an error while loading. Please reload this page.
#14204 here, we picked up our Systemcore and Motioncore at Worlds on Friday. Currently waiting for the updates to Systemcore to work with alpha 5, but we have a mecanum program ready to go to test! Excited to see how it goes and get the A3O1s in the future!
All reactions