Hey, scout from 95 here! ScoutingPASS has been great for us, although we modified and gutted our fork of it a lot to get it to work how we wanted on our old 32-bit iPads. Now that we’ve got nice tablets, we’re working on porting it to an Android app, which we think will work better for our purposes.
I’ve seen some of the new features, and they look neat! We might pull them into our fork once we get some time.
We really appreciate the fact that ScoutingPASS exists! Our scouting was basically nonexistent until last year, and having a pre-made app ready to use was really helpful for getting a scouting program going.
We tried a new intake geometry for about a second, then ripped it all back apart to the MK1 collector design. The rollers were too close and too rigid to intake cones via their flange.
‘Hey, you guys know we have a nice cart you can work on, right?’
‘We like the floor’
And also an intake smash test. The linear slide and drive are super compliant, the operator has to drive the intake out during dramatic acceleration (since it’s open-loop). We did manage to chip one tooth on the PLA+ printed gear, but the mechanism still worked after testing.
We have elected to print versions of all of our superstructure and arm components to work with aluminum tubing while we wait for the carbon tubes. We hope to have that assembled by the end of the week.
What tablets are you using for scouting? We’re looking at using a similar setup, but initially were only going to use phones - but testing scoutingPASS for only one device is definitely easier!
As we are all learning about the maintenance of our newly built robots I think it is useful to re-post info from our 2022 build thread that has low-key been a huge quality of life improvement for us and others. I’ll just give the tl;dr here:
Thanks for reposting this in a short and simple way. This is one of the best quality of life things we have picked up from another team in the past few years.
I highly recommend more teams follow 95’s lead and grease their components this way.
Something that I’ve noticed with roller claws (233 2011, 179/1323 2018, etc) is that adjustabality in prototyping and even in competition is key. Some material can wear off the rollers or something can get knocked out of place so having slotted hole positions for your rollers so they can change position easily is very useful
Nice new carpet! My team has actually been thinking about getting carpet this year to practice on for the first time; where did you guys source it? Is there any advice you’d give us?
Local off-season/leftover competition carpet is the best bet. We have gotten a close approximation at HD before, but it didn’t hold up all that well.
Secure it with carpet tape underneath and gaffer tape around the perimeter. Don’t install carpet pad if you can avoid it, the competition doesn’t use that.
Vacuum often, before dirt is showing.
Painters tape to mark the field is nice because it isn’t too permanent.
Thank you for the tip! Would I just reach out to a local competition and see if they have any carpet left over from last year (is it as simple as that )
Painters tape works on the cheap, but isn’t the most durable. Would recomend teams invest in some gaffers tape for laying out the field if they can. It’s durable and meant for just such an application.
More likely a team who runs an off-season near you, or the competition committee can point you to who took the carpet. Some teams stock up for offseasons and to hold them for teams who can’t take the carpet right from the competition venue. If a local team/he is hosting they may still have it of course.
I was trying to remember where I learned this tip and it must have been from 95s old build blog. We found you can use food injector for it. They are fairly cheap and easy to pick up at any grocery store.
Let’s talk about intakes! Well, at least our intake.
We had hoped to be able to knock over an upright cone with the intake and collect it by running ‘cone mode’ while the rollers came back across the cone. But that didn’t work, instead all that happened is this:
Not ideal.
So, we added a motion to the intake. The intake plates float on the collector transmission shaft with two bearings. A polycarbonate spring pack (light gray) pushes the arms down.
The front of the collector arms is supported by a (light blue) roller on each side.
Slots in the arms and (essentially) bosses bolted to the MP face limit the total arm motion.
This should allow the intake to pop up and over cones that we tip over and acquire them. Parts are with the team, ideally getting tested tonight.
ALSO: the carbon fiber tubes are ordered! Annnnd the carbon fiber tube vendor has a two week lead time instead of their posted 2-3 day lead time. So we’re going to start a third design spin of our superstructure parts to work with tubing we can acquire more quickly. Yay…
We are implementing your swerve code (which is excellent btw!) and I was wondering what, if any, issue you had while tuning your heading PID. It looked like we got Integral wind up yesterday but it could have just been the pigeon needed to be inverted.
Technically, we’re running a PD loop, because the I term is zero. You can check that the pigeon is correct by putting the output of getYaw() on SmartDashboard (or whichever dashboard you use) and manually rotating the robot- it should increase as the robot rotates counterclockwise. Also make sure that robot-centric and field-centric drive are working properly before you try the full absolute drive; this will help isolate the issue.
Tuning went amazingly quickly- I pretty much just increased kP as much as possible without excess oscillations, then added kD to reduce overshoot.
Start the gain really low (0.001 or 0.01), then adjust by orders of magnitude, then by doubling/halving, then fine adjustment.
As discussed previously, we are planning on using Limelights and AprilTags for vision, with our ultimate goal being no auto alignment— just drop the robot on the field where it can see some tags, and it’ll figure out the rest. There are a few steps to making this happen:
Limelight process tags and determines where the robot is
This is pretty easy to set up, just needing to input the limelight’s robot-relative location. The limelight then spits out red- and blue-alliance poses.
Fuse odometry and vision data
Fortunately, WPILib can do this for us! The PoseEstimator classes work essentially as a drop-in replacement for the Odometry classes, with the option to add global pose data. Any advice on tuning the Kalman filter would be appreciated, however.
Be able to drive from anywhere, to a particular pose
This is the most fun part— we are doing on-the-fly trajectory generation to get from wherever the robot is to any predetermined pose on the field. Because having to remember the coordinates for every point-of-interest (POI) on the field would be… bad, we create a big ol’ hashmap relating string names to blue-alliance poses. Then, we use this fun Java hashmap manipulation code copied from StackExchange to mirror all the poses for the red alliance:
private static final Map<String, Pose2d> RED_MAP =
BLUE_MAP.entrySet().stream().collect(Collectors.toMap(
entry -> entry.getKey(),
entry -> new Pose2d(
new Translation2d(
entry.getValue().getX(),
FIELD_WIDTH - entry.getValue().getY()),
entry.getValue().getRotation())));
When you put everything together, it looks like this:
A note about the last test, where it hit the other robot:
Yes, it will try to correct for that. However, trajectory following is all done based on time, rather than robot position— the follower command will quit after a certain number of seconds have passed, not necessarily when the robot is at the target. Fortunately, creating a precision-alignment PID controller command is pretty easy with a swerve drive, so we can use the trajectory follower to get close, then the PID controller to score.
In testing this, I was encountering a “Watchdog not fed” issue— that was displayed instead of “Teleoperated Enabled” on the driverstation. However, I was not getting loop overruns, and the joysticks still functioned mostly correctly (some lag). Eventually, I found that I was polling the DriverStation for the current alliance every loop cycle— don’t do that. FMS won’t like you.
Also, maybe don’t run the LimeLight 3d field view thing and AdvantageScope and two instances of VSCode and SmartDashboard and the DriverStation all on the same laptop.
Thank you! I am rewriting my general swerve library based off your code since I couldn’t get mine to work fast enough and you guys are more experienced . I will just publish the Pigeon to the SmartDashboard since it is a sendable it will update itself (also why you dont have to publish the field everytime on your code too btw)
)
. I will just publish the Pigeon to the SmartDashboard since it is a sendable it will update itself (also why you dont have to publish the field everytime on your code too btw)