strategy

@James Slattery has joined the channel

@Clio Batali has joined the channel

@Alex Larson Freeman has joined the channel

@Will Hobbs has joined the channel

@Lucas Rininger has joined the channel

@Jon Coonan has joined the channel

@Alex Larson Freeman set the channel purpose: Go to Worlds

Solid, Alex. Solid

Start the hype early, I say

Slack > email

@Enrique Chee has joined the channel

@Binnur Alkazily has joined the channel

@Michelle Dalton has joined the channel

@Chris Rininger has joined the channel

Flying game semi-confirmed

probability of pneumatics element to the game seems higher from the teaser

@Jack Chapman has joined the channel

@Jack Stratton has joined the channel

@Fiona Morrison has joined the channel

@Timo Lahtinen has joined the channel

@John Sachs has joined the channel

@Jeff Dalton has joined the channel

@Kenneth Wiersema has joined the channel

@Rose Bandrowski has joined the channel

@Charlotte Larson Freeman has joined the channel

@Peter Hall has joined the channel

@Ethan Rininger has joined the channel

@Kate Treviño-Yoson has joined the channel

@Adrien Chaussabel has joined the channel

@Chris Mentzer has joined the channel

@Mike Rosen has joined the channel

@Benjamin Soldow has joined the channel

@Sophie Holzer has joined the channel

@Samantha Rosen has joined the channel

@Marie Sachs has joined the channel

@Tom Wiggin has joined the channel

Pneumatics and steampunk

both feature cylinders full of high pressure matter that actuate things

you think!

@Luke Frank has joined the channel

No password required

No password required

Can we have a new channel for technical difficulties?

if our tech was actually operational that would be great

Let's keep this channel for strategy in any case

stuff breaks and stops working all the time and most of the time the best we can do is pray it starts working again

Tom...your request is noted, but we'll work on it later.

if we collaborated and shared our knowledge we could solve these problems easily

nobody cares how many degrees you have if you spend half the class bumbling around trying to make the projector work teach

@Harper Nalley has joined the channel

@Tom Wiggin has left the channel

I took a snippet of just the field for reference, printing, whatever. Here it is.

@Riyadth Al-Kazily has joined the channel

Brainstorming from this morning: https://docs.google.com/document/d/1J3zrIIWWG-TlluiTo9IprME-lGoWukl-POfNmFvwm7M/edit?usp=sharing

The scoring guidelines on p. 42 say that you get 5 points for crossing the gray baseline by T=0, so can the robot go back after crossing?

That's for the end of autonomus, it can go back

Just needs to cross once

one would assume so

@Declan Freeman-Gleason has joined the channel

Great stuff on strategy analysis, as well as scouting and statistics like OPR and their usefulness.

@Clio Batali pinned a message to this channel.

Cross-posting - cool passive gear collector & distributor from RI3D Indiana: https://www.facebook.com/ri3dindiana/videos/1258980350815860/. It looks like its just get the gear, drive to the airship, drive forward to the spring and thread it through the gear, and the pilot lifts it away. Would something this simple still be 1 mechanism?

https://www.chiefdelphi.com/forums/showthread.php?threadid=153193 I doubt many teams will agree to this but the rules will probably be changed to prevent it, maybe the gears will be marked for each alliance as one comment said

There is some debate over whether rules C02 and C03 apply to the "gear alliance" since both rules prevent teams from "throwing" or intentionally playing beneath their ability

Do you think they'll change the rules to prevent something like this? (How would they change it in that case just curious?)

They might change the game pieces so that the gears have alliance colored tape on them or something, so that you can only use certain gears in each airship

they could also call out this specific strategy and just ban it

Gotcha

I just checked and the noodle agreement ended up being nerfed the same way (using tape to change the scoring of the piece)

(that's why they made that joke)

Also my dad and I were talking about the point difference between a gear bot strategy and a fuel bot strategy, do you think it's possible they'll change scoring for fuel bots and make it a little more equal to score with both strategies?

@Clio Batali I don't think it's necessarily a joke, because it could actually work (but I think they meant it as a joke)

This is the noodle agreement all over again, except for gears.

Someething tells me that with this, along with how gears are so overpowered will lead to a nerf. I can’t imagine this was intentional

Maybe, but they could leave it as-is and give more points to fueling or make it more efficient

That would be better - buff fueling rather than nerf gears

Yeah, they could either bring down the rp point of kPa or they could make 1 kPa + 1pt = 2 fuel which would make a fuel robot a much more attractive strategy than if it was 1 kPa + 1pt= 3 fuel

It'll be interesting to see how they handle it

Or if at all

Check this out (thanks Dana!)

Right now, looking at the low goal during teleop, it seems completely useless in competition to use. It takes so much fuel to get barely any points.

Some people are arguing that the pilots will have a harder time interacting with the rotors than expected, so the gear strategy may not be as good as we think

That's what I thought

@Rose Bandrowski totally agree

It's also so easy to block someone from getting a gear on the peg which concerns me if it also take a high amount of precision.

A defense robot could easily tip the scale in this game if that is true.

I think it would be easier to block a shooter

I don't agree because you have the key to protect you at least somewhat

a defense bot has 5 seconds before it has to leave the key, enough to disrupt multiple shots

and my thought is that it will be similar to last year scoring (when it comes to defense) you can definitely be blocked or defended but how many people will do it.

Let me ask you this, if you're on defense are you going to block a gear bot or a fuel bot?

I would block a fuel bot

My thought is more likely a gear bot, giving the fuel bot an advantage.

I think that just because it's so much easier to score with a gear bot, but also so easily blocked or screwed up when trying to put that gear on the peg.

Maybe, but most gear bot designs involve some sort of passive "holder" for the gear that would be hard to miss with because it just hooks on

Well yeah, but lining it up can be difficult and take some time.

I talked to Robby about this and he said defense was generally not very good at blocking high goals last year, so it would be even harder to block putting a gear on a peg

but you barely have to bump that robot and it's unaligned and can't put the gear on.

Also, the gear bot is more likely to be traversing the whole field, making them more vulnerable to longer cycle times. It would be hard to stop a cycle, but longer cycles mean fewer pts

Agreed

(from defense)

And blocking high goals last year seems more similar to putting fuel in the boiler than it does to putting a gear on peg (to counter robby's point)

I agree, but I still don't think we'll see many defense bots. However, the game pieces could be a huge obstacle so cycle time could be a lot longer

Especially if we push every button early on...

#sabotage

we should do that no matter what robot we make

just to spice things up

I wonder if that'll be a legitimate strategy during the competitions - or if they'll ban it.

They won't ban it as quickly as they'll ban the gear alliance

Agreed

Could be helpful, simplified version of the field. https://www.chiefdelphi.com/forums/showthread.php?threadid=153187

so H10 says Once a ROTOR is started, the PILOT may not remove any GEARS used to start it." but the manual doesn't appear to rule out removing the pre-populated gears in rotors 3 & 4 and using them to contribute towards rotor 2 & 3

That is an interesting catch! And quite possibly why there are pre-populated gears to begin with. (Otherwise what are they for? They could have just made the geartrain for those rotors shorter...)

the manual says they exist to be (potentially) taken away at championships, just like how the 40kPa value may be increased.

@Jim Carr has joined the channel

if we have a Q&A access code, https://frc-qa.firstinspires.org/ might be the place to clear that (and the velcro rope issue) up

One other Q to cover: can gears, once threaded onto the spring, be lifted out of a passive slot on the robot, or does the robot need to backup with the gear staying on the spring before the gear is lifted. There are varying opinions about how that will be ruled on CD

I recommend that we don't rely on the peg to remove the gear from the robot. With 2 pilots an 3 pegs, that might mean that a robot has to wait several seconds while the gear is removed. It would be much more advantageous to deposit the gear and move away on our own.

Of course, that brings up the question of whether an opponent could remove a gear that we placed on one of our pegs...

The scenario of having to wait on a pilot to raise a gear should only occur when all three bots are simultaneously delivering gears, which should be quite rare IMO given projected cycle times, limited (only 2) gear attainment locations, the fact that some bots will be fuel-focused, etc. interesting to ponder the scenarios :nerd_face:

Team Update 01 says no to moving prepopulated gears, even before the rotor is started: H15: A pre-populated GEAR may not be removed from its AXLE.

https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate01.pdf

Also, they now list the capacities of the upper and lower boilers:
The capacity of the Low Efficiency GOAL is seventy (70) FUEL. The capacity of the High
Efficiency GOAL is one-hundred and fifty (150) FUEL. FUEL that exceeds GOAL capacities will
fall back on to the FIELD.

Interesting poll on climbing: https://www.chiefdelphi.com/forums/showthread.php?threadid=153418 It's not surprising over 93% of teams plan to climb because it is such a large amount of points in 10 - 20 seconds and RI3D teams have shown there are viable reliable solutions. An alliance can be behind by more than a full rotor at the end of the game and win if they have one more climber than the other team. I strongly recommend reserving some robot volume for a climber, despite the strategy vote.

@Kenneth Wiersema: do we know that velcro(-tipped?) ropes are legal yet?

@Jon Coonan set the channel topic: Strategy discussion (also use for Rules Q&A)

@Kenneth Wiersema: @Ethan Rininger Also some good q's for the Q/A session (tomorrow!): what constitutes a correct starting position for auto? (ie, does the robot have to be flush to the wall, or just touching it?) Also, some clarification about the key would be great. (what constitutes being "inside"... all or part of a robot?)

I concur with this !!!

In terms of the question about lifting the gear out of the robot while the gear is still touching the robot, it appears you can https://frc-qa.firstinspires.org/qa/1

@Jack Stratton: A questions been asked on it, still haven't replied https://frc-qa.firstinspires.org/qa/6

Thanks Kenneth.

https://frc-qa.firstinspires.org/qa/31 You can't move pre-populated gears.

What about the Velcro on the rope?

Is that allowed

See post directed at jack, Q/A number 6

Thanks

I like how I can refresh those pages and get slightly different errors each time.

I just get it saying that it can't get a secure connection, not sure why

Did anyone else notice https://frc-qa.firstinspires.org/qa/4. It says "There are no rules that require a ROBOT remain within its FRAME PERIMETER beyond the start of the MATCH (required per G1-C combined with R2). Rule G4 requires only that it remain within the volume constraints defined in R3 during the MATCH." It was asked in the context of moving mechanical extensions, but I wonder if it also means ball storage could extend over the bumpers after the start of the match, maybe by using a stretchy (but strong :)) wall material? Or maybe shaped flexible material (think pop-up tent or soft luggage with expandable volume capability)

Most of the entrees regarding velcro as rope haven't been answered, and most other materials, except for a couple, so there might be a rule clarification coming up about it.

Update: The "loop" side of velcro is allowed for the rope

Please read all !!

Thanks Chris M. for sharing !!!

Rules update 3: https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate03.pdf

And no placing gears on to the field via the overflow loading station.

I found some good photos of field elements on Flickr from a team that was at the live unveiling: https://www.flickr.com/photos/ligerbots/albums/72157678872068725

Everyone should look for details that could us design our robot to take advantage of the field.

Someone should thank the @LigerBots on Twitter for posting these photos. As far as I can tell, they're the only ones to make their photos public (so far, at least).

And by "someone", I mean @spartronics4915 :-)

Thanks !!Riyadth

I read a thread a while back that pointed out a tactical advantage of handheld game (e.g. xbox) controllers over flight sticks: the fact that the driver can walk around outside the driver station to get better sight lines. I guess in past years, drivers would sometimes use extra long cords and walk all over their alliance's side, and this year they're clamping down on that a bit by limiting the range to 1/2 driver station away. But I still think it's an interesting loophole, and with the arguably poor sight lines of this year's game, it might be worth looking into as another option to enable hardware & programming wise.

I think that would be worth a try, and I don't think there would be much of a programming overhead.

I haven't heard any discussion by the team regarding adjusting the priority of climbing (possibly because decisions have not reached the programmers yet). I would like to provide some encouragement toward the inclusion of a climbing system, as I feel it is a crucial ability to differentiate our robot from others. I think the information that @Chris Rininger found on Chief Delphi should inspire us to try and achieve climbing as a stretch goal (meaning we should start thinking about it sooner than later).

+1 to what @Chris Rininger & @Riyadth Al-Kazily said

Team update 4
https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate04.pdf

I think Clio mentioned it, perhaps in a different channel... If you're interested in the climber, please join the climber channel & contribute. Thank you!

Team update 5
https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate05.pdf

Bumper team might want to take a look

Thank you Kenneth

Team update 6 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate06.pdf

Autonoumous startegy ?

Is there any rule about where the robot starts from in autonomous? All I can find is that it is a foul to go into the opponent launchpad (A04). Q386 asks a similar question but no answer yet.

Touching the alliance wall is the only restriction as far as i know

I can't find that in the manual. Only the video said that....

7.1 G01 is the rule you're looking for

Ok thanks

So for autonomous strategy, a lot of possibilities: where to start on the wall, one shooting location (unknown yet), 3 gear positions, the baseline, and 2 hoppers (near and middle). Which objectives you pick and how flexible you want to be to alliance partners will determine how many paths need to be coded and which sensors required. Thoughts? Anyone working this?

I think that vision really is required for most of our auto programs we want to be doing. Since our position on the field is completely based on eyeballing it, we can't rely too heavily upon "drive x feet forward then turn y degrees" type programs.

At this point we're planning on using distance sensors (either optical or ultrasonic) to track distance to the walls, as well as the imu for more angle-specific turns.

With those combined, I believe the shooting auto should be doable, but it's hard to say where we stand on the gear auto since that system is still somewhat amorphous and we don't know how accurate our aligning can be. That's something really worth testing once our distance-specific auto driving is fully functional

It is my understanding that the primary autonomous strategy would be to shoot 10 balls into the high boiler, and then cross the baseline. That may be incorrect. I have not put much thought into the gears, as I do believe that would require vision to be successful. But I'm looking forward to a good discussion about the pros and cons of different autonomous activities.

As far as the use of distance sensors, the thought would be to start from against the field wall, move slightly away from the wall and drive towards the boiler, while keeping our fixed distance from the wall. The front corner of our robot would contact the boiler (and we may need an additional sensor for that), and then we turn so that the front edge of the robot is touching the boiler. If we pick our distance from the wall carefully, we should be able to align our robot in the middle of the boiler wall by doing this. Once we detect (with yet another sensor?) that we are flush with the wall, we fire up the launcher and empty the hopper. (We may want a sensor to tell us if the hopper is empty, or we just run it for long enough that it should be empty...)

After unloading our fuel into the boiler, we could simply use the gyro and encoders to drive across the baseline.

We have to remember that we need "mirrored" sensors and autonomous programs, as the orientation of the field is reversed on red and blue alliance sides. We might have the wall on our right when moving to the red boiler, but on our left for the blue boiler. (Unless I got those backwards...)

At this point, it will be important to understand our robot's driving capabilities. I recommend mimicking the physical layout w/ boiler ( @Clio Batali, you may remember our discussion on how we can use the hallway for creating the autonomous layout). Then, drive the robot at low speed to test the theory and layout a map of what needs to be executed during autonomous. It needs to be a step by step plan that driving team can build. We'll start with the happy case (assume best starting location) and then add the other edge cases iteratively.

@Lia Johansen has joined the channel

Rules update 07 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate07.pdf

Rules update 08 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate08.pdf

@Ethan Rininger scouting ideas?

I'll go on chief delphi and look at what some other teams are doing

I was thinking of having the scouting sheet rate the team on different categories from 1 (did not do or completely ineffective) to 5 (very effective) rather then record actual numerical data for everything.

This is a scouting sheet from team 3937 "Team Breakaway"

Something I remember our past scouting teams have had issues with was interpreting the data - keep it in mind

Team update 09 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate09.pdf Very small I04D addition, otherwise nothing important.

Team update 10 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate10.pdf I think there is some stuff that electrical/programs should look at.

Here's the 2017 inspection checklist v1 https://firstfrc.blob.core.windows.net/frc2017/AuxDocs/2017FRCInspectionChecklist.pdf.

@Lia Johansen ^^^ see reference to firmware versions.
PS. this reminds me — before bagging, lets test our tethering to the robot to ensure we are ready for competition day

@Binnur Alkazily: Thanks. That is a good reminder!

Rules update 11 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate11.pdf Inspection checklist rev1.1 https://firstfrc.blob.core.windows.net/frc2017/AuxDocs/2017FRCInspectionChecklist.pdf Robot lock up form https://firstfrc.blob.core.windows.net/frc2017/AuxDocs/2017FRCRobotLockupForm.pdf

Here's what I have for scouting so far. https://i.imgur.com/H79nK9O.jpg https://i.imgur.com/CaxSRSvr.jpg

Rules update 12 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate12.pdf Rev 1.2 inspection sheets https://firstfrc.blob.core.windows.net/frc2017/AuxDocs/2017FRCInspectionChecklist.pdf V1.1 of the lock up form https://firstfrc.blob.core.windows.net/frc2017/AuxDocs/2017FRCRobotLockupForm.pdf

https://m.youtube.com/watch?v=SG9ep-NBtg Andy says we should bag heavy spare parts so that they don't count as holdback. Are spare parts now considered holdback? What's the official rule on this?

thanks Alex for posting

Week 0 matches have already started. Watch the streams and learn what to expect when we're on the field:
https://www.thebluealliance.com/gameday#layout=1&view0=2017week0-0&view1=2017week0-1

^^^

Currently watching - I'm seeing a lot climbing, balls on the ground, and not a lot of accurate shooting

Usually only 1 shooter per alliance

And a lack of accurate autonomous shooting as well - I've seen a lot of teams shoot in autonomous and miss

Please make prettier

working on it

Do we want to color code the different sections/catagories or just seperate them off from one another

@Kaedric Holt has joined the channel

I'd like to color code them but we can't print 500 color sheets (or even black/white with backdrops, like the scouting sheet you linked has)

Looking at R21 the WITHHOLDING ALLOWANCE is made up of fabricated parts that weights up to 30 pounds. Later it says that "This means teams may not store FABRICATED ITEMS outside the pits to be brought to the event at a later time. This set may be changed between events (i.e. a Team may leave a different set of items out of the bag and/or fabricate new items to bring to their next event"

So there is a limited amount of fabricated items, but there is an unlimited amount of COTS parts. And a COTS part that has been modified for the robot becomes a FABRICATED ITEM.

So we want to store our spares with the robot in the bag because the hold back counts spare parts and robot parts the same as fabricated item.

This should be our answer to the question of the spare parts/withholding allowance.

thanks

joncoonan: autonomous shooting is hard to do. Have you noted any key starting positions that we need to be aware off??

They keep changing positions. I think they are using the time to debug and vary positions

Rule update 13 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate13.pdf

@Kenneth Wiersema: looking at new rules, it is not clear to me that the drive team can bring a wrench to release the climber brake. A past Q&A said yes but now this rule could be interpreted as no. Would you please confirm?

I would go off of the Q&A answer, as a wrench wouldn't be considered a safety hazard by their examples, and I can't find a specific rule banning use of tools. @Chris Rininger

Rule update 14 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate14.pdf

@Brian Hutchison has joined the channel

Rule update 15 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate15.pdf

Had the opportunity to watch some matches around the country today. Some observations: highest scores are around 300 (150 from climb, 140 from gears, and a few points from fuel or penalties). Average winning score is around 200 (2 climbs, 2 gears). No one is shooting low goal, and very few shooting high goal ( average points from fuel per game is around 3). So I look forward to seeing us fill it up, but we will need to balance our desire to shoot with the scoring needs of our team. Just too many points associated with gears and climbing so they should probably come first; work it out ahead of each match with alliance teams.

In fact, after 2 or 3 matches, I think scouting will almost be able to predict the score of each match, since it's so tied to whether each robot can climb and do gears. As such I'd like to see scouting hand the drive team a sheet before each match that Clio can use to determine strategy with our alliance partners; how many points can our team realistically get and how (versus the opponents).

Other observation was a lot of yellow cards. DO NOT enter the field until the GREEN light is on (field crew goes in first on the purple light). And DO NOT reach into the portal to grab a gear or anywhere else into the playing field.

Oh and I saw at least two robots fall during a climb (ouch). And at least two robots where the gear got dropped into their intake or launcher (one got a yellow card for "launching" the gear by reversing their intake!).

Great advice John !

One thing more tactical: it seems with passive gear drop off there can be resistance that causes the spring to bend as the gear is raised. If the airship pilot jerks the spring up too fast the gear can fall off. So it seems wise to lift fairly slow and smooth until the gear is fully clear of the robot. And then can speed up the lift. Pilots whose team's robots can drop off gears may not be thinking about this, so this is probably something to cover in pre-match dialog.

Great advice again . I hope driving team are reading .

Scouting results sheet for day 1: https://docs.google.com/spreadsheets/d/10O7tD6sIjTyNUuUSFkaaKMt05QVWd8Lm3HA3vMm6Ucw

@Finn Mander has joined the channel

Good read for playoff strategy: https://www.chiefdelphi.com/forums/showthread.php?threadid=156409. My take away: get an advantage in fuel, get 3rd rotor as fast as possible, the defend against other alliance getting 4th rotor (&climb of course)

@Jeremy Lipschutz has joined the channel

@Adrianna Carter has joined the channel

if you are scouting, please make sure you are at the stands scouting!

As of Q79

We got first in qualifiers?!

When you're trying to figure out how you beat the sonic squirrels

Thank you to all of our mentors, we couldn't have done this without you.

@Cruz Strom has joined the channel

Scouting things, in no particular order

- we printed 450 match sheets, which was fewer than (# matches * 6) yet there were still (estimated 40 on the clipboards plus however many were still in the box) blank ones left over
- didn't use pit information at all
- why did we pick 3223 again?
- a good number of sheets were "filled out" almost completely blank
- might as well just take everything intake/shooting related off the sheets, if something's really exceptional put it in comments
- even though I sent out two teams, the second with a specific list of who to visit, we only hit like half the pits

- I feel like we need a better scouting box system but I don't know what to replace it with

I saw irs's scouting box they had a bunch of folders in it, maybe that could work? (Also yeah I never heard our reason for picking 3223 although they did well)

we used to have a folder for each team, the only reason we didn't this time is because we didn't order any folders.

That seems like a lot of work

I could save some space by generating 12 sheets for each team with the right match number and team name already filled in on their sheets, if that would help

it was a lot of work

Maybe - could be good for accounting which matches were not scouted

Curious, what does SkunkWorks do for scouting? I remember they had a class on their methods during their visit thing

@Jack Stratton I suggest one sheet per team, with 12 rows down (1 for each game) and whatever columns you need for tracking stats. Collect the sheets at end of match and hand out the next batch for the next game. Benefit of one sheet per team is that at the end of day one you already have a summary of each team. Also less paper used and less paper tracking.

Double side for more space

Yep

the issue with that is finding the right sheet for the right clipboard six times between every single match

each team is going to be in every location at least twice, we can't stack sheets up in the order shown in the match schedule unless the sheet is not per-team, but per-station

we tried to distribute sheets like that I think two years ago, it's a lot of work especially given how far away from each other scouts seem to always sit

(it's easy enough to write a script to generate per-station sheets but the match order isn't published until basically the morning of the matches, so we'd need to make sure the printer is available asap.)

Here's the rationale for 3223: There were very few par teams left, and based on our scouting and the necessity for a climber, our list was basically down to Spartabots and ROCK. No one else who hadn't been picked could climb with some amount of reliability. As for the choice between those two, I had previously looked at the most recent scouting data to see what the most pertinent status of the robots said, and saw that Spartabots had been breaking down all day, with few successful climbs, while ROCK was relatively consistent. Both at peak operation could climb and place 2-3 gears generally, but I decided that a reliable climb was the key consideration.

@Dana Batali has joined the channel

@Terry Shields has joined the channel

Another defensive strategy some teams did when we were on the field (knowing we were the best shooter) was to send a bot to crash as many fuel bins as possible -- knowing that it was much less efficient to vacuum up balls vs. filling our hopper. Sooo... getting a reload of balls as early in the match as possible strategically helps a shooter bot.

By the end of the competition we were just as efficient picking up from the floor as we were from the hopper

Perhaps a strategy we should keep in mind when we face another shooter bot in competition who doesn't have a good intake

(if that happens, i haven't seen many robots with a shooter that didn't have intake)

my sense was similar to will's: that the hoover was as fast or faster than the "big drop"... This wasn't the case, i think, 'til after the intake had been broken, then fixed around mid competition.

Good point Will and Dana. I forgot about the intake improvement mid-competition.

here is a chief delphi thread on the accuracy of the boiler counting mechanism:

https://www.chiefdelphi.com/forums/showthread.php?t=156533

Not that accurate but wow still

I wonder if we'll see a shooter that's accurate, fast, and can hold a lot of fuel. that'd be amazing

Bear metal has the capacity and speed, just need to get there on the accuracy front

Am I right in thinking that a faster shooter decreases accuracy?

https://youtu.be/oRtaGtriAAI

annoyingly intriguing autonomous from citrus circuits: side gear PLUS hopper-fed fuel and FAST shooting (though not as accurate)

another shooter: https://www.youtube.com/watch?v=1twnsPUhms

@Brian Hilst has joined the channel

A few more observations where I think #programming can help:

1. Improve driving accuracy, especially at slower speeds. A lot of time was spent trying to accurately drive up to the ball and gear loading/unloading stations. Do we need vision adjustments also?

2. Adjust the autonomous strategy after shooting to either better line up for the gear drop or hit the closest ball hopper to load the balls. We will still cross the line in both cases.

3. Add an autonomous strategy to drop a gear at the side station. I think we can do this with our accurate driving ability.

@Declan Freeman-Gleason Are you still considering building a scouting web app? I would be willing to help with that so we don't have to manually enter all the scouting forms.

@Jack Stratton My suggestion of using one sheet per team is predicated on not assigning scouts to positions/stations. Just hand out the 6 applicable sheets before a match, and sort/file them by team number when you receive them back. Shouldn't be to hard to find 6 sheets out of 40 in the 5 minutes between matches.

Regarding web apps, note that we probably won't have good network connectivity at Glacier Peak. Auburn Mountainview was exceptionally nice in that they had WiFi available, but most events are not so lucky. And at Glacier Peak I've had trouble getting enough AT&T signal to even make a phone call, let alone get to a web page.

That said, if some "offline" app could be used, and then the data synced up later, that could be useful. I have a couple of older iPads that I could lend for the cause.

I saw a team that had a scouting app but unfortunately not for iOS

Take a look at it?

Maybe we use a spreadsheet application (like Google Sheets, Apple Numbers, or Microsoft Excel), define some fields for scouting data, and find a way to export the files so they can be combined easily.

@Riyadth Al-Kazily I would use Firebase (https://firebase.google.com) which will store data when offline and subsequently sync it.

If we choose to make a scouting app.

Using someone else's would obviously be easier.

Someone should totally check out this app for scouting. Look at the number of the team that made it!
https://itunes.apple.com/lv/app/cardinalscout/id1106712826?mt=8

check out this robothttps://www.youtube.com/watch?v=ewTCvLp5EUo&feature=em-subsdigest

We should look at how they integrated their circular agitator with their hopper and see what we can do to make ours similar

I like the 5-motor flywheel drive system! That's one way to get enough oomph for fast shooting.

@Riyadth Al-Kazily : nice find! Do you think they are running all 5 off one motor controller? Looks like that might be true.

Wow that's impressive! So similar to Helios conceptually

So interesting that they have their gear mechanism on their intake. Smart!

What I find impressive is the "whole robot" design... like the way a gear and then fuel can be onboarded with just a little tilt. I wonder what their holistic design process is... could ask them. Very cool!

Though I can't see their climber working very well it seems such a small space for the rope that the driver would have a hard time getting it with those last few seconds to climb.

Yeah you should ask!

I think they have multiple motor controllers. I see at least two right below the group of motors. And I don't think you are allowed to run more than one of those motors off of one controller.

I assume they are putting 4 controllers in follower mode, and using one as the master.

I didn't see where their encoder is, but they must have one somewhere.

@Rose Bandrowski I think it would be better for a student to ask :-)

Okay I can ask them.

I sent them an email :slightlysmilingface:

agreed! :slightlysmilingface:

West Valley event match videos have been posted to YouTube: https://www.youtube.com/playlist?list=PLwES-SbpsnxyNM0BptRnmnXJrBc1Hba2w

Rule update 16 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate16.pdf

Rules update 17 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate17.pdf

Watch team 4613 in auto go to hopper and then to high goal and shot fuel. Fixed shooter. Event is going on now in Australia

https://www.thebluealliance.com/gameday#chat=tbagameday&layout=1&view0=bluezone-0&view1=2017ausc-1

We should try to program our robot for this. Can we do it programmer ?

coachchee: if we have a practice field available at glacier peak, I'm sure we could do it

Why not setup at school and do it ?

I can't recall having a practice field last year but my memory may be bad

There is a practice field

We're going to spend most of our 6 hour unbag working on the robot i'm pretty sure

It is behind the curtains at glacier peak

Okay I just didn't notice

Here is a YouTube link with their autonomous https://www.youtube.com/watch?v=k2pWR593tqI

I don't think it should take us the entire 6 hours to fix the robot. If we could get this autonomous working that would be great

Thanks @Will Hobbs for sharing. It should take 4 hr to repair robot. @will plese post your video in programming channel

That'd be pretty awesome if we got it done, go programming go!

@Enrique Chee : declan says he has the field measurements (measured them at auburn) he will work on the camera and programming just the distance movements this upcoming week. We will use the second chassis. Since we have limited time (us programmers) with the robot it will be a stretch. I could be hopeful about getting it to work for auburn but im not 100% sure. @Declan Freeman-Gleason what is your feeling?

There are a few more measurements I might need to figure out, but that's not the hard part.

We need to increase the speed of pretty much all the autonomous movements.

That's the hard part.

And most importantly, we need to keep the original (working) autonomous code completely untouched. It would be bad to break what is already working while reaching for our stretch goal.

I would also recommend that someone get realistic values for the time it takes to empty a hopper (so we can know how long to "pause" at the hopper) and also what our actual shooter rate is (with a "full" hopper). And we need to keep in mind the processing time of the boiler, as the last few shots in autonomous probably won't count at the autonomous rate.

(To time the hopper emptying, we could find a few videos posted on YouTube and time what we observe)

Based on what I have seen it takes about 3-4 seconds to empty a hopper

@Declan Freeman-Gleason we discussed things to plan around this during the open house. here are couple of other things to think
path + process to trigger the hopper — where our robot hits the hopper will determine how many of the balls will make into our ball chamber. as we don’t have this setup here, this is something that needs to be optimized/improved during the competition. probably using percentVbus and ramming into the hopper is a good approach (over trying to be exact w/ encoders)
as the balls will be everywhere, probably need to run the intake as we approach the boiler to make sure we can still dead recon it
faster tuning for the shooter — last I recall we were ~2 balls/sec — as @Riyadth Al-Kazily pointed out
if we still have time to make it across the baseline (though it is only 5 additional points…), run the intake to see if we can pick up other straggler balls

@Lia Johansen if this is a go, we’ll need to make sure programming team has access to the robot for continuous tuning between the competitions — please be ready for that

This is my priority list, which @Binnur Alkazily and I discussed:
Before we have the robot:
1. Measure the field for our regular movement and aligning with the gear
2. Measure the field for our stretch goal with the hopper (I already have some measurements for this)
3. Add the first measurements to the code on the main branch (this is a low risk addition)
4. Add the second measurements to the code on a separate branch
5. On that separate branch, get curved driving to be more accurate (I have an idea on how to do this)
6. Maybe speed up other pieces of autonomous (although curved driving is going to be the first thing I try, and then speeding up other things, a large change, will come later)
Once we get the robot:
1. Get the cameras working
2. ^Impliment and test everything above :sweat_smile:

Is there anything anyone else would like to add/would like to do with the robot?

For auto to the hooper, we should align the robot along the key line . So the robot is not placed flush with the wall, rather should be placed at an angle with just the corner in contact with the wall of the field. See this for reference. https://www.youtube.com/watch?v=k2pWR593tqI

@Jack Stratton your record/playback available for doing this move is another one we should plan for — as I recall, you need to have record buttons remapped. unless there is an objection from programming team lets plan for that as well as

FirstWA has just now started posting the videos of the Auburn Mountainview event on YouTube:
https://www.youtube.com/playlist?list=PLwES-SbpsnxyFZ0HbHDeZVoCDW0zrnl7l

It looks like they're only posting the Mount Vernon videos from today on that playlist :cry:

They have just started posting the Auburn Mountainview videos now I believe

@Ethan Rininger I won't be at the district championship, so I suggest you either handle scouting there or find someone to take care of it. note that there are 64 teams going and 128 qualification matches instead of the ~70 we scouted. that means the existing system will probably need some changes because 768 sheets of paper won't even fit in the box, never mind be easy to enter into a spreadsheet

taking in to account the previous ideas in this channel for compactness

I suggest getting ahead of the curve, and start scouting the teams before you go, using video from YouTube. At least capture all the basic information from each bot, so you can classify shooter vs. gearbot. Things like "pick a gear from the ground" should be easy to determine. Maybe assign team numbers to several Spartronics members, and have them fill in a Google sheet? (No idea if this would be useful, so take the suggestion with a grain or two of salt)

@Ethan Rininger here is my source file if you don't want to completely start over for districts

I think a more spreadsheet oriented version would help, if not having a comments field is a tradeoff worth making. up to you guys

want to make sure you saw Rose's and John's comments

The Mount Vernon rankings are out and I was wondering if that could help us.

At our next event we are going to use a new method of scouting. We are going to use an app called SpeedScout17. It is usable offline because at Glacier Peak there is no wifi or cell service. In addition to that we also have a comments sheet to write down stuff about individual matches. Be sure to download the app before the competition date

Okay

Is that for Android or iOS? Or both?

I have it on my iphone thus far

Both - more details coming soon in #announcements

If the team needs extra devices, I have a couple of old iPads you could use

Have you though of how to get the data off the devices at the competition? Where there is no network?

Data is compiled afterwards at the hotel - the app stores the data on the device it is installed on and can then easily be exported via .csv files and placed into a spreadsheet via a script. Comments are placed in manually based off of the above sheet

But what about the last few matches on the morning of alliance selection? Do you make your choices before the qualifications are over?

We do that anyway. At the very end I think we'd probably be running more off the comments

Last time it worked well having people individually scout teams on the second day. I reckon we go for that again

We could use this new system for the first day and then narrow down on the second day

Please make sure whoever you assign to scout are staying in the hotel with us. Jack C., Jack S, Timo, Declan, Finn, Lia, (6) These 6 are staying with the team.

The following are staying in the same hotel with their own family. They are Ethan, Brian, Mike Nelson (3) . They can also scout. Please make sure all 9 have devices with the APP. If they get tire maybe they can lend their device to the other teammates (10) who are not staying overnight.

FYI, not the entire team is on this channel. Only 43 out of 65 (mentors and students).

I've been told a proper announcement will go out

Rules update 18 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate18.pdf

@Riyadth Al-Kazily any spare iPads would be amazing; I have a feeling some people will forget to install the app / have phone troubles

@Enrique Chee who are the other 10?

They are James Slattery
Noah Martin
James Sovick
Andrew Peterson
Kaedric Holt
Chris Mentzer (staying overnight )
Cruz Strom
Lucas Nalley
Rose Bandrowski
Samantha Rosen
Sophie Holzer
Sean Hooyer

Just in case you don't know, the app requires IOS 10.2 or later, people with iPhone 4s' or earlier won't be able to download the app.

I noticed that myself.

Okay

@Jack Chapman, @Timo Lahtinen, @Lia Johansen, @Ethan Rininger, @Brian Hutchison, @Michael Nelson: since you're staying the night, install the scouting app linked in #announcements because we're putting you on scouting duty Saturday. You can trade off with @James Slattery, @James Sovick, @Andrew Peterson, @Kaedric Holt, @Harper Nalley, @Sean Hooyer, @Samantha Rosen who should also install that app to get ready to take over. the links are in #announcements, it's SpeedScout17

to be super clear: position 1 is always the team whose station - not robot, but station with the team number LED sign - is closest to the boiler. on both red and blue. no matter what side of the field we sit on. (who gets to scout what station will be figured out later, but everyone needs to know this)

@Enrique Chee I'd like a short block of time at the hotel friday night to ensure everyone has the app, knows what our priority scouting items are (gears + climb is way more important than accurate fuel numbers, etc) and how the data will be sent back.

Thanks for clearing this up. @Jack Stratton . Yes for Friday night.

thanks

@Jack Stratton i am charging the iPads and will install the app this evening. Do you need them before Friday?

On the app it counts high boiler balls by 2? Shouldn't it be three??

I don't think so

@Jack Stratton Can I be scouting Saturday too? I was under the impression that I already was but didn't see my name on your list. It looks like we already have 6 people though.

certainly

Speedscout17 just added an update allowing comments on individual matches

If you are staying overnight , you are scouting both days. @Finn Mander

Great, thanks!

Also @Brian Hutchison will alos be staying overnight so he can also Scout.

also

Here are some more teammates staying overnight at GP that can help scout. Julian Bonifaci
Niklas Prün
Michael Nelson
Luke Frank
Peter Hall
Brian Hutchison

Julian julian_bonifaci

@Jack Stratton Unfortunately the scouting app requires iOS 10, and my iPads are too old to upgrade to iOS 10. Looks like they will not be of use to the team.

thanks anyway

My email:

Jack C: Red 1
Finn: Red 2:

Timo: Red 3

Lia: Blue 1

Ethan: Blue 2

Brian H: Blue 3

Scouts: try and find which springs aren't functional so you can tell the drive team

The attached file may help the scouts. It show all the district teams in order of district rank, and what events they have participated in so far. The 40 teams competing at Glacier Peak are highlighted in YELLOW. We saw 18 of these teams at Auburn Mountainview.

Thanks Terry !

@Ethan Rininger @Luke Frank @Sean Hooyer @Harper Nalley @Andrew Peterson @James Slattery @James Sovick email your scouting data to if you have any

@Sean Hooyer has joined the channel

@Andrew Peterson has joined the channel

@James Sovick has joined the channel

Rules update 19 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate19.pdf

I know we are looking for gears now, but if we got on a team with 2046, we may want to go to balls, they can get about 34 KPA in a match by them selves

Teams that we could get 40 kpa with: 4488, 2471, 4918, 2046. These teams are all getting 30ish on their own, and they shoot from away from the boiler. If we're on an alliance with any of these teams 40 Kpa is a very likely possibility.

Hello to all those who are attending Cheney! In order for us to get a general idea of how our competitors preform, you all now have a scouting assignment to complete before Wednesday (Which means you have to do it tonight or tomorrow).

Each of you has been assigned teams to watch and take notes on. You should be watching 4 matches per team. On this document (https://docs.google.com/document/d/14WyjlZ4nckBn7PPy-rplstqDkr5kBB80aJOJuFkgi9o/edit?usp=sharing), write up your notes on that team's averages during their matches. You can see what a completed page looks like on the first page.

I would recommend using the Blue Alliance (https://www.thebluealliance.com/) to find your team, and videos of their matches should be linked. Please make sure you are scouting their most recent event.

Put a check mark on this post if you have read up to this point.

Assignments:
@Sean Hooyer : 492, 753
@Michael Nelson : 948, 955
@Andrew Peterson : 957, 997
@Lucas Rininger : 1318, 1425
@Ethan Rininger : 1540, 2046
@James Sovick : 2147, 2148
@Bo Baird : 2374, 2471
@Rose Bandrowski : 2521, 2550
@Clio Batali : 2811, 2907
@Jack Chapman : 2980, 2990
@Jon Coonan : 3024, 3219
@Declan Freeman-Gleason : 3223, 3238
@Will Hobbs : 3393, 3663
@Sophie Holzer : 3674, 3693
@Brian Hutchison : 3711, 4061
@Lia Johansen : 4125, 4173
@Timo Lahtinen : 4450, 4488
@Alex Larson Freeman : 4495, 4513
@Charlotte Larson Freeman : 4662, 4918
@Chris Mentzer : 5085, 5198
@Harper Nalley : 5295, 5450
@Samantha Rosen : 5468, 5920
@Marie Sachs : 5937, 5970
@Cruz Strom : 5975, 6343
@Kenneth Wiersema : 6350, 6445

@Michael Nelson has joined the channel

@Bo Baird has joined the channel

Please make sure you put your name in the comment section for each robot that you scout

Who did the scouting on APEX and Sotabots?

@Timo Lahtinen You only assigned 50 of the 64 teams

Who will be scouting the other 14 teams?

I just put in the data from the scouting at Glacier Peak, for those teams that didn't have a new match this past weekend.

Can we add in the comments from the scouting

Please make sure your name is in the comments section of the teams you scout. Also please adjust the size of the picture to get all of the data to fit on one page

The document should only be 64 pages long.

I would like to have the document completed by 8pm

2148 and 5937 have declined to go to regionals so we don't need to scout them, however we now need to scout 4131 and 488

Rules update 20 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate20.pdf Not really worth posting, but just for keeping up.

Scout Assignments:
@Lia Johansen : B1
@Samantha Rosen : B2
@James Sovick : B3

@Sophie Holzer : R1
@Ethan Rininger : R2
@Brian Hutchison : R3

They are a good solid gear bot, with a fast climber

But what about shooting, their efficiency with gears and what do offer us

4131 and 2980 dont shoot, but I think we could get 4 rotors with them.

Just curious, does that help/|\ @Clio Batali ?

Oh, shoot, we're not with 4131 in QM-60, we're with them in QM-76

Thanks - we've been checking pre-scouting data periodically for the robots we're with, but yes, information is always useful.

Okay

Send scouting data to

^^^

Evan from 5803 mentioned us : https://www.youtube.com/watch?v=Y5IKRPCggs

About 5 minutes into the video.

https://www.youtube.com/watch?v=TZxEP8N4Nx4&t=4240s

Listen 1 hr into video about the cheesecake and Vihillabot

https://www.chiefdelphi.com/forums/showthread.php?threadid=157772 Thoughts?

Who will signup ? Timo ? Captains please take the lead on this.

Ethan ?

Last one, rules update 21 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate21.pdf

if you are attending worlds please read below carefully. In order for us to get a general idea of how our competitors preform, you all now have a scouting assignment to complete before Monday.

Each of you has been assigned teams to watch and take notes on. You should be watching 4 matches per team. (watch their 4 most recent matches) On this document write up your notes on that team's averages during their matches.

I would recommend using the Blue Alliance (https://www.thebluealliance.com/) to find your team, and videos of their matches should be linked.
Please make sure your name is in the comments section.

Put a check mark on this post if you have read up to this point.

Assignments:
@Bo Baird 114, 281, 604, 832
@Jack Chapman 1319, 1410, 1619
@Jon Coonan 1778, 1836, 1868, 1912
@Luke Frank 2230, 2383, 2444
@Will Hobbs 2583, 2587, 2682, 2848
@Peter Hall 2896, 2903, 2910
@Brian Hutchison 2996, 3039, 3132
@Timo Lahtinen 3562, 3835, 3931, 4005
@Alex Larson Freeman 4400, 4401, 4403, 4488
@Ethan Rininger 4513, 4613, 4915
@Lucas Rininger 4941, 4944, 4965, 5002
@Cruz Strom 5429, 5431, 5454
@Kenneth Wiersema 5496, 5516, 5588, 5663
@Clio Batali 5705, 5737, 5818, 5887
@Sophie Holzer 6023, 6055, 6305
@Lia Johansen 6366, 6429, 6434
@Charlotte Larson Freeman 6517, 6739, 6754
@Chris Mentzer 2534, 1744
@Finn Mander 2950, 4635, 5458
@Marie Sachs 6340, 3309, 6442

If you have any question please ask @Timo Lahtinen or @Will Hobbs

When we arrive we will also be sending representative to each pit to confirm our data.

@Lia Johansen I see you are scouting 6429 (https://www.thebluealliance.com/team/6429/2017) This is a Turkish team -- it would be great if you go visit them at the competition :slightlysmilingface:

https://docs.google.com/document/d/1JUwQUKxYPr5j50ACvnsCQ6AcjXO11uep7qALbt9y5s. Here's the link to the document

@Will Hobbs I wasn't given an assignment

Ok

I will reassign some teams to you tonight

Ok, thanks

I have edited the list above and assigned you three teams

Please assign Marie, She will be there on Wed. Finn you are on the list.

He added it in afterwards, but thank you

I have updated the assignments.

Who is taking lead on this ? Timo ? captains ?

https://frc.divisions.co/r/south Pretty cool website for statistics. 3238 has 1.2 more gears scored on average than ANY other team at the competition!

One of the teams assigned to me for scouting is going to St. Louis not Houston

What team?

2534

Also 1744 was already filled out though there is no name in the comments

All of them look like they have been filled out since I copied and pasted from the district champs scouting

Just delete what's there now

Will , you should clarify that your google doc contains info that you copy and paste for each team and you should delete them all before everyone looks at them. It will be very confusing if the data was copied and paste vs our team adding that data.

I will delete all of the data that was copied and pasted when I get home tonight

Did anybody ever respond to this?

@Timo Lahtinen

I have not

Can you please do that

And who are we sending

Myself and two others I suppose

You only need to send 1 representative if I remember correctly

well they say on there at least one, but three preferably

Ok

http://firstfrc.blob.core.windows.net/frc2017/FIRSTChampionship/CMPTX/Hopper.pdf

looks like we're playing in match 1

We are playing match 1, 19, 31, 39, 49, 64, 77, 89, 94, 106

Ok, @Finn Mander is the other scouter we will be sending to help the joint effort, and we'll just send two scouters to it

Ok

@Will Hobbs I'm going to try to clean up the scouting document a bit to make it so that there is one team per page.

Thank you

Rules update 22 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate22.pdf All about the festival of champions, not specifically pertaining to us.

Not yet ;)

I am going to print the scouting data and put it in a binder

GOOD IDEA !!!!

Is it filled in ?

When you guys scout at the pit to confirm this data, how do we update the binder ?

there is enough space on each page to add more information

Everything is printed and in a binder. I will put a pen in the binder and when we scout in the pits people can add notes in the margin

What is the assignment for the pit scouting ?

Are you asking who will do the pit scouting?

Yes , same list as the binder scouting ?

We will have two people probably timo and one other go around to all of the pits

I can do it

Time and another person will take about 4 hrs. I suggest more than 2 people.

Timo

@Paul Vibrans has joined the channel

@Timo Lahtinen

Sorry for the confusion. This is the schedule for matches that Timo and I will be scouting tomorrow, not our match schedule

Congratulations on good plays for Spartronics :slightlysmilingface: and condolences for failures by alliance partners :disappointed:. Never give up!!

What're we ranked?

http://frc-events.firstinspires.org/2017/HOPPER/rankings

51 right now

Match results are here: http://frc-events.firstinspires.org/2017/HOPPER/qualifications

Thanks!

@Timo Lahtinen that is awesome!

A mentor friend from 4911 reminded me today that there is an open invitation for our team to collaborate on and utilize a scouting solution they've created. It involves cheap android tablets (like the $50 Kindle Fires work) for compiling data in the bleachers + a laptop-based server to which the data is uploaded via bluetooth. I believe it also includes Tableau integration. They're able to turnaround aggregate data views quite fast she says. Please let me now if there is interest. Thanks!

Whoa, that's really cool. I'm certainly interested. It's already created?

They used it last year as I understand. I recall her saying there were some minor glitches at times that they worked around. It is a tech solution that would likely need some participation from a programmer. How about this: I will let her know there is interest and ask what skills would be required to participate and use the solution effectively.

Yeah sounds good, I'm not a huge programmer myself (although, trust me, I've tried). So I'd love to see the more avid programmers on our team take this up.

@Rose Bandrowski I got some more information about what would be required to collaborate & set up the solution. Since it is true the solution will require programmer/techie contributions, I will post it over on the programmer channel. Anyone interested should join in over there.

@Chris Rininger Okay, thanks!

Does anyone have the KOP 5-license code for Tableau by chance? My mentor friends from 4911 are still working on enhancing their scouting app (see posts from June), and I told them I'd try to come up-to-speed on the Tableau data analytics and presentation layer. Thanks - BTW if any students are interested in learning about Tableau as well in the context of analyzing scouting data, let me know.

try this… it is from dec 2015 —
Code: TDNT-75DE-5660-02EB-2710
http://www.tableau.com/first-robotics

Here is the current Tableau code for 16-17:

TDPO-C821-28C0-B3B0-AF29

Enjoy. Thanks

Thanks!

Just heard some great news. The Autodesk BXD Synthesis team confirmed the 2018 field will be available in the simulation environment with hours of the announce. Having a field to drive around on like that should be super helpful for strategy among other things.

Thanks for the update .

@Darwin Clark has joined the channel

@Jules Blythe has joined the channel

@Anna Banyas has joined the channel

@Martin Vroom has joined the channel

If anyone’s interested, here’s the scouting data from girls gen. If you want to do anything with it please make a copy of it, as it’s currently sorted by matches.

@Justice James has joined the channel

@Aiden Grayson has joined the channel

I've looked a bit into the potential for the drive team to have up-to-date scouting data going into each match, so they know what to expect from their alliance partners and opposing alliance. It seems feasible by keeping the solution simple. One of the simplest approaches I found works like this:
- Design a Google sheet for scouting data collection and ranking/reporting. A common way seems to be to have a tab for each team, and on each of those team tabs have a standard data collection table with a row for each match the team plays and columns for each scouting data item. And then there are aggregate results tabs as well for evaluating/ranking teams.
- Team members access the Google sheet using tablets or phones (internet connection required for this step), and they enable the Google sheet for offline data collection in case there are no mobile carrier data signals in the arena.
- Six team members at any given time enter scouting data into the shared Google sheet using the team tabs.
- If there is mobile access in the stands, then periodically the data entry devices can connect to an LTE-connected device to sync data. Otherwise, syncs up to the cloud will need to occur periodically between matches by leaving the arena and finding a signal to use.
- In the same spreadsheet, a tab could be designed to enable the drive team to enter their alliance teams' numbers and the opposing alliance teams' numbers, and then summary data about both alliances will populate the tab. And that information could be used as a key input to strategy prior to each match.

Thoughts? It seems like it would be pretty easy to do a proof of concept. I actually built a half prototype of this type of spreadsheet a while back. I could work with Ethan (anyone else interested?) to get to a more robust prototype if there is interest.

One clarification - the connection to an LTE device would need to be either via bluetooth or wire - no WIFI allowed of course.

minor niggle: i believe bluetooth may also be disallowed, but I'm not certain.

It's allowed (802.11 is specifically disallowed, and bluetooth is 802.15 I think), and many teams use it, but one team did report they were asked to turn off their bluetooth connection once. Seems like a low risk - even 4911's & 4663's @ solution uses client + server with sync over bluetooth.

Guess I was remembering last years' R68 which states: "no form of wireless communication shall be used to communicate to, from, or within the robot except R62 and R67"... Since this is about the robot communications, I guess it may not apply for scouting?

Yes that’s right. The other rules say no 802.11 and no making arrangements for the host facility to provide internet. No rule I’ve heard against using mobile network internet + Bluetooth or wired connections to clients.

Last year when we used the app, I would fill out a scouting sheet for the robot that we would be with/against in the next match and I'd then send that to Clio.

Yep @Harper Nalley - same idea. Could use this year’s version of that app as well, and I believe there are still offers from sotabots and also 4911/4663 (they work together). The Google sheets approach would be a way to customize to our preferences, but other options have other advantages.

The thing with google sheets is that they take more time to fill out on a phone. The app we used last year allowed us to export the info directly to slack.

it might also be interesting to build an app that sent data directly to a google sheet rather than exporting csv and pasting in excel later that night

Yeah, that would be nice.

if you can use the google drive as the data store, it should be pretty straightforward to write a script in google sheet to pull in the data

@Jack Stratton — did you mean ‘excel’?? was there a reason we were using both google sheet and excel?

maybe you've been doing something recently I'm not aware of; I just remember doing my scouting analysis stuff in excel from CSVs that the app generated

(or maybe it's just been a while!)

got it! that makes more sense, as I remember you w/ excel :slightlysmilingface:

was wondering what would we use both tools…

Some teams use an inexpensive app builder service called AppSheet that dumps data to a Google sheet (or a few other options), and they seem to love it. It would be a cool project to build our own tool for sure though if there is interest and capacity to do so. Plenty of open source code out there as well from many teams.

Here's a link to AppSheet. With 50% academic discount & given need for offline data entry, the cost to use a public custom scouting app on the platform would be $10/month. https://www.appsheet.com/Pricing

@Ryan Olney has joined the channel

@Micah C. Glasby has joined the channel

@every one https://www.firstinspires.org/resource-library/frc/competition-manual-qa-system encrypted Manuel is out. Get 'em while their hot!

I was wondering if it would make sense for strategy to be a bit more official as a subgroup within the team. I'm not talking about dedicated team members, but instead more a virtual team (or "v-team" as we call them at Microsoft) more organized than just a Slack channel where people from various "normal" teams come together as a multi-disciplinary group addressing a specific purpose. Members would likely include captains, student drive coach, scouting lead, rules masters, coach, and some mentors.

Deliverables could include...
- Common approach/templates for the strategy part of kickoff/build
- Quickstart items for kickoff strategy work as well... Examples: 1) a quickly created 1-pager covering all scoring & penalties provided to all 4 strategy groups ASAP on Saturday. Covering ranking vs. normal points, and also any differences between quals and elimination matches. Maybe to be created by the rules masters? 2) 1-page printouts of the field
- Scouting approach/format - owned by the scouting lead, but with pre-committed input from a reliable group of people

It might even be good to have a Strategy lead role within the leadership team, to be played by a student who has expertise in complex game strategy. I understand there are a number of folks on the team who play complex strategy board games, for example, and I suspect those folks have developed "strategy muscles" the team could figure out how to utilize.

We had a strategy sub team two years ago, which then mostly ran pre-kickoff and some elements of kickoff, but it wasn't something that stuck around for any period of time.

ok, just floating the question because it seems potentially valuable, especially with a larger team from which to draw resources/contributions

@David Ard has joined the channel

Here are links to three Robot-in-3-days teams’ information to get us started + the RI3D YouTube channel. Update: Adding Snow Problem —> https://www.chiefdelphi.com/forums/showthread.php?threadid=160899

Game Manual - Power Up

@Sean Lafer has joined the channel

In case other strategy teams are interested, here's a scoring matrix that incorporates Power Up influence created by Strategy Group 1 https://docs.google.com/spreadsheets/d/1Nk9a6dYox37IhT9chxMqWbSh6vRluk0ZKpKRdp0Bfu8/edit?usp=sharing

This document will do the math for you if you change the values

@Randy Groves has joined the channel

@Austin Smith has joined the channel

@Cory_Houser has joined the channel

Thanks , mentor !!!

Snow Problem's Strategy White Paper - seems pretty well done & worth reading for an outside perspective: https://www.chiefdelphi.com/media/papers/download/5268

I mentioned this a few days ago, and I'll say it again: I think we should have a strategy virtual team this season. The complexity of this year's strategy is an order of magnitude higher that the past couple years IMO. What we're doing now is setting directional strategy in the context of what to design and build, but actual game strategy will need to go deeper. It will need to involve more prep than the past including IMO a strategy playbook for the drive coach and drive team that contains our pre-thought-out point of view of the right approach to various scenarios. Also, between the power-ups and the power struggles over the scale and switches, in-game dynamics are going to be downright crazy and preparation will increase our chances of making good in-game decisions. I'm interested in getting this going if others are recognizing this same need. Thanks.

I concur !!!!!! Captains please initiate group by finding someone to lead from leadership.

Here also is the Green Horns strategy paper (see the Snow Problem one posted earlier). It’s yet another take on things, including some strong numerical analysis of scoring, cycle times, etc Highly recommended. https://www.chiefdelphi.com/media/papers/3423

@Paul Vibrans A few comments on your document:
1. All of the cool new features that Dana and I have been working on recently (path planning and better driving) use math that assumes a differential drive. If you want mecanum, you need to convince everyone that being able to strafe is better than being able to follow complex paths in autonomous. I am not convinced that mecanum is that good/irreplaceable in that regard. Path demo planning: https://drive.google.com/file/d/1ks4lEBWqLuY9-amRF3S3E6jp5aSf5SlM/view?usp=sharing
2. We can't forget about the vault/powerups. There's an entire niche that involves putting stuff in the exchange station for the vault. You can get more points by filling the vault than you can by doing a solo climb.

@Robert Galvin has joined the channel

@Sean Williams has joined the channel

@Nora Wilson has joined the channel

@Josh Goguen has joined the channel

PDF version of Green Horns Strategy paper since some are saying they are having problems getting it from the site.

PSA from Strategy Group 1: The platform zones are only applicable in the last 30 seconds of the game.

Close up actual field pictures from New Hampshire: https://photos.app.goo.gl/Vk7p7MdnBtKiQKkA3. Also, here are line-of-sight views from each driver station position: https://www.chiefdelphi.com/forums/showthread.php?threadid=161068

Here's a video of sight lines as well. We should be able to use Synthesis to explore like this as well, though I haven't tried it yet. https://www.youtube.com/watch?v=e-Yb4tJ7-I&feature=youtu.be

The mecanum wheels are all about putting a cube into the relatively small hole that leads to the vault.

Why not simplify things by having the primary driving axis be at 90 degrees to the cube handling axis?

Fair point, but from driving perspective I would think floor pickup of cubes would be slower if you have to sidle up to them

Idea started over lunch. I think this kind of prep for the drive team could be a huge help to our team and also be a differentiator to help with getting picked for alliances.

why not for building a mechanism that has some degrees of freedom for placing the cube rather than mecanum wheels?
this year we are going to leverage team 254 codebase with support for path following which will be useful for auto. adding mecanum support to the code would require potentially a lot of work and additional risk. I’d need to be sold on ‘why’ of mecanum.

@Grant has joined the channel

@Chris Rininger Great design! Do you have the base (unannounced with auto movements) image? It would be really useful to put into the path planner.

Someone from 1678 shared it on CD: https://www.chiefdelphi.com/forums/showthread.php?threadid=161097

Powerpoint in case you also could use it

agreed — something like this will be key for alliance discussion. we may want to consider lamination to enable captains to draw on them too.

RI3D links! An awesome person with alias “loremtoastem” on CD shared a spreadsheet where all RI3D links are being gathered. Link: https://docs.google.com/spreadsheets/d/1rzdzWBM-vI51AhB-8SdPtsB2Vsru7ogK7zxAIlcHM/edit?usp=sharing ‘Bout time to watch some day 3 and wrap up videos to get ideas.

As soon as I saw SnowProblem’s shooter it made me think... intake + shoot cycles will be a lot faster than grab, elevate, and place cycles. The key to owning the scale is dominate early and maintain. I’m starting to wonder if shooting might not be the sleeper winning solution to loading the scale (& switch for that matter). https://www.chiefdelphi.com/forums/showthread.php?t=160899&page=2 It’s something to at least spend a few minutes considering I think. No precision but the chance to own early.

UPDATE after sleeping on it: I think 3 cubes on the scale during auto is this year's shoot from the hopper or deliver a gear + shoot in auto, and it will be accomplished by short range shooting bots with vision cube pickup that can cycle faster than the pick and placers. In tele, those teams will quickly extend the lead on the scale further. By the time precision matters due to the number of cubes on the scales & the other team potentially takes over the scale, it'll be too late because more than half those points will already have been won.

The ideal energy for throwing a cube can be computed. Will the numbers support the concept?

@Chris Rininger I like that idea! Even being able to do two would put us way ahead in the early competitions, and 3 would be a great growth goal.

FYI . We have a scale completed for tonight .

It's pretty nice

https://twitter.com/twitter/statuses/950543625506775041

stairs are a great protyping tool!

shooting might be achieved with a fancy spring rather than fast-moving wheels. (in this game, shooting rate only needs to match intake rate of 1 cube / secs-per-cube)

Along with Dana’s point, I would think an intake and shooter (perhaps a platform that gets quickly pushed up using potential energy from a spring or elastic) that does not discriminate by cube orientation could be an advantage. Likely more consistent throw as well.

@Chris Rininger pinned a message to this channel.

Rules update 1: https://firstfrc.blob.core.windows.net/frc2018/Manual/TeamUpdates/TeamUpdate01.pdf

Return of the Ramp Bots?

My reading of these changes (esp as pertaining to climbing) is that the strategy of lifting one or two robots without attachment to the bar is still legal. The only rule clarification here is that you can't lift yourself. I recommend strategists check CD. If this is valid ( a-la 2007), it seems hard for me to imagine it wouldn't be among the highest priorities...

for example:
https://www.chiefdelphi.com/forums/showthread.php?t=160980
https://www.chiefdelphi.com/forums/showthread.php?t=161232

Do we have anyone authorized to ask questions on the Q&A area? I think that we should get a reading on the 'with the exception of brief incursions beyond the EXCHANGE or the opening in the PORTAL wall' statement in the S05 safety section, as to whether a robot 'grabber' could cross the plane of the exchange while depositing a cube.

I’ll bring it up at the leadership meeting tomorrow, as we still need to get an account set up potentially, I’m surprised that someone else hasn’t already asked that question.

Not so far - I did a search on 'exchange' and didn't find anything pertinent.

Yes, but it could come up between now and the meeting, or whenever we get the account straightened out.

Why not submit it now? They might answer it by the time we have the meeting.

The account that we used last year doesn't work now, I think we need to create a new one every year, as I just tried the old one

Go ahead

I'd rather do it at the meeting, as last year we used Mr Chee's email for the email, and I would like his permission first for it. And whoever's email we use for the account is need for the verification of the account.

Okay maybe send him an email about it.

As well, if Peter's going to be our rule master he needs the information too, or he should be the one to submit it

I would love to be a rule master but so far I have not received any confirmation that the job was mine or not mine

We'll verify that at the meeting, as you need to get some information. As well, we'd like a second rule master as well.

ok

https://www.youtube.com/watch?v=n3dIPnPQ7gM

https://www.youtube.com/watch?v=1Be3qbEGnFo&t=5s

https://www.youtube.com/watch?v=IQXbA9EmmC4&t=12s

I just read through the latest, and yes it is confirmed a robot on the platform can lift other robots above the bricks to provide valid climbs for those robots.

One thing that is a tad bit troubling to me is... This climb assist thing will almost certainly have to be (or attach) low on the robot. If everything else is designed first and located on the robot not considering it, it seems like it'll be difficult to add. I guess you could have ramps on each side standing up during the match and then they are lowered at end game and then raised again. But it seems like that approach would contribute to high COG problems... Should probably look at 2007 to your point - I believe coach ordered one of those "best of FRC" books from that year that should be arriving in a week or so.

I wish snow problem has shot some cubes with more than a one on the scale to see how they landed... but interesting to see a shooter has actually been pulled off. their intake system could be potentially more efficient though.

We should definitely use green horns to estimate cycle times for the elevator... slower than anticipated.

That shooter looks a lot faster than the other options...

Ri3D's arm is certainly more work than payoff

If they put some wheels on there maybe it'd be better but lining up time... eh

The shooter is actually the fastest from what I can tell visually that's interesting

One other interesting thing from the Q&A: in question 6 it is confirmed the box tubing is part of the rung, meaning robots may hang from it. So that's 2 more inches of grabbable surface on each side.

We should reconsider about shooting .

https://www.youtube.com/watch?v=gPq-NNh0E

and climb !

Here's the reveal https://www.youtube.com/watch?v=n3dIPnPQ7gM

Thanks. I posted in strategy already.

One of the things we talked about in our strategy group was the value of having a tall camera (like 8-9 feet high, raised when the match begins). It's valuable for the driver/operator to see in order to drive & complete tasks, potentially valuable for vision (if stable enough), and this morning I realized if high enough it would allow visibility to the margin of difference between teams on the scale that will not be obvious from the driver station otherwise given the side view. That last one could really help tactically, because it would let the team/alliance know when the margin is positive enough or negative enough that time may be better spent on other tasks like loading the exchange. This next question is more engineering I suppose: Does anyone know the best way to raise a stable camera from below 55" to 100ish" (or however high is needed to across the scale when our alliance doesn't own it)? Telescoping mechanism? Simple bent arm (single joint could get to 100+")?

Remember that a camera like that would have to be wired

Murray State University RI3D: elevator that can climb https://www.youtube.com/watch?v=DzfcYLr3YUA&feature=youtu.be

Seems like a needlessly complicated and inefficient elevator set up. Good example of a u-shaped chassis though, and avoiding the 16” extension limit.

Yes, agree their elevator design is really not good. Decent climb on it partway through video at least

@Randy Groves Here’s a Q/A that I think fits the question that you posed earlier https://frc-qa.firstinspires.org/qa/76

We should watch for WPI's reveal - robot seems similar to direction we may go with open front elevator.

Also, coach brought up shooting again when sharing SnowProblem's videos. My current opinion is that teams will get good at shooting and cycling faster than arms/elevators, so they will be critical for building an early lead. BUT elevators and arms will have to clean up after them by more precisely placing cubes in teh open spaces. I predict some strong alliances will be 1 shooter that can jump on owning the scale early, 1 elevator or arm that can place precisely high or low (these will be the most common type of bot IMO), and 1 bot optimized for picking and placing low to the switch or into the exchange. And ONE of those bots will either climb + help another climb OR park and help TWO robots climb. I think levitate will be a standard to use... climb + helping two robots climb will be rare. So given all that, it really boils down to what role do you want to play?

i agree that climbing helping two robots seems very unlikely. parking + two lifting robots seems compelling but offers engineering challenges. Did any of the 3-day robots address the question of helping another climber? either by space-available or explicit helping?

Team Indiana appeared to be building two side ramps on Day 2. They did their reveal live on FUN I believe, and the replay is not available yet. I pinged them on their Facebook page asking about it in case they're unaware the replayable video isn't out there yet. Also, coach ordered a "best of FRC" book for the year (2007?) that had the rampbots.

Follow-up prediction after that last post: Some elite teams will have the following so they can "do everything":
- Intake that doubles as a shooter so they can own the scale early (i.e. starting in auto) via fast cycles. Can also place low into switch/exchange with it.
- Elevator or arm for more precise placing (yes, in addition to the shooter) on the other end of the robot.
- Two climbing ramps on either side.
- At least a few will also climb with the weight of two additional robots (why not? those NASA engineers need something to figure out, right?)

Kind of a different subject, but in the ball park. What I'd like clarification on is whether the robot itself can break the plane, and if so, what is the definition of incidental?

Rehash from our Tuesday group strategy meeting...
Let’s say we don’t have a shooter AND we find our elevator design is not the worlds fastest. How much time could we get back if we had an elevator design that could rotate at apex to place (eject) cubes 90 degrees to the LEFT or RIGHT? This would eliminate the driver having to turn in to face the switch or scale while delivering a cube, and turn again before driving away after delivery. Just select height, drive by the switch/scale, eject LEFT or eject RIGHT, then drive away. (Yes, this sounds like a complex design but we’re proposing ideas, right?)

And speaking of “select height” would it be worth providing the driver station with discrete heights to select for cube delivery? Once a cube is captured from the floor, the driver begins heading toward the target and selects the height needed for proper cube delivery:
Scale High - stack on top of a cube
Scale High - place in scale
Scale Medium - stack on top of a cube
Scale Medium - place in scale
Scale Low - stack on top of a cube
Scale Low - place in scale
Switch - stack on top of a cube
Switch - place in switch
The elevator is raising to selected delivery height while driver is concentrating on driving to target. One less variable to worry about while driving. And hopefully elevator has already reached correct height when robot arrives at target, saving valuable seconds.

Zou keepers robot in 3 days https://m.youtube.com/watch?v=uFN1ANC9Lh8
Another single point articulated arm with a fold in grabber that uses wheels. Also U-shaped chassis

Week 6 robot in 3 days, https://m.youtube.com/watch?v=4WwsVOGwvZo
Hybrid shooter/Elevator set up

Regarding the rotational delivery system, I like the idea however I think we’d need to test to make sure that it would decrease the cycle time to make a hard argument for it - Id want the driver of robot to confirm they like this idea and that they think it would actually be helpful rather than not used during competition. Though if we think we’d actually use it, definitely!! It’s a really cool idea

That’s good to know even if our question isn’t answered completely

I think that might be something we think about as an addition to the module.

@Harrison has joined the channel

https://m.youtube.com/watch?v=btIH6rYNua0

This is the game that Lucas and I based our design on, it happens near the end of the game though

It starts at 1:38 in the video.

There is a way to make a side ramp carrier do a climb from the rung and all three get up. No need to use the levitate feature so it will give the ranking point if the other two alliance members can do nothing but drive. I can explain on Sunday, Jan 14.

@Paul Vibrans: this idea was discussed. Questions arose from that discussion:

are there balancing issues? Say a tall, heavy robot on one side, and a short light one on the other.
Would it work if you only had one passenger?

Absolutely. The field is designed with a crosshead guide below the rung, we just need the crosshead and a 600 pound rated winch that can climb 18 inches in 5 seconds.

If we design the hook properly, it will center on the rung automatically. Driving to the guide and engaging it will take some practice because the guide only projects from the wall by 2 inches.

The robot would be better designed if it is 33 inches wide and 28 inches long with the ramps on the "front" and " back". Platform geometry limits ramp length to about 36 inches. With the ramps folded out the whole assembly needs to be less than 8 feet 8 inches minus something for alignment error with the rung.

The pantograph or shooter would operate over one side

It seems to me there are a lot options on the table for teleop and end game, and many (perhaps all) of them can work. The team will just need to decide, and I believe the way to do that is by identifying the deeper strategy we want to pursue. To me, that boils down to some questions:
1) What capabilities do we think will differentiate a winning alliance at the district championship and worlds level? Because my understanding is those are both goals of the team. In my opinion the differentiators will be things like a) flexible auto that can mesh well with a variety of partners' auto options, b) drive team preparation (playbook is a must with this game), c) ability to own the scale early and then keep it most/all of the match, d) really fast "low altitude" cycling the whole match on the switch & exchange, e) ability to get 2 + levitate or more ideally 3 robots climbed
2) What robot roles are needed to compose that kind of winning alliance described by the answer to #1? Thoughts on that:
a) a quick-cycling shooter bot that can win the early scale ownership, b) a nearly-as-quick precise placer bot that can take over on the scale after the first several cubes have been shot up there, c) a super fast cycling low placer bot for the switch & exchange, d) one of the bots that can climb + 1 or 2 helped or that can at least reliably help 2 robots climb
3) Finally, what role does Spartronics want to play on winning alliances in Portland and Houston? We can't play them all, so which role DO we want to play?

IMO, to be able to decide on what mechanisms we'll build, we will need to clear this deeper level of strategy. Otherwise, our decisions could be arbitrary without fully thinking of the overall role we intend to play or whether or not that role has a place on a winning Portland/Houston alliance.

Mr. Michaels at school runs a composites class (Lucas took it), including carbon fiber. There might be an opportunity to collaborate on using composites to reduce weight of the ramps.

Mike's thoughts on a strategy and depends on a shooter.
- It limits the number of cubes we can get on the scale: the shooter prototype team tried it and found a practical maximum of about 5 cubes on the scale. After that they kept falling down.

- It's likely be be much faster than any sort of grabber/placer mechanism: videos of other robots with direct placement seem really slow by comparison.

- Its implementation risk is much lower than any sort of grabber/placer mechanism: we've built shooters before, I think we (Coach Chee) was successful in getting Gaea to put up cubes on the scale.

- With regards to both speed and implementation risk, we're dependent on a good intake mechanism, which we don't need if we've got a grabber/placer

@Mike Rosen what was the cycle times for your shooter prototype? (From grabbing a fresh cube, to having it land in the scale)

Good question, @Darwin Clark. I didn't see it. This was based on discussion afterwards, but the prototype was basically a slingshot -- it couldn't have taken more than a second or two ... but again that's all after you get it through the intake and into the shooter.

On average, i think we went somewhere around 10 seconds between shots, but we weren't trying to see how fast we could shoot, we were more focused on trying to see how many cubes we could get into the scale and where they would land

Someone needs to look at the possible trajectories from a low to the ground shooter to see if a robot carrying side ramps can block any or all shots. What about a fast rising elevator or pantograph? There are no rules that I can see against blocking shots as long as they don't involve robot to robot contact.

I think the risk of a foul from contact in the null territory and the probable small percentage of robots that will shoot make shot blocking unlikely to add much value. On the topic of shooter pickup to shot cycle time, I’d get out a stopwatch and look a Snow Problem’s reveal video, then reduce the cycle time by some percentage due to the fact that there is a lot more time to tweak and tune than the RI3D team had.

Rules update #2 that I mentioned last night https://firstfrc.blob.core.windows.net/frc2018/Manual/TeamUpdates/TeamUpdate02.pdf

I remember us wondering about the topic of Q&A #56. Is it ok to push an already-placed cube back on the plate when placing a new cube? Answer is yes; the action is called a "nudge" and is allowed. So if a shooter bot haphazardly places several cubes onto a plate, then a more precise placer bot can place cubes, nudging other cubes, to make things more orderly.

Interesting answer to Q&A #121. Q: If Robot A is hanging from the bar on the scale, with Robot B hanging off of them, thus making Robot B transitively supported by Robot A, does Robot B need to be fully above the platform? Put another way, if Robot B is hanging over carpeted null area, but is still fully supported on the scale transitively by Robot A, will full points be awarded? A: A ROBOT being in the space above their PLATFORM is not one of the criteria required in order for it to qualify for a CLIMB. Per Table 4-1, "For each ROBOT fully supported by the SCALE (either directly or transitively) with BUMPERS fully above the BRICKS at T=0, not in direct contact with their PLATFORM, and not at all in the opponent’s PLATFORM ZONE." I read that to mean a robot can have ramps, platforms, or whatever extending to the carpet behind them off the platform or past the end of the platform on the sides. As long as robots are supported by the platform (directly or transitively) with bumpers 12 or more inches up, climbs count.

Low placer robot reveal - most interesting to us probably is the intake design. Below is just a picture; here is the reveal: https://youtu.be/miFmVdjzCEI

Power Up ultra early competition in Texas: https://m.youtube.com/watch?list=PLTocT0DivsNnrvjnLZ9PZmI9G1DIKqNFx&index=1&v=b84NzkM30GE

Oh my gosh that is interesting!!

Thank you Chris, this really tells us the importance of an effective intake arm huh.

Chief delphi thread that relates to the MCCC

https://www.chiefdelphi.com/forums/showthread.php?threadid=161333

@Mark Tarlton has joined the channel

Also related to MCC, here's a different camera view that follows around a high-placing elevator bot created by the 12th Hour RI3D team. There are actually 4 of these... https://www.youtube.com/watch?v=q-w4Wdi3KIg&list=PLldc3KLAFxrDgwXlZ16lLtk9tI11dx2pE&index=4
What I notice is... It's hard to be a precise placer, even with a high-reaching bot. Cycles on this generation of high placers at least seem quite slow compared with the fast cycles I expect of shooters. (disagree & commit, I know :slightlysmilingface: )

Also, the risk of accidentally pulling down on the scale (& drawing a foul) seems pretty high - will need to be careful.

@brian_bonifaci has joined the channel

I think being able to place into the scale will make us stand out if this is any signal.

@Ronan Bennett has joined the channel

Reinforces the need for slow and smooth lateral and front/back control when trying to place cube.

The 118 Everybot at the MCCC that Chris posted illustrates how quickly an opponent can turn your switch off by shuttling cubes from their portal to your switch. Rapid cycles due to the short distance and minimal cube handling.

Rules update 3 https://firstfrc.blob.core.windows.net/frc2018/Manual/TeamUpdates/TeamUpdate03.pdf

Teleop strategy approach... filing here for further review: https://www.chiefdelphi.com/forums/showthread.php?threadid=161613

https://docs.google.com/document/d/1ekW8h4GHmpmYTviLxXnm6OiVI50Uo4fC33UA3Snkuk/edit?usp=sharing

This is just a general scouting ideas sheet, feel free to add any ideas that may come to you

@Ethan Rininger pinned a message to this channel.

Rules update 4 https://firstfrc.blob.core.windows.net/frc2018/Manual/TeamUpdates/TeamUpdate04.pdf

@Peter Hall Rules question. Our climbing approach includes an intention to stick out arms that touch the sides of the TOWER in order to stay stable as we climb (including climbing with 1 or 2 other robots). I'm going over the rules again again, and I'm a bit concerned about the "Grabbing" and "Grasping" prohibitions that are part of rule G19 below. Would you or the other rules master (is it Cory?) please check the Q&A for a clear answer to this? And if one does not exist, please ask a question. Thanks!

G19. Be careful about what you interact with. DRIVE TEAMS, ROBOTS, and OPERATOR CONSOLES are prohibited from the following actions with regards to interaction with ARCADE elements. Items A and B exclude DRIVE TEAM interaction with FIELD elements in their areas. Item C excludes use of the PLAYER STATION hook-and-loop tape, plugging in to the provided power outlet, and plugging the provided Ethernet cable in to the OPERATOR CONSOLE. Items A-D exclude RUNGS and POWER CUBES. A. Grabbing B. Grasping C. Attaching to (including the use of hook-and-loop tape against the FIELD carpet) D. Hanging E. Deforming F. Becoming entangled G. Damaging

To sum up my question, does having arms extended on both sides of the 2-inch Tower bump out constitute grabbing or grasping the Tower?

We will be rolling on the tower similar to rolling on the floor.

Yep... i would argue we’re “bracing” or “stabilizing” rather than grabbing or grasping, but two arms, even with wheels, that are bracing against the two sides of the tower could be considered grabbing. I think even you used the word “hugging”. We just need to make sure in my opinion, or we’ll be subject to the interpretation of each individual judge we encounter.

@Peter Hall: They’re picky about robot design questions, so we need to keep the question generic. Maybe this: “If a robot has elements that extend outside the robot perimeter to brace against & roll up the 2-inch deep sides of the tower during climbing, would that be a violation of G19’s prohibition of grabbing and grasping?”

I'll look and see if someone has asked that. If not I will.

Rules update #5 https://firstfrc.blob.core.windows.net/frc2018/Manual/TeamUpdates/TeamUpdate05.pdf

I think that if both wheels contact simultaneously, that could be considered grasping. If only one wheel at a time is in contact, then I'd call it rubbing but not grasping. The other aspect that may matter is whether the wheels are free rolling vs powered or locked. It would be hard to "grasp" something using free-rolling wheels.

@Ethan Rininger Saw this thread discussing data items to include on scouting sheets: https://www.chiefdelphi.com/forums/showthread.php?t=161268&highlight=score

Thanks for your input. I'm thinking about this similarly. Thoughts: Tower is 17" wide. Arms (or at least the surfaces of the roller wheels that may touch the tower sides) will need to be a bit wider than that for the driver to be able to get into position against the Tower- maybe 18.5" - but it can't be too wide because that would defeat the point. When climb with friends happens, the bracer arm wheel on the side with the heavier robot will contact the tower and roll up the side. Depending on the geometry, there may also be pressure on the face of the tower (by the robot's bumper or separate wheels). If enough tilt to one side occurs, it is possible both bracer arm wheels will touch... that scenario is what has me a bit concerned.

Here's a doc on scouting that @Jack Stratton created a couple years ago that was intended to be carried into the future: https://www.chiefdelphi.com/forums/showthread.php?t=146466&highlight=spartronics I suspect there are some things worth dusting off in there.

I think this Q/A kind of answers the question, kind of weird how it's referred to incidental force. https://frc-qa.firstinspires.org/qa/157

Actually I’m still a bit concerned because it sounds like it is ok if the bumper or a cube grabber incidentally makes contact. I don’t have a warm fuzzy feeling that our arms exclusively intended to make contact with the tower for the purpose of stabilization will fall into the “incidental” category. I wish the word “passive” had been used. Is everyone else feeling fine that the q&a gives us a green light?

We need to discuss today.

On the other hand, why have the 2-inch bump out if not intended for this. Some side climbing teams seem certain to deliberately lean into the tower

I need to look at the tower more closely with the rungs.

See pictures in the pinned spreadsheet in the climber channel

I think as long as we don't damage the tower while climbing we are good.

Very thorough paper shared on strategy: https://www.chiefdelphi.com/forums/showthread.php?threadid=161913

@Enrique Chee pinned a message to this channel.

@Ted Larson Freeman has joined the channel

@Chris Rininger programming will start setting up some autonomous paths to being with (looking at the 40607 Power Up Strategy document, it is pretty cool!) It would be good to have a list of these paths+strategies performed that we can standardize for both the dashboard selection and also for alliance communication. If strategy team already have a list started, please point us (@Declan Freeman-Gleason) on that direction. Thanks!

@Binnur Alkazily I believe a differentiator can be the ability to have a generous variety of auto routines that could allow, on an alliance with two high-placing robots, two or even three cubes on the scale during auto. That means being able to go along the wall, into the null zone, and then place a cube onto the scale at the far end of the null zone. Remember there is that nearly-inch-high bump on the field to deal with. Glad to hear the team is starting working on paths. It was a strength last year and I feel like it can be again this year.

Chris, I get that. I am just stating the obvious, which is that we need to standardize these paths so when the driver clicks on a dropdown menu (probably better than multiple choice selections), the menu reflects what they discussed w/ their alliance. I like to see these options clearly represent the path robot will follow and do — things like ‘Drop off to the switch direct path’ or ‘Drop off to the switch along the wall, into the null zone, at the far end of the switch’.
If strategy team has compiled these, great programmers will use them. Otherwise, programmers will make them up, as we always do :slightlysmilingface:

Understood :slightlysmilingface:. We talked about our auto opportunity as a team during the drive team meeting a bit as well, including an intention to have in the drive team playbook illustrations of the potential paths of each auto starting position so we can use that to come up with a plan with our alliance partners each match. Lucas N. is the strategy V-team lead, and Ronan is our programmer on the overall drive team (as backup human player). thank you!

@Harper Nalley I hope you have read above !!!

Here is a start to a strategy playbook

https://docs.google.com/document/d/1QjQWmZoFedrrwdV2VOLasFn5WcrA0ESAM8L0n2ju8oE/edit?usp=sharing

Great. Good to see you don't have HW, but you do in my class for Thurs. Done ? @Will Hobbs

@Enrique Chee Not done yet

@Binnur Alkazily Does Declan's new draw-the-path code allow us to easily make paths for if we cannot get access to a specific part of the wall? Or is there something additional beyond drawing the path that is more time interval consuming that we may not have enough time intervals to make.

Not sure I understand your question. The path creation code makes it easy to create many automous path options. We would need to combine these paths with both where our robot is positioned w/ which side of the scale is randomly set as ours when match starts. This combination will likely result in a long drop down list of autonomous selections for the driver to specify. And, I am stating that we need to be clear across the teams what we name those selections and how they map on the actual path.

That answers my question.

Good start :slightlysmilingface: If we are the only robot in the field, this works well. However, as the switch side is randomized, we need to consider how the other alliance robots will move so that we avoid running into each other. This needs to be part of the alliance communication and autonomous strategy selection.

Totally agree. Just a start

It's a cool game with the starting randomizations. I see us having a set of starting positions - maybe up to 4 or 5 of them. And each starting position will have a path for each of the randomized scale + near switch color assignment possibilities. We could even have A and B options for a given starting position, with each having some different paths. The path creation code should enable a rich set of options in the context of what I just described, and it will help the team stand out IMO. Excited to see what we can do!

Would it be possible to make one while cueing if necessary?

check w/ @Declan Freeman-Gleason in theory, yes - but would need to be loaded into the code + robot. would not want to try it on the fly :slightlysmilingface:

I like to see if we can simplify the selection/definition process. I am concerned we could easily go overboard and cause usability issue w/ selecting the right autonomous strategy. It requires some working brains, which I got none right now :slightlysmilingface:

I considered it, but it's extremely high risk. Although the path planning tends to Just Work, I wouldn't gamble a match on it. We should have the time to premake all the paths we need, and to make new ones on the practice field at competition.

What do you mean by “Just Work”?

It tends to do as its told. There is some tuning based on speed that should be done, and other factors that make the optimal path are difficult to judge without testing, but in the end the robot will probably drive where its told the first try.

Oh, I see, so it isn’t really something that should be done while waiting unless something really goes wrong.

You will always have a safe autonomous action to perform (do nothing or just cross the line) assuming problem you are thinking relates to an autonomous path issue. Otherwise you have a bigger problem on your hand. You will not be able to correct a misbehaving preprogrammed path on the fly without testing.

Team update #7, not a lot of important changes https://firstfrc.blob.core.windows.net/frc2018/Manual/TeamUpdates/TeamUpdate07.pdf

I added a section titled "Tele-op Scenarios" to the playbook.

@Harper Nalley pinned a message to this channel.

Thanks @Harper Nalley The pinned strategy paper has some related concepts we could borrow to flesh out that section further

I actually think we could use that paper as a template, making it our own by adjusting it reflect our robot & strategy, and then we could turn parts of it into a playbook

I agree, this could be sort of a brainstorm paper.

https://firstfrc.blob.core.windows.net/frc2018/Manual/TeamUpdates/TeamUpdate09.pdf

team update 9

also very usefull is the combined updates page

https://firstfrc.blob.core.windows.net/frc2018/Manual/TeamUpdates/TeamUpdates-combined.pdf

This might be worth checking out to get an in-game feel for things https://www.chiefdelphi.com/forums/showthread.php?threadid=162402

Whoa that's really cool!! Maybe useful for drive team?

yeh that's what I was thinking. evidently several people can play at a time - need to try it myself to see how it works (I'm sure it isn't perfect as a beta)

True true

@Ethan Rininger As we've discussed , it's time to decide what the scouting solution will be and then develop it and test it (ideally with week 0 matches). @Martin Vroom @Justice James @Ted Larson Freeman Declan told me you're interested in helping figure out a scouting solution - great! thanks! Here are options to take a look at:

1) Old Standby... Paper & manual entry into Excel, possibly with Tableau
2) Six chromebooks / tablets and a Google Sheet set up to work offline. Requires periodic Internet to sync. Ideally, chromebooks/tablets are online all the time via a laptop + Verizon device (connected by wire - wireless turned off) + laptop-to-bluetooth internet sharing configured. Remember Google Sheets does not work well with Kindle Fire tables (which is a bummer since they're cheap).

Beyond that, there's a whole bunch of options that teams and individuals share. Some of them carry a very minimal cost. Here's a Chief Delphi thread that covers many of them: https://www.chiefdelphi.com/forums/showthread.php?t=161131&highlight=scouting

Re: scouting, I really like the cross-team cooperation concept of the Green Alliance one described in post #7. Would someone look into it further?

@Ethan Rininger That Green Alliance option might also work great for that PNW scouting group you've been attending - might be worth mentioning next time you meet with them

I like the idea of using Tableau, but at this stage we should evaluate several options. We need to do some brainstorming on the requirements. I'd like to know more about what was done in previous years--what worked well, what bottlenecks impeded analysis, etc.

@Ted Larson Freeman: Thanks for looking at this. Ethan and I looked at an inexpensive app builder today called AppSheet, and it seems promising in that it is easy to set up & works on phones offline or online, feeding data to Google Sheets (which do connect to Tableau) . Another possibility mentioned is RobotScout, an open source Android app that also works offline. See last post here: https://www.chiefdelphi.com/forums/showthread.php?threadid=161131 Agree we should discuss requirements & past experiences - we’ll be around tomorrow.

Additionally, Appsheet doesn't seem very restrictive as many other UI-based app/website design programs are

Rules master -- question: is it allowed to manipulate a cube that is already placed on switch or scale once placed?

https://frc-qa.firstinspires.org/qa/75
"There are no rules explicitly prohibiting manipulation of POWER CUBES on any PLATE."

it's ok to push/nudge/bump (e.g. push it back to form a second row) a cube while placing a different cube, but my understanding is it's not ok to pick up a cube already on a plate and replace it in a different spot

@Binnur Alkazily @Riyadth Al-Kazily @Ronan Bennett @Jon Coonan @Declan Freeman-Gleason Here's what I think we should have in the drive team playbook for each autonomous starting position

:+1:

https://join.slack.com/t/frcscouts/sharedinvite/enQtMzEyNDAxNzYwMTE0LTI0NzcwMWE3ZWIyZTA0YjZjOWQ3NDZjODJkNzRhMWFhN2I4ZWM2NzI4MWFkZmRlMGYxNzliOWZiMTNhNzYyNTI

Link to collaborative scouting slack channel

@Ethan Rininger pinned a message to this channel.

@Declan Freeman-Gleason for the playbook, it'll be best (from printer ink perspective) to have the paths on the white field background, though I do like having all the pre-placed cubes on the diagram.

online I definitely like the look of the dark background better BTW

Good point! We can also display them on a computer/change the path planner background when printing.

https://firstfrc.blob.core.windows.net/frc2018/Manual/TeamUpdates/TeamUpdate10.pdf

Team Update 10

http://www.teamneutrino.org/resources/frc/strategy/

I found this last night, its out dated, but I think some things can still apply

@Sean Reilly has joined the channel

https://docs.google.com/document/d/1PhHVY-FzKRuLgLiH99ugmqSwJ7veO0FVHsa9JCh6Q/edit?usp=sharing

@Harper Nalley pinned a message to this channel.

This is the scouting/strategy template. This document covers the various robot archetypes, robot data sheets, and the match scenarios.

Thanks @Harper Nalley!

@Chris Rininger Today I added a section to the end of the document that deals with the more nit-picking part of strategy. So, collecting data that will allow us to track teams' specific successes and shortcomings (specific as in which modules are they best with) and then over the course of the competition season we will be able to see how each team progresses and improves.

Week 0 events today! Here’s info on the official one, and there are several others around the world - search Chief Delphi. https://www.chiefdelphi.com/forums/showthread.php?t=162762&highlight=Week+0

Cool thanks Chris!!

Looks like the official event is getting ready for elims matches... perfect time to tune in & see what this game is like.

https://www.twitch.tv/videos/229946677 starting at around 1:30 are some matches already recorded

Whoa that's interesting how many robots were dropping the cubes

looks difficult to place up on the scale - a camera up there is going to be important if was can

Watching one score go up every second while the other score stays at zero makes me nervous for the team with zero!

I was really surprised with the cube drops in auto. It also looks like we are going to have an advantage with how fast the scissor lift is compared to the elevator systems

Oh man if there's an alliance without a scale bot they're kind of screwed if the other alliance has one

Yeah agreed some of the elevators are really slow

I was just watching the match that ended at 1:34:00 and man the blue alliance just took over because the red only had two bots running and neither were doing a good job at switch and had no scale. A balenced team that works is so important.

Interesting how many robots are dropping cubes, that'll be something important to scout since it increases their cycle times so much.

Also have a lead early on is going to be SO important, it's much more difficult to get the lead back once the opposing alliance has it.

Seeing how irregular cube placement is with a elevator system, the difference between a shooter and those elevators is mostly the same. Also, a lot of teams don’t seem to know their rules very well.

Yeah did you just watch the live stream? Red was in blue's scale zone and bumped the blue robot so many times

Yes, and the only power up I saw played was levitate, so the exchange isn’t very useful

Yet

Just like they don't know the rules they don't know how to play the game, we'll see more of that I'm sure. I saw one other match where they used boost really effectively

On the live I just saw the second successful climb with friends

It didn't give that alliance a win but whoa impressive

Maybe not useful now, but likely to become more useful as teams learn to drive, place, pick, etc.

Its more of climbing friends as far as I can tell, the main robot didn’t lift itself, but then again that's what’s levitate is for.

That's true. They didn't play levitate I don't think?

If they had they might have won

I can’t remember, I thought I saw them getting cubes for it

Yeah

One of the games I saw the cube got stuck in their robot and they could do nothing

Yeah

That robot was also super top heavy

It nearly tipped a few times

Yeah

Nobody is putting cubes on the opposing alliances switch

Yeah a lot of top heavy robots in this game for sure. Our scissor lift is definitely an advantage there

No I saw that happening

It doesn't... really help that much?

Ok

I haven’t seen it happen yet

It's useful if you're in the lead and you're trying to make sure that the opposing team doesn't score on their side but otherwise not super useful

I thought there was going to be more of that, since the loading zone for extra cubes is on the opposite side.

Really the trick is getting a lead early on is what I'm seeing

The last match on the official one had that, closed the point gap by a significant amount. If the other team can’t climb, then you disabling their switch might still win you the match

True

It is much more efficient to attempt to secure the scale. The scale is most critical due to the fact that it has a 2 point delta, one from denying the opponent their point, and one from the point that you begin to gain.

I agree the scale is much more important I’m just surprised we didn’t see more people placing on the opposing switch

Scale with the opponent’s switch out is what is needed, but still, a winning alliance only needs a ∆point gain of 1 to get ahead or the same with 0, and the winning team having more points

To start with

Does having a one point lead on the opposing team the entire mach 'cancel out' a climb?

Sort of, you need to be 90 points ahead, so having a +1 for 90 second should, if most other parameters are the same, but it should for most matches.

Did we just see a team drop another team while climbing??

I missed it but saw the robot on it's side

Early game so critical... Each alliance partner knowing exactly what they will do first & where (across all 4 randomization possibilities) is a key to this game.

@Darwin Clark There’s your answer, quarters 4 had +1 for red for most of the game, and that was enough to cancel out a climb by half way through the match

Agreed -- this will be similar to last year's game where the shooter became the tie breaker for the gear robots

At higher levels of competition like Portland elims and Worlds, it will be a game of seconds and getting all default points. All alliances will have 3 climbs per side (levitate included or not) at highest levels, and all will get the switch and scale point pumps started early, and THEN the usage & timing of the Power Ups will really matter.

Robots getting caught on the scale is probably going to be more commanplace than I thought

Agreed with Chris

Those power ups will make all the difference

as we've said, scale will be battleground, but "everybots" that can blitz the opposing team's switch will be a factor as well.

Several of us watched week 0 matches during the meeting today, and here are a bunch of observations we made. These apply across many teams - please read. https://docs.google.com/document/d/1yIOkbnHefPxyMcsqrj-OwRCjAXDC1V4uKAETSeeSI3A/edit?usp=sharing

@Chris Rininger pinned a message to this channel.

Drive Team Playbook - Pre-match Planning: https://docs.google.com/document/d/1VREUxIOMKtLdwU-Mntv1xlWEd-HDDLUNL9qTYtIxw4g/edit?usp=sharing

@Ian Ruiz has joined the channel

https://www.chiefdelphi.com/forums/showthread.php?t=161745&highlight=human+player This is what I'm using to prep for human player (@Ronan Bennett)

Tableau is an interactive data visualization tool that we can use for analyzing scouting data. Students can download it for free. See https://www.tableau.com/about/press-releases/2014/firstr-robotics-students-get-opportunity-use-tableau-software-analyze-data

Tableau has some videos on its YouTube channel that are geared to robotics: https://www.youtube.com/playlist?list=PLqx68DwhYA8QwwHHXF4ee8hJFWRbxO