Integration Checklist

[aidnem]

List of things we should integrate, and in what order (OPEN TO SUGGESTIONS/REVISION):

1. Swerve drive module PID tuning + verification
2. Verify driving works in teleop
3. Tune PID for arm
4. Tune PID for shooter RPM
5. Tune PID for aiming robot at speaker
6. Verify intake works + banner sensor stops intake
7. Verify end to end scoring with fixed angle/RPM target (pick up note, score note). The fixed angle can be up against the subwoofer for max repeatability
8. Initial verification of localization (vision + odometry) based on manual driving around the field
9. Build out lookup table for arm angle and shooter RPM based on distance from speaker
10. Path following control by driving auto routes (determine speed/accel limits for auto, retune modules if needed)
11. Implement + tune autonomous
12. LEDs for beelink not on
13. LEDs for note indicator

[aidnem]

@jkleiber You probably have more of a vision in mind for what integration will look like, feel free to edit this post or suggest edits as you see fit. I just wanted a good way to have an overall view of the integration process and track progress.

[jkleiber]

This is a good list, but the order should be based on the following:

1. Technical risk (how difficult do we think a task will be to execute from an engineering standpoint)
2. Time estimate
3. Pre-requisites

So I would propose the following ordered list:

1. Swerve drive module PID tuning + verification
2. Verify driving works in teleop
3. Tune PID for arm
4. Tune PID for shooter RPM
5. Tune PID for aiming robot at speaker
6. Verify intake works + banner sensor stops intake
7. Verify end to end scoring with fixed angle/RPM target (pick up note, score note). The fixed angle can be up against the subwoofer for max repeatability
8. Initial verification of localization (vision + odometry) based on manual driving around the field
9. Build out lookup table for arm angle and shooter RPM based on distance from speaker
10. Path following control by driving auto routes (determine speed/accel limits for auto, retune modules if needed)
11. Implement + tune autonomous
12. LEDs for beelink not on
13. LEDs for note indicator

[PChild]

LEDs at some point. 🥺

PXL_20241007_002211631.mp4

[jkleiber]

Update: intake works but we need to make the banner sensor work and only allow full intake when aimer is down

[jkleiber]

@aidnem @linglejack06 @avidraccoon @minhnguyenbhs

Would Saturday shop from 10am to 3pm work well for y'all? If not, what time frame would be better?

I don't expect that everyone will be able to make 100% of this time, but I just want to pick a time where we can have continuous attendance and get a lot done

[avidraccoon]

I'm sorry but I won't be able to go to the shop on Saturday.

[minhnguyenbhs]

hi! I'm so sorry but something came up and I don't know if I'll be able to come tomorrow

[minhnguyenbhs]

@linglejack06 would it maybe be possible for me to ask you for a ride? I'm not sure if I can go either way but would that be too much trouble for you? thanks- sorry

[aidnem]

I can make it sometime around 10 but unfortunately can't give anybody a ride, sorry.

[jkleiber]

I am writing this message to try to provide some direction on what we should be aiming to accomplish over the next two shops for all our Robots.

Robot assignments - please make sure the robot you are assigned to is ready for competition:

• High Key: @aidnem @linglejack06
• Apep: @minhnguyenbhs
• C bot: @avidraccoon
  If your work is done, then I'll leave it to your discretion as to which robot needs the most support.

Monday October 14
High Key: fully functioning teleop by end of shop

• Shooter lookup table
• Drivetrain auto aim at speaker

Getting the drivetrain auto aim should be easy if vision is working well. The main priority of today is getting a highly accurate lookup table for shooter so we can do auto on Wednesday.

Apep:

• Test auto a few times to make sure it's mostly working
• Do some teleop if time allows

C bot priorities

• If the superstructure is on, test/integrate scoring. The robot is drivable (I fixed the steering offsets on Saturday)
• See if you can get driving working without the weird control issues once scoring is done or if the superstructure isn't on (steers halfway and then only gets to the setpoint if you stop commanding things)

Wednesday October 16
High Key:
Build out autonomous incrementally in the following order:

• Score the preload and sit still (1 note)
• Center start 4 note wing auto (preload, wing notes)
• Center start 3 note (preload, center wing note, 2 centerline notes)
• Center start 4 note (see above but go get another note from center)
• Amp side start 3 note (preload, amp side wing note, centerline note)
• Amp side 4 note (see above but go get another note from center)
• Source side 3 note (preload, 2 from centerline far side)

We want to have an auto at each start position in the following preference order: center, amp, source. Bare minimum is that we need to score preload.

If vision is working well, then prioritize picking up notes rather than scoring them. If we had more time we would want high shooter accuracy, but theoretically the shooter lookup table is correct from Monday. So if an auto is consistently picking up all the notes and shooting them at the goal move on to the next one to tune the path. If there's time on Friday or at competition we can mess with the lookup table.

Apep and C Bot:
Finish anything that didn't get done on Monday. Driver practice if High Key isn't in the way.

cc: @PChild for awareness on what programming should be doing today/Wednesday

[linglejack06]

@jkleiber @aidnem do we have a good way to quickly adjust shooter rpm? If not I thought of a basic hack we could do to prevent redeploying after every rpm change

[jkleiber]

We should develop a test mode to set aimer angle and shooter RPM using elastic

[linglejack06]

@jkleiber @aidnem after several failures auto works with alignment now, shooting preload is fairly accurate. It gets to intake the first note but the arm isn't at intake position so it intakes into robot above arm. I'm gonna work on adding a named command to make arm go to intake position tonight. Also , by the time robot got out to the first notes position, vision estimate was completely wrong (likely due to lack of apriltags on our field by amp). Therefore the alignment was really messed up. But I think with proper comp field vision should be sufficient to aim from out there.

[jkleiber]

Thanks @linglejack06 , it sounds like we need to do a better job of rejecting bad vision estimates so we can be robust to the case where we don't have much tag information. I think that should at least help us get all the wing notes since the speaker tags will be well in view

[jkleiber]

@aidnem / @linglejack06 can we work to get the 14-calibrate-cameras branch merged to main today? Then we should create a competition branch + release on Github prior to BRB

[linglejack06]

@jkleiber yes, do you want me to add the arm intake position to this branch before we merge?

[jkleiber]

Let's use a new branch

[linglejack06]

Ok then 14-calibrate cameras should be able to be reviewed and merged

[jkleiber]

It still needs a pull request

[linglejack06]

I’ll open that when I’m by my Mac Sent from my iPhoneOn Oct 17, 2024, at 1:42 PM, Justin Kleiber ***@***.***> wrote: It still needs a pull request —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[minhnguyenbhs]

hi I’m feeling a little unwell today, I’m not sure if I’ll be able to go to BRB but I’ll do my best to get there asap
if I can't go, I hope things go well today!!

[aidnem]

@minhnguyenbhs Sorry to hear that, I hope you feel better! You didn't miss much lol

[jkleiber]

@aidnem I think we should baseline the following overall goal for B bot this week: "make the robot great in teleop"

This doesn't mean we are going to abandon auto, nor does it mean that we should make the robot less automated. It just means that we should prioritize things like ease of operation.

The following will accomplish that goal:

1. Making auto alignment work
2. Tuning all controllers so that "force shoot" is not required
3. Making amp warmup / scoring process seamless
4. Adding a "pass shot" to feed notes to our alliance wing
5. Adding LED indication for note possession / beelink not on

Once these things are complete, we can resume our incremental build up towards autonomous.

[aidnem]

I agree. I believe that auto alignment was the culprit behind force shoot being required, which would mean that (hopefully) if we fix align it will fix both issues. Fixing the aimer is also going to be crucial so that we can actually make shots. Also, I think localization was a bit of an issue (we can't aim if we don't know where we are).
Would you mind elaborating on what you mean by making amp process seamless?

[jkleiber]

Currently we have an untested amp mode (besides shooting notes in the pits to verify logic). Last year scoring in the amp was possible in theory but we were so inefficient with it that it wasn't worth it. I want to ensure that it's as easy to score in the amp as it is to score in the speaker (and for both of these things to be easy overall)

For localization I think we should start by only considering 1 camera and then incrementally adding cameras as we feel confident in the ones that have been incorporated

[linglejack06]

What went wrong with the alignment? @jkleiber @aidnem it was working great at shop

[jkleiber]

It just straight up did not work at BRB as far as I know. This could have been a vision problem. In auto we would either:

1. Not move at all
2. spin in circles

[aidnem]

@jkleiber I think it was aligning properly in auto, I suspect that when I flipped all of the aligns by 180 degrees to make it aim at the speaker (instead of shooting the note at the referee) I forgot to update the isDriveAligned function. This means that it would align correctly but then think that it wasn't aligned, causing us to never auto-shoot, and requiring all mashers to force shoot.

[jkleiber]

@aidnem can you create a ticket and a branch to fix that? If you have time it would be good to try it in the simulator to see if that works

[aidnem]

Issue created: #56.

[aidnem]

Also @jkleiber we were never moving in auto because it would aim and spin up flywheels but never shoot, and the auto was waiting for the shot to be taken before driving away. Supposedly this will go away once we satisfy it that it can take shots without force shoot.

[linglejack06]

I noticed that would happen in auto when vision estimate pose was wildly different than real pose. As long as no changes were made to the alignment part that’s the only thing I think that could be wrong. I guess we will look at it at shop tomorrow and try to figure it outSent from my iPhoneOn Oct 20, 2024, at 3:54 PM, Justin Kleiber ***@***.***> wrote: It just straight up did not work at BRB as far as I know. This could have been a vision problem. In auto we would either: Not move at all spin in circles —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[aidnem]

Probably a vision issue then. I think we should start with the most reliable camera and then see if we can get just that camera to work at all.

[linglejack06]

yeah, i had adjusted the speaker alignment specifically by pi radians (as in shop it was pointed the wrong way), this was then accounted for in the is drive aligned method by adding back the pi radians. but if you changed the getAlignment function for speaker then the is drive aligned would be messed up

…

On Mon, Oct 21, 2024 at 12:12 PM aidnem ***@***.***> wrote: Issue created: #56 <#56>. — Reply to this email directly, view it on GitHub <#27 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZ7J5PWLJA2QKRGF5FTKE4LZ4URXZAVCNFSM6AAAAABPQOLP72VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMBQG42TCMA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[aidnem]

Yes, for some reason the robot turned 180 degrees away from the speaker and shot into the crowd during the first match's auto, so I inverted the rotation after that.

[linglejack06]

Was that on blue alliance? If so it’s because I forgot to add a conditional. On red alliance 180 degrees has to be added to the heading to align to speaker, but blue alliance works without the heading. So the conditional should say if red alliance add 180 and if red alliance subtract the 180 for the is drive aligned method. If blue alliance then the rotation is left alone for the is drive aligned and the get rotation Sent from my iPhoneOn Oct 21, 2024, at 12:52 PM, aidnem ***@***.***> wrote: Yes, for some reason the robot turned 180 degrees away from the speaker and shot into the crowd during the first match's auto, so I inverted the rotation after that. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[aidnem]

Yes that was on blue, that makes sense. Any idea why the headings are wrong by 180 degrees on red?

[linglejack06]

I assume it’s due to the coordinate plane of the field somehow. I can explain better with a drawing at shopSent from my iPhoneOn Oct 21, 2024, at 2:13 PM, aidnem ***@***.***> wrote: Yes that was on blue, that makes sense. Any idea why the headings are wrong by 180 degrees on red? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[linglejack06]

Yes the wait command specifically waits until the note has left the shooter before doing anything. So the auto will not continue unless the note is shot or spit outSent from my iPhoneOn Oct 21, 2024, at 2:17 PM, aidnem ***@***.***> wrote: Also @jkleiber we were never moving in auto because it would aim and spin up flywheels but never shoot, and the auto was waiting for the shot to be taken before driving away. Supposedly this will go away once we satisfy it that it can take shots without force shoot. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[linglejack06]

Also it won’t continue on path if isDriveAligned is false so two issues thereSent from my iPhoneOn Oct 21, 2024, at 2:17 PM, aidnem ***@***.***> wrote: Also @jkleiber we were never moving in auto because it would aim and spin up flywheels but never shoot, and the auto was waiting for the shot to be taken before driving away. Supposedly this will go away once we satisfy it that it can take shots without force shoot. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[jkleiber]

Plan for Shop Today

• Test / tune pass shot
• Test seamless amp
• Get better at shooting in teleop (possibly vision tuning)
• If time allows, run some simple auto

[aidnem]

This is probably obvious but in case I forget later, tuning-shot mode will work for pass testing so that we don't need it to have its own test mode.

[aidnem]

@jkleiber want me to create an issue for closed-loop path following so that if we have time for autos we can make them actually good?

[jkleiber]

Let's use #35

[aidnem]

@PChild When arm is being controlled to the bottom position, there's enough play in the chain for the aimer to swing up due to acceleration of the robot. There's just enough play in the system for this to sometimes intake notes into the middle of the robot if we intake while accelerating just right. Is there any way to reduce backlash in the chain? My proof that this is not a code issue is that, when setting the motor to brake mode, I can lift the arm a little bit before I feel the brake mode resistance as the motor actually starts to turn.

[PChild]

Also we should check that when the robot is enabled, behavior of brake mode when disabled != PID control behavior, the encoder is 1:1 on the arm so it shouldn't see any lash from chain or gears.

[aidnem]

This is true, PID might just be controlling down too weak to bring the arm back down immediately. We don't really have a good way to gently drive into the hardstop but I feel like it wouldn't be enough anyway unless we were driving hard enouhg for it to heat the motor up a lot and probably be bad.
We could consider a fancy feedforward solution based on acceleration but honestly we could also just tell oliver not to accelerate too hard while intaking.

[PChild]

Adjusting the current limit lets you control both how much torque the system pushes into the hard stop with and how much heat is generated. The driver should be allowed to accelerate as hard as they can.

[jkleiber]

@aidnem we could use @minhnguyenbhs work in #47 to apply a constant downward aimer output and a low current limit in intake mode

[aidnem]

Good idea, I was thinking of something similar.
Do we know if a current limit will do what we want (not disagreeing, just curious)? I'm not sure how smart it is, but does it just zero out motor voltage when current goes above the limit and then wait for a period of time?