@James Slattery has joined the channel
Go to Worlds
@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
@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
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
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...
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
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
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.
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 !!!
What about the Velcro on the rope?
Is that allowed
See post directed at jack, Q/A number 6
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 !!!
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 :-)
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
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!
Bumper team might want to take a look
Thank you Kenneth
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
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
@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
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
thanks Alex for posting
Week 0 matches have already started. Watch the streams and learn what to expect when we're on the field:
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.
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
@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
@Brian Hutchison has joined the channel
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
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:
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?
@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.
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!
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:
West Valley event match videos have been posted to YouTube: https://www.youtube.com/playlist?list=PLwES-SbpsnxyNM0BptRnmnXJrBc1Hba2w
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
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
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:
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
Is that for Android or iOS? Or both?
I have it on my iphone thus far
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
@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
Chris Mentzer (staying overnight )
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.
@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.
@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.
Speedscout17 just added an update allowing comments on individual matches
If you are staying overnight , you are scouting both days. @Finn Mander
Also @Brian Hutchison will alos be staying overnight so he can also Scout.
Here are some more teammates staying overnight at GP that can help scout. 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.
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
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.
@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.
@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.
Send scouting data to
About 5 minutes into the video.
Listen 1 hr into video about the cheesecake and Vihillabot
Who will signup ? Timo ? Captains please take the lead on this.
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.
@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.
https://docs.google.com/document/d/1JUwQUKxYPr5j50ACvnsCQ6AcjXO11uep7qALbt9y5s. Here's the link to the document
@Will Hobbs I wasn't given an assignment
I will reassign some teams to you tonight
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 ?
One of the teams assigned to me for scouting is going to St. Louis not Houston
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?
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
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
@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.
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.
@Paul Vibrans has joined the channel
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?
51 right now
Match results are here: http://frc-events.firstinspires.org/2017/HOPPER/qualifications
@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.
Here is the current Tableau code for 16-17:
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.
@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.
@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
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.
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...
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
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.
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 .
and climb !
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
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.
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
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.
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
@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.
Teleop strategy approach... filing here for further review: https://www.chiefdelphi.com/forums/showthread.php?threadid=161613
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.
@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.
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.
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
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.
team update 9
also very usefull is the combined updates page
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)
@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?
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
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.
Team Update 10
I found this last night, its out dated, but I think some things can still apply
@Sean Reilly has joined the channel
@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.
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
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
One of the games I saw the cube got stuck in their robot and they could do nothing
That robot was also super top heavy
It nearly tipped a few times
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?
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
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
@Ethan Rininger and @Chris Rininger have already created a mobile app for collecting scouting data. I suggest that anyone interested in scouting and strategy take a look at the Tableau links above. We should meet--perhaps next weekend--and put together a work flow, beginning with gathering scouting data using the mobile app and ending with making and publishing data plots using Tableau. This will be a proof of concept until the first competition, but the tools are flexible enough that we should be able to make adjustments as needed.
Here is one more link from Tableau, their general starting point: https://www.tableau.com/resource/desktop-welcome/data
@Ted Larson Freeman thank you so much for looking into this! That article looks like they’re talking about Skunkworks if I’m right, pretty cool stuff. I’d like to see if we can use this application effectively!
I have added a speculative strategy section to the Strategy Scouting Template (It's pinned to the channel). I hope that over the next week and on Friday at the competition I can work with people to fill this out. Perhaps during meetings and at lunches? I have first lunch on Monday, and second lunch the rest of the week.
Don't forget to setup and video tape matches . I believe @Cruz Strom was heading this .
This is the plan for strategy at our first competition.
The goal for this year's Strategy team at the competitions is to relay strategy suggestions to the drive team as the day progresses (as opposed to at the end of each day). To do this we will be employing a system where we record detailed data about every robot at the competition. We put that information into a data-sorting infrastructure (Linked below) that allows us to turn that raw data into information we can use. Once we figure out the strategies for the up-coming match(s) we will send that to the drive team. The information sent to the drive team is will include the following: Our own priorities and what we should suggest to our alliance members. For example, if the alliance member 'A' is a fast (sorry) robot that can only score in the switch, we might suggest they attempt to keep the opposing team from scoring with their switch. Alliance member 'B' is slower, but can also only score in switches, so we might suggest they focus on our switch and maybe our exchange. Alliance member 'C' (Us) should focus on the scale.
As this is the first occasion we are using this method of doing strategy this will be pared down and streamlined as the season progresses.
Please read above
Lucas, as an option, it's really easy to create phone-based data collection apps using the same AppSheet tool as will be used for scouting in the stands (i.e. Ethan's scouting tool). I think there may be an opportunity to automate/streamline what you have planned using that, and I'd be happy to show you how it works. There's even a way to include robot photo collection within the app for retrieval later. Thanks for all your thoughts and work on strategy - I think it will help.
Okay, thank you! I will spend some time intervals thinking about what part of this could be automated.
I agree with Chris, speaking from experience it's alot easier to organize data in a program rather then working on a complicated physical system. Takes alot of clerical errors out of the equation too. I like that app idea
practice scouting these matches:
Did the link for the scouting app already get posted?
For in browser @Justice James: https://www.appsheet.com/start/3b6e7b78-6a89-4043-8971-4d7a2370c44a?utmmedium=email&utmsource=transactional&utmcampaign=Share+the+App+Conversions#appName=SpartronicsPowerUpScoutingPublic-553736-560994&page=form&row=&table=AppSheet+Scouting+Test&view=AppSheet+Scouting+TestForm
@Ethan Rininger That works, thanks!
Is this an Android or Apple app?
Hmm doesn't seem to install on my phone (Android)
Can’t help you there sorry
This is a "web page app" rather than a real phone app. I copied the URL from the message above to a browser already running on my phone and it worked fine. Once there, you can bookmark it like any other webpage. @Ethan Rininger do you have suggestions on team number etc we should use for testing? Also, for questions about time remaining, do we enter the number of seconds? Is that how it will be displayed at the match?
If you are on IOS or Android I would use the first link and follow the instructions. Just use any team that is in the match if you want to test. The time remaining is the time on the scoreboard when the points start to get scored.
Additionally I have edited the app to factor in some suggestions I received yesterday, so things might be different than they were on the presentation, but should still be pretty obvious what you need to do
@Ethan Rininger pinned a message to this channel.
Thanks for the tip. I clicked on the first link and it installed the Android app. I had to come back to Slack and click on the link a second time to get your tool to open up. It also created a short cut to the scouting app on the phone screen
One key point about the app: To scout offline, you’ll need the actual AppSheet app rather than the web-based approach. If unsure what you have, please ask
@Enrique Chee if you have the new Tableau activation code from the virtual kit of parts, would you please share it with Ted and me (or maybe Ted already got it)? I think students can generally get it for free. Thanks.
Just emailed to you
Thanks - ok to share with Mark T as well? He mentioned he had a little Tableau experience.
One view I would love to figure out how to do is ranking teams by total cubes placed, with horizontal or vertical bars for that composed of segments representing their volume of each type of cube placement. So we could tell a high volume overall placer that focuses on the scale from a high volume “everybot” that focuses on the opponent’s switch.
I can’t get the app to load either.
I tried and it didn’t work, I’m going to try again at Vernon or today at lunch.
Just to make sure folks are using the right link, here's the link to install the app on iOS or Android: https://www.appsheet.com/newshortcut/3b6e7b78-6a89-4043-8971-4d7a2370c44a
If installation is failing, please describe what happens when it fails so it'll be easier to troubleshoot. It is possible there could be compatibility problem with older versions (or maybe really new versions) of Android, for example, and we can check into that.
@Ethan Rininger For some reason the webpage is not working, it may be the school wifi
because it worked on my house's wifi
I've got an Android 6 phone. I see the 'Install' link, and I select it. I see a flash of a progress bar, but other than that, nothing. I've looked on my phone and see no new apps have been installed.
It's strange because the web version was working before. EDIT: Fixed it.
Here’s what I did to get it working on my phone.
First download the app sheet app from the App Store. After that I opened the link and it redirected me to the AppSheet app and downloaded the scouting app. Then just open the app and it should work without an issue
if we are talking about the tableau code, it is for the robotics team -- so, anyone in the team can use it
Who would like to meet with ORF in the pits tomorrow
Sure, would be glad to - I think @Mark Tarlton also is playing with Tableau, and I think @Ted Larson Freeman also. Now that we have data from an event, we can do a lot of experimenting & refining to come up with the valuable views. What I did is actually pretty elementary - I'd like to figure out how to do some cooler multi-color / multi-field views like 3663 does.
I have a rules clarification; In the first finals match we played with Jack In The Bot, a section of their lifter fell off on the ground (Around 1:08 in this VOD https://youtu.be/3xEFUIFz7qc). It can be seen as a small black section of cable, but clearly larger than our googly eye. If what I understand is correct, they should have been disabled correct? The way I understand it is: If a piece falls off your robot, then you are disabled. Am I missing something?
We got disabled at the end of a match because one of our googly eyes fell off, this seems more serious than that
That's my point, I'm wondering if there might be some rules clarification I may have missed that would explain why we got disabled and they did not.
We did not get disabled for loosing a google eye
Did we stop and not climb because we didn't know if an important part came off?
Will, that was word around the stands, thats very interesting that it was not the case. We can resolve this at a meeting.
This was finals? Or semis?
A chain came loose so it was seized up. Easily fixed.
It was not finals, I don't remember the exact match number, but what happened was: we lined up for the climb, and hooked onto the bar, but we failed to climb. AT THE TIME OF HOOKING ON a googly eye fell off, and from the stands it seemed like we were disabled because of it.
Yeah - we saw something pop off, and Themis didn't climb. It took a moment, but we realized it was a googly eye. I figured that the drive team didn't realize it was a googly eye so they didn't want to risk falling.
If Jack in the Bot couldn't have been disabled for their part that came off, its interesting that they didn't decide to stop. It wasn't an insignificant piece, so they either didn't realize they lost it or the didn't care for some reason.
I am pretty sure it was bumpers
Bumpers fell off a couple of times
It was my understanding that ANY part of your robot coming off is grounds for disqualification, due to the bumpers falling off and causing us to be disabled. @David Ard It was my understanding that any part qualifies. Is it only bumpers that cause you to be disqualified?
Bumpers are a big part since they protect the robot but many other things can disable you.
I think so, since we were disabled when our bumpers came off.
The incident for 2910 is at 1:06. A large part of their elevator came off.
Like how team 360 lost a part on the scale
What match did that happen again
The referees would definitely have seen 2910's thing, since the robot was between two referees. It was so obvious we could see it in the stands, so I think it only works for bumpers. I skimmed the rules, and the only disabled rule that didn't relate to fouls seemed to say it only happened if you lost a bumper. Someone should double check as I didn't read it very closely and I could easily have missed something.
The match where we hooked and did not climb was an issue with the chain on the climber motor
We were not disabled in that match
Gotcha, just rumors in the stands then
We got disabled when we lost our bumpers because the robot becomes unsafe when you loose the bumpers
Also the time that the robot fell was not an issue with our climber but was actually because the other team ran into us
Thanks for the clarification - all we could see was that 1) we didn't climb and 2) something (later found to be a googly eye) fell off the climber, and we thought the drive team had the same information we did.
I have a quick question for programmers - could the autonomous program used to get a cube on the scale if our colored scale is on the same side be improved if we program the robot to run along the wall and then turn in to the right position? The program was incredibly helpful in games when it worked, even against faster bots with a similar program, so I just wondered if there was any fine tuning that could be done so it would work more consistently. I thought there could be some way to get work around the small factors, like slight differences in placement, that have kept the path following program from working at its best.
Great week 1 data for refining strategy: https://www.chiefdelphi.com/forums/showthread.php?threadid=163648 This is from First in Michigan btw, which is one of the more highly competitive regions for FRC because (I believe) the state provides a lot of funding to teams + the auto industry & their engineers are there. The stats on win rate vs auto performance & scale ownership ate interesting.
And here’s a preview for PNW week 2 (here comes 4488, etc). https://www.chiefdelphi.com/forums/showthread.php?threadid=163677
There is some good insight in those threads.
I've put together a proof of concept for graphing scouting data, imitating the graphs that team 3663 posted during the Mt. Vernon competition. The graphs are in the file Scouting_Plots in this Google Drive folder: https://drive.google.com/open?id=1KSPPfoxOp8EfvfhzZvRKhPpfeQVZ8buB
The simulated data is in the file Scouting.csv. The scripts I used to generate the data and make the plots are also there. In this case I used R (https://www.r-project.org/) instead of Tableau. I'd be happy to help the team get started using either of these tools for data visualization.
Ted, any thoughts on python w/ jupyter notebook (instead of R?) this feels complementary to programming skills we have in the team as well
I really like this view... https://docs.google.com/document/d/12fUpBmJTZX49m835Hk0a-N9UtqoLFCMqEKhCfsQt78o/edit I'd like to figure out how to also create it using Tableau. Ted, here's a link to the real world data from Mt. Vernon. Is there anything we need to change about the structure of data in you opinion? Mark T. mentioned it would be helpful to establish default values for non-required fields rather than allowing nulls, for example. The link: https://docs.google.com/spreadsheets/d/12Mdco5faKAfU4IWKfoegiXNLTxJOUhFf7UbMLA3PpU/edit?usp=sharing
Related, here’s a good discussion about pulling blue alliance data into Google sheets: https://www.chiefdelphi.com/forums/showthread.php?threadid=163773
Binnur, I would be happy to work with Jupyter as well. I'm a long time IPython user, but I always head straight back to R when I want to plot data. I think R has some great advantages--publication quality graphics, well designed analysis packages, etc. It depends a lot on what the students want to do. My guess is that Tableau would be best in terms of being able to modify plots on the fly without having to write any scripts.
Chris, I'll see what I can do with the Mt. Vernon data. My initial hunch is that we can work with it in the current format. And yes, I'm sure we can do everything in Tableau.
BTW, coach asked about teaching the students Tableau, and I think a good approach will be to create useful views and then walk through the data and view configurations, maybe recreate a view or two so the students can observe the workflow, then have the students create their own.
Has anyone had a chance to install Tableau? @Binnur Alkazily has also suggested that we could use Python in Jupyter notebooks. For those who are interested in trying that option, please download Anaconda from https://www.anaconda.com (choose the version for Python 3.6). During the Glacier Peak competition, I will work with the scouting and strategy teams to plot scouting data using Tableau, Python in Jupyter, or R. We can use any or all of these, but the installation files are large enough that we'll have to download them before the competition. Here is the link again for Tableau: https://www.tableau.com/academic/students. R can be installed through Anaconda (launch Anaconda Navigator and click the link to install RStudio), or as a separate installation from CRAN. I suggest the Anaconda option because then you can run R in a Jupyter notebook.
I'll try to test it out with our spreadsheet.
FYI Tableau can connect directly to the Google Sheet where the scouting data from the app lands, as Justice just implied
@Ethan Rininger Could I get acsess to the google sheet were the app spits all the data out?
Jack, please don’t change the spreadsheet- most changes will require parallel changes to the app, which I’m trying to avoid
I already archived the my Vernon data
@Jack Chapman Are you assigning scouters
or have scouters sign up for time slots
Okay anything I should do tonight before coming to glacier peak
I cant think of anything
@Ethan Rininger do you have the scouter sign up sheet you used last time that you could share?
@Jack Chapman I was having trouble sleeping, so I went ahead and updated the app so counts default to zero, and I also updated the spreadsheet sheet names so they make sense relative to the data they contain. We'll need everyone to update the app before scouting, which means they'll need to open it while having a cell phone internet connection. Luckily, our pit location has cell phone data connection unlike the majority of the school. How about we have our scout meeting in or maybe behind our pit so people will have data connections & can update the app (or load it for those who don't have it yet)? 10 or 10:30am sound right?
@Violet Advani has joined the channel
@Tanner Nalley has joined the channel
All, HERE is the link to use for the scouting app. It seems like the one Sean shared is an old one maybe.
@Adam Rideout Redeker has joined the channel
I've just uploaded some preliminary plots of the Mt. Vernon scouting data, similar to yours, @Chris Rininger, only with the categories plotted separately: https://docs.google.com/document/d/14zwAWC0qrUyLq3YW8CtzmFkgQ1ShX6cIuPXmy76u04/edit?usp=sharing
These were done in R, and all the files necessary to recreate them are in the same directory: https://drive.google.com/drive/folders/1wFGU2iAnpT0tjC2O0brcoG-RqRk7DxrX?usp=sharing
@Jon Coonan Question about data processing, with the graphs already created, how much have you been using the graphs? i want to know what you have liked so far about them, in addition to what improvements you would like to see.
I used the one chris created when I was on the field and it was extremely useful. For Portland if we compiled all our current data and had similar printouts I could use that while strategizing in queue
What I think would be a game changer is... for each match, come up with a data sheet profiling our alliance vs. the opponent
Using data we've obtained to date + data shared via that scouting network Ethan was part of
That would be very, very cool. Would the idea be to give Jon the graphs during queue(Either via technology, or a printout) to inform tactical decisions about the match?
As soon as we know the schedule in Portland, could create a sheet for each match, and Jon would just have it for his drive team binder
@Ethan Rininger I've notices a few discrepancies in the scouting data. In some of the columns (How much defense played, Accurate cube placer, and Driver skill) there is some 'True' or 'False' fields in cells where it does not look like there should be. Is this by design? Or is this an error?
For reference, I'm looking at the mount vernon scouting data, and that particular entry is on row 43 with similar entrys on rows 79, and 243.
"how much defense played" is a bit wonky too. @Peter Hall did your app crash at mt. vernon?
more likely, that data was added from the spreadsheet, because the app shouldn't be able to do that
What I think happened is that is an old data format due to the person scouting not having the most recent version of the app
They would have to launch the app while they are connected to the internet and it will automatically update, they probably just didn't do that
As Ethan mentioned in the past, he (& later I) collaborated with several other teams on scouting, and we now have a healthy set of data (not perfect mind you). Here's a link to scouting data from the collaboration that we can make use of in Portland: https://docs.google.com/spreadsheets/d/1onkXw3H0cOdIBHrvE1TvCut1VA-GmCwQsbCaLFhlSKs/edit?usp=sharing
@Darwin Clark Here is a Jupyter IPython notebook with bar plots of our Glacier Peak scouting data (download the file and open it from the command line with "jupyter notebook Scouting_GP.ipynb"): https://drive.google.com/open?id=17fkz-bPvXQeujfKdhSJOcgFa9IIVHKrr
The data file is just the "Glacier Peak Data" tab from Ethan's spreadsheet, saved as a CSV file: https://drive.google.com/open?id=1p8qrpgNuhWclayCqwRDhlZEuzR8dbgq2
@Chris Rininger and @Ethan Rininger I'll take a look at the combined scouting data. There's a lot to explore! We should be able to extract useful profiles for the district competition.
Here's a different version of the shared data in which I added a strategy worksheet for each of the 12 matches. Once the schedule is released, we can update the team numbers on each match sheet to see a readout on each match using the scouting data. https://docs.google.com/spreadsheets/d/1-xlG6KUfmX0aNQhc5ElIVSqKUxTnwCTO4kbICh-8S2k/edit?usp=sharing Thanks to Ethan for getting involved with scouting collaboration group - without data from several competitions we did not attend, this kind of thing would not be possible.
Great to see there is interest in taking the data analysis further! If interested in the more granular match data (which is in like 4 different formats from different scouting systems), let me know. What I provided is really a roll-up of the most common data teams collected.
@Ted Larson Freeman I haven't been keeping in contact with you (Should be!) but I have been working through this. Currently I am using the Mt. Vernon .csv file that you shared with me a few weeks back. I'm very very close to receving my goal( < 3 hours). My current goal is to create a bar chart comparing team and total cubes on the scale from that event. Mostly that is a superficial goal, with the overall objective being to learn more and develop infastructure for a python data analysis system. Once I get something worthwhile produced, I will check it into a github repo (Which I will link), and show here.
For the future I would LOVE to have a discussion about where effot needs to be. Right now I am becomeing farmilar with a Python interface, but I am super excited to take this into something that can be deployed and used.
When you say 'Ethans Spreadsheet' do you mean (https://spartronics.slack.com/files/Ethan Rininger/F9WEZ94S3/spartonicsscoutingdata-mt) or the new spreadsheet? (https://docs.google.com/spreadsheets/d/1onkXw3H0cOdIBHrvE1TvCut1VA-GmCwQsbCaLFhlSKs/edit?usp=sharing)
@Darwin Clark That’s great! We’ll synch up tomorrow.
@Chris Rininger It’s great to have so much data! Thanks.
I have changed the Spartronics Power Up Strategy Template (again). Jon told me that the only information he needs before a match is whether or not a robot can go for the scale and whether or not they can climb and so the template reflects this. I have also added something I would like to test at portland, it is a series of questions about what a robot did. The questions are based on those that strategists for football teams ask. I am moving away from the alpha-numeric system that I had in place before because it was too complicated and created too much data for a strategy team with two people to deal with.
if anybody is planning on watching the competition on twitch, I could use some help testing this system out. Basically I'll send you what robots to watch in certain matches and then you would fill out "Strategy Test for Portland" and slack that to me. The twitch stream isn't great when it comes to watching a specific robot, but this is just an early test of this idea.
Looking scouting data (https://docs.google.com/spreadsheets/d/1-xlG6KUfmX0aNQhc5ElIVSqKUxTnwCTO4kbICh-8S2k/edit?usp=sharing) for teams with/against us in match 1, I think it may be an opportunity to play the following strategy to pull an upset: Don't go for the scale at all. Send two robots to steal the opponent's switch and leave 1 to defend our alliance's switch & load the exchange. Move a robot to our switch depending on the ownership situation. Make sure we use Power Ups to the fullest. And make sure we get a climb. Even if we lose, this approach could maximize our "cubes in match" productivity.
@Jon Coonan please read above from Chris on
Our 1st match
@Jon Coonan Some graphs for our remaining matches.
This is all data from the combines scouting sheet that Ethan shared.
@Darwin Clark Great plots! Here is one way to increase the plot size in matplotlib. Try different values of width and height:
width = 12
height = 9
matplotlib.rcParams['figure.figsize'] = [width, height]
@Ted Larson Freeman Those are with increased size, I belive those are 18.5 by 10.5
@Darwin Clark you can experiment with two y-scales to give better balance to lower vs higher counts (like moving total cubes to 2nd y coordinate) Also, think about color codes to quickly highlight offense vs defense or key strategic capabilities — whatever is important to differentiate quickly can be a different color. Btw, nice graphs!
@Binnur Alkazily Yeah, I had an internal dialogue about some of those smaller things, like color. I played around with some options, and what I settled on was one of the canned options, which is just a color spectrum (There is around 30 different spectrums to chose from). I didn't have time to look into coloring the individual columns, but that's definitely an important property that we can exploit.
Internal dialogue! Sounds deep :) Happy to see you are enjoying the data explorations!
Isn't that just another way of saying that you're talking to yourself? :smiley:
@Kate Swietlik has joined the channel
@Lane Johnson has joined the channel
@Doña Keating has joined the channel
@Jeffrey Tappen has joined the channel
@Mark Tarlton Hey Mark, building on what you told me about House Of Quality (Quality Function Deployment). I went home and did some research and put together this simple example matrix for FRC. Is this the general idea? I built this primarily off of the sample image from wiki (https://upload.wikimedia.org/wikipedia/commons/thumb/3/3e/A1HouseofQuality.png/500px-A1HouseofQuality.png). My main concern was the y-axis of the matrix; For our application I don't understand what that axis would represent. In the sample image, it represents 'customer requests'. Perhaps game tasks (What is currently in the sample matrix) , or something more along the lines of modules?All feedback appreciated! (https://docs.google.com/spreadsheets/d/1OEAU0Ito0lU9RhqLc2JOD3h-CMJN3JrPc5nMyMEbJA/edit?usp=sharing)
@Darwin Clark @Mark Tarlton Interesting stuff. I found this paper with a House of Quality analysis of user requirements and design parameters of an underwater robot: http://rdo.psu.ac.th/sjstweb/journal/37-6/37-6-8.pdf . I think this approach could be useful, but I'm not sure how long it would take to figure out. Maybe a couple people could give this a try on day 2 - I have thoughts about how to fit our ways to score, team goals, and functional requirements into the format, but it will take time.
Here's another reference that's more specifically oriented towards engineering. This looks to be from a textbook. Take a look starting at page 59 of the textbook.
we're going to try to put together a draft spreadsheet for a generic FIRST robot using last year's game as a guide where necessary.
Hey Strategy amigos! I just saw an announcement that at 9pm on Twitch the night of kickoff there will be a Robot-in-3-days strategy round-table discussion with teams FRC1678, FRC125, FRC1241, FRC4481, FRC225 & FRC2590. This will be a very valuable way to spend an hour, because we'll be able to gather a bunch of strategy insights from those teams that we did not think of ourselves to incorporate into our strategy work on Day 2. I'm definitely planning to watch and take notes. If anyone else wants to join in, here's a link: https://www.chiefdelphi.com/t/first-plays-ri3d-on-fun/335556
Also, here is the Robot-in-3-Days channel on Chief Delphi: https://www.chiefdelphi.com/c/other/robot-in-3-days-ri3d
I may also try to tune in on this... Others should too!
Related: Here's an RI3D spreadsheet someone created last year that I took a shot at updating for this year. There are a couple new RI3D groups, and at least some of the main ones from the past will go again. Links: https://docs.google.com/spreadsheets/d/1Yubvuo6aWE8AHZ0so7Tl3DviPnLrRayZYgGGljWgL78/edit?usp=sharing
@Jack Chapman @Ronan Bennett @Chris Mentzer Would one of you please invite the strategy group to the channel if it hasn't been done already? Thx
@Max Hays has joined the channel
@Merrill Keating has joined the channel
@Jack Scheiderman has joined the channel
@Noah Solomon has joined the channel
Here's a sample HoQ document for last year's game. There are notes at the bottom and comments with some of the cells. It uses the Excel "Solver" to do some of the optimizations. I'll try to provide more info later.
this spreadsheet shows separation of objectives (the lines) which would be produced by strategy team, and the engineering characteristics by the engineering team. The "Options" represent specific design concepts and how well they address the individual engineering objectives. "Complexity" represents the effort required to achieve the objective.
@Camden Greenhalgh has joined the channel
@Camden Greenhalgh has left the channel
Spreadsheet we're working on in the strategy group: https://docs.google.com/spreadsheets/d/1R9gRATbALqLMz4mwRNsOCn35hURJ6EGdUfQsVvkL34/edit?usp=sharing
This is for both Robot Interactions 1 and 2
Spreadsheet found on Cheif Delphi on Penalties: https://docs.google.com/spreadsheets/d/1kR77IIB48UsqlpX9N1ChHf2RgeYm546aJzaEapsoauw/edit#gid=0 Original post: https://www.chiefdelphi.com/t/all-the-fouls-in-one-spreadsheet/336379
I've been thinking about that Ginger Powers strategy doc from last year. Link: https://www.chiefdelphi.com/t/paper-4607-power-up-strategy/162600 One thing in there I think we really should do is identify eliminations alliance compositions/strategies for district champs, and then figure out how we might fit into that picture.
Here are three types of alliances I think we could see at Tacoma (what do you think?):
1) Robot 1: first rocket; Robot 2: second rocket; Robot 3: cargo ship. That approach optimizes traffic and decently distributes scoring tasks. The first two robots are "do everything" bots, but the third could be a low task specialist.
2) Robot 1: first rocket then work on the other if time; Robots 2 and 3: cargo ship then work on the 2nd rocket if time. All three robots are "do everything" bots, but the third alliance partner is not that strong at high tasks.
3) Robot 1: rockets; Robot 2: cargo ship; Robot 3: defensive disrupter. I'm not sure about this one being real, honestly, but it could be IF a) there is a killer 2910-in-2018 type robot and b) there is a robot that has proven itself to be very valuable at defense during quals and that could thus shut down the great opposing robot
What other district champs elims alliance compositions do you all think will exist?
Interestingly, you have classified your example archetypes by what game objective they pine for. I would argue, due to the intense difference between the disk game element and the cargo element, most robots will be categorized by what elements they can manipulate. Looking back on 2017 (The game that shares similar properties in regard to field elements), the robots competing in semis often had one robot that was classified as a 'Everything' bot. For example, I think this distribution is more likely: 1) Robot 1: High Hatch Robot 2: High Cargo Robot 3: Fast Cargo.
Thanks! I knew I was probably not fully thinking it through... Now that I think about it more, since there are no RPs in elims, it'll be all about fastest possible cycles, which means low (faster/easier) then high. Quals, on the other hand, will involve alliances with at least a couple strong teams trying for the rocket RP. I'll think about it some more.
Put this together to show the importance of Ranking Points, especially bonus Ranking Points (from Rocket and/or Climb). You can win all 12 matches and get 24 RPs; you can also lose all 12 matches and still get 24 RPs if you can get both Rocket and Climb RPs (something you can mostly control). Green shaded area shows the RPs of the top 10 teams from each of our competitions last year; we want to be in this box.
Added the Excel file for those that can read it.
Taking Darwin's thinking in a slightly different direction, I believe the High bots will be able to do both Panels and Cargo, so Robot 1: High Rocket, Robot 2: Low Panels (fast), Robot 3: Everything bot.
@John Sachs Could you explain how you reached those numbers at the meeting?
Yep, good one. Since there are so many game pieces, and enough low placement locations to occupy two robots, I agree there will be a place for a single really fast low bot on DCMPs elims alliances... similar robots to 2017 gear runners. However, for versatility, alliance captain would likely pick a fast low bot that can do hatch panels and cargo low.
Here are a couple good strategy reads to see what others are thinking. I recommend the top one (there were like 30 people reading it last I checked), because the person seems very experienced as is looking at cycle times similar to us:
In that first paper, the best insights (I think) are later... In particular, the author's thinking about cycle times (he projects ~15 seconds), the viability of just going for low targets, and the potential high value of defense is worth reviewing. Also, the final comments about simple robots that will get picked for elims have good insights.
@Darwin Clark here's a revised "house of quality" spreadsheet for this year's game.
I don't totally "get it" yet... One challenge, I think, is assuming we can normalize Robot Qualities with things like Score Enablers & Events.... I'd almost say take those off & do a separate qualitative assessment against those.
What is also missing is experiential context. After staring at this game nearly every waking moment the past day, I think the best scale bot teams from last year will dominate the medium and high rocket tasks, because they can just reuse their drive trains and lifts (2910 will be a monster again). And teams from 2017 that were fast gear running bots will reuse their drive train designs from that to be fast low hatch panel placers. The end game climbing task seems like an opportunity, If we could incorporate a ramp or something that makes it 95+% likely an alliance partner can get up to L3 on the hab, then if we are also a pretty good panel/cargo bot I think we could go far. I am not convinced we will need to do the medium and high rocket tasks... with the number of game pieces on the field, they're just not that valuable. I think the rocket RP will be something of a red herring other than the highest levels of competition.
Good discussion about defense: https://www.chiefdelphi.com/t/how-do-you-win-with-defense/337423 Also, survey of teams about whether they’ll stay low or also go mid-level or high: https://www.chiefdelphi.com/t/tall-robot-or-short-robot/337815
thread on vision / auto navigation / auto targeting:
the navigation lines range in length from 20-25 inches. That's not very long, especially if our robot is > 30". When it comes to accurate auto navigation/docking: that's not a lot of length to correct for orientation and position errors, especially if our sensors point directly downward. Probably means that the standard vision targets would be needed uses for distances > 25. @Riyadth Al-Kazily pointed this out yesterday. An interesting exercise: combine last years' vision with a go-to-goal action that attempts to align itself with only 25" run-up. (from a dead-still start). The success of this endeavor (or lack thereof) would determine the priority of additional sensors for the navigation lines.
What's the field-of-view angle for our cameras? I assume we'd like to have the camera higher up and angled down slightly -- meaning we should take camera mounts into account in our design. Any suggestions on what that geometry should be?
Also, are multiple cameras practical? for example, one that's angled down looking for floor markers and another looking straight ahead for vertical vision targets?
multiple cameras are feasible - we've had up to three. There's probably not enough bandwidth for the driver to see all three simultaneously. Field of view is also negotiable: there are attachable fish-eye lenses for example. As the camera projection (fov) increases, the projection becomes increasingly spherical and so lines become more curved.
@Mark Tarlton FWIW, we ran with an unmodified FOV of ~45 deg last year.
good set of whitepapers from Ri3D Snow Problem
From talking with drivers, back of robot high would be a good “drive around” view because robot is in foreground so it is like a 3rd person video game view... could help mitigate latency perception
With a reasonably wide angle like maybe 75 a 120 range. Good thing to test with drivers. Would a solution with a camera 4’ up on a piece of that polycarbonate square tube work as a rigid mount?
Greenhorns ri3d strategy paper: https://www.chiefdelphi.com/t/ri3d-greenhorns-2019-strategy-white-paper/337787 whole thread is interesting
Simplified maps of the field to use for strategy & other things... these always come in handy https://www.chiefdelphi.com/t/2019-strategy-map/339067
Following-up on a discussion with @Mark Tarlton and Paul. Of note: there are only vision targets on the lowest level of the rocket (But on every cargo ship hatch). I think this opens up more possibilities for the vision platform. I would argue that on the rocket, the Gaffers tape leading up to each side is more important to track that the retreo-reflective tape, because it's relevant (for alignment purposes) in 100% of the rocket cycles, while the vision targets are only relevant 33% of the time. However, this flips if the robot is focused on the cargo ship (where there are vision targets on every receptacle).
I think the vision targets may be used as navigation targets since they are visible from longer distances than the floor tape and their locations on the structures are well defined. Assume the vision camera is attached to the robot and not to the manipulator. If you are navigating to the top port of the rocket, knowing exactly where the robot is relative to the low target is probably enough to place cargo or hatches. I think the vision targets alone are sufficient to accurately locate the robot. @Chris Rininger There is a trade-off between field of view and working distance. The wider the field of view the shorter the effective working distance between robot and target. There's another trade-off between camera resolution and precision. Narrow field-of-view plus high resolution gives highest precision.
Exactly, and I think using the low vision targets to align the robot is another tool to solve the same problem. The main point I'm raising is: There's a possibility vision is used to detect the Gaffers tape on the ground, and not the vision target, and that distinction should fit into whatever robot is going to drop out of pipe in a few days.
Hello from the east coast, I'm still lurking and learning around on this slack but regarding defensive play, our team 4361, is assuming there will be defense. Especially at a district playoff level, since the first 3 teams to pick will probably have 2 good all around bots and then can use anyone with a good drive train on their 2nd selection to disrupt more points than any scoring bot left to be chosen
I feel like there are still some strategy things we could do to help inform the decision tomorrow. We started but didn’t finish the brainstorming of district champs elims alliance composition, for example. There is also the more granular robot archetype list & projected achievement for each. Finally, for each of the three options, we could make some assumptions to come up with cycle time ranges specific and then do some more analysis using that. What do you all think would be most valuable?
Cross posting here...
Snow Problem’s strategy paper (3 pages) is required reading in my opinion - find it in the CD post just shared - scroll down a bit. Once we pick a robot archetype, we should something like it. The way they created strategy gameplay narratives for their robot is super insightful. To make it easy, here is Snow Problem's folder with their white papers, including strategy: https://drive.google.com/drive/folders/1lRS2b08bcc58ljoN1MTSXZuYcg-AuBJX Read it folks!
I completely agree. Their climber mechanism is something we should consider using - they said it took just six seconds.
Somebody did a more robust survey than the high / low one, and I copied the data and put it in a quick pivot table. Sample size is 54, so not huge, but still this is interesting and useful. Here's the sheet: https://docs.google.com/spreadsheets/d/1O5Uqba9GQSHt8A86cbIZOJTkmM9oZGTJlwmsi92uI/edit?usp=sharing And the original Chief Delphi post: https://www.chiefdelphi.com/t/do-you-want-to-specialize-poll/336066
Here's a screen snippet for easier viewing. Clarification: Numbers represent how many teams out of 54 surveyed are going with that strategy.
Rules Update 02 -Look for these here
Notable things-5.1.1 now has 24 of each game piece are staged at either end of the field
Panels can now be shot 3 ft
Changed wording for playoff penalty cards
Matches to watch & learn from! The Week -6 event in Houston was yesterday, and they’ve posted the 11 matches played. Anyone strategizing, designing, or prototyping should watch some of these to gain insights. https://www.youtube.com/playlist?list=PLkZ6Ld1x9Y9KHbO6yFjb5xq11inq0Tw
1. Don't expect a high level of play at all. Instead, watch how the ball bounces, how spacing/traffic look generally, etc.
2. Defense will be very common - maybe nearly every match. It's much easier to disrupt a robot placing a game piece than to place a game piece. Any robot that can move with a decent driver can be a high-value alliance partner with the lack of protection zones.
3. The Everybot had a surprisingly hard time placing hatch panels because they had to line the panel up flush to get it to stick (I saw some drops - they did better in match 4). From the testing I saw in the robotics room yesterday, I still believe flicking panels from 6 to 24 inches will be much faster than docking/releasing/backing up. It is both a faster action and more forgiving (i.e. it works from a wider variety of angles, so should result in fewer drops, which I realize seems counterintuitive). I agree with avoiding pneumatics if possible, but we should test flicking vs. docking because the time saved from flicking might be worth a compressor + 1 tank + a couple pistons + some tubing to the panel flicker.
4. Good view of Everybot driving off L2 at beginning of match four; seemed to have little trouble
5. Balls roll and bounce quite a bit, but carpet dampens things a touch... balls end up in a slow, roaming roll before coming to rest
6. Intake will need to get the ball off the ground quickly & before moving to avoid losing it - balls have high friction against the carpet. See 1:25 in match 9.
7. Clearly need to confirm plan with alliance partners for Sandstorm. A couple times drivers (driving with cameras?) collided going for the same target to drop off a panel
8. Slowest steps of cycles (as one might predict) seem to be lining up to acquire a game piece, acquiring game piece successfully, lining up to place a game piece, and placing the game piece successfully. Robots were at different sprint speeds in the open field, but those things I just mentioned made or broke cycle times.
@Chris Rininger Thanks for sharing !!!
Is a robot allowed to play defense during the sandstorm period? I note that it is very challenging to place hatch panels (or cargo) during the sandstorm, and is probably easier to cross the field and be a pest to the other alliance, if such behavior is allowed. I couldn't find that detail with a quick skim of the rules...
Sandstorm defense not allowed if I’m remembering correctly
Cool! It handled the drive away from HAB level 2 easily. The little wheels up front took some of the shock. I liked the little pneumatic 'kicker' for ejecting Cargo. The wheeled ejection mechanism could place at the rocket's mid-level but it looked like the robot had to be in exactly the right position to be successful. The hatch panel grabber was secure but it held the hatch a little too low for accurate placement.
Watching the videos, I'm not seeing a clear advantage for "intake on one side and place on the other to reduce cycle time". Unlike PowerUp where the cubes and switch/scale were 180 deg opposite, in Deep Space you have to turn to line up with any of the stations relative to where you acquire a game piece. I can see robots picking up cargo in all areas and angles relative to stations. Seems like advantage really will go to those with quick, agile drive trains, fast orientation to stations, and touch it/own it mechanisms.
New rules update... everyone might want to take a look at rule G4.
>G4. One GAME PIECE at a time. ROBOTS may not have extended or repeated control, i.e. exercise extended or repeated influence, of more than one (1) GAME PIECE at a time, either directly or transitively through other objects.
>Violation: FOUL per additional GAME PIECE. If greater than two (2) at a time or second GAME PIECE leaves ROBOT, YELLOW CARD. If ROBOT releases all GAME PIECES, YELLOW CARD.
>If a GAME PIECE becomes lodged in or on a ROBOT, it is considered controlled by the ROBOT. It is important to design your ROBOT so that it is impossible to inadvertently or unintentionally control more than the allowed maximum.
>For example, if a ROBOT controls three (3) GAME PIECES and then releases them all, the team is issued two (2) FOULS (per part 1 of the violation), a YELLOW CARD for controlling more than two (2) GAME PIECES (per part 2 of the violation), and a second YELLOW CARD for releasing them all during the MATCH (per part 3 of the violation), thus earning a RED CARD.
It looks like if a robot ever controls three game pieces, it'll either be a red card, or a yellow card but they have to hold onto a piece for the rest of the match.
Interesting discussion about hatch panel placement. It makes me think we should prioritize speed over high precision when placing that game piece. https://www.chiefdelphi.com/t/legal-vs-illegal-hatch-placement/341462
Interesting thread. Regarding speed & precision, I think speed is important, but getting the panel to stick in place is critical. If it doesn't stay, it doesn't score. My guess is that the penalty for dropping a panel will be essentially 1 full cycle. So, what do we mean by "precision" ? It isn't a measurement of "distance from absolute center" but rather the probability of successfully staying attached, holding the cargo, and thereby scoring points. I think that a 95% success rate is a reasonable number -- only 1 in 20 placements fails. Obviously, the distance from center and the success probability are correlated. We should be able to estimate what the position error bounds will be. Those bounds may be different for the rocket and the cargo ship since the cargo ship has devices installed to block severely off-center hatches. Additionally, when we look at robot position relative to the 'target' position, we should consider positional errors (side-to-side offsets) and also rotational errors. There's been talk of just driving the robot hard into the wall and expecting it to automatically square itself up, but we need to test that assumption.
For our strategy, we need to understand the trade-off between speed and confidence of successful placement. This will depend on driver skills and the various driver assist functions.
I agree. I was trying to say it seems like the successful placement zone of panels may be fairly large (several inches larger “target” than might be perceived at first glance in the manual), and it might open up an opportunity for a somewhat less precise and faster placement solution.
The Behind the Glass with the Everybot video we watched at the beginning of today's meeting https://www.youtube.com/watch?v=YeIbv-qbIHw&feature=youtu.be
As of Rules Update 4 (https://firstfrc.blob.core.windows.net/frc2019/Manual/TeamUpdates/TeamUpdate04.pdf), this was removed.
Thread with links to more strategy maps: https://www.chiefdelphi.com/t/strategy-map-for-2019-deep-space/341758
Very interesting post from a mature team that is perennially focused on robots designed to optimize cycle times. Must read! https://www.chiefdelphi.com/t/cycling-optimization/342304
Is this the right link? I see an empty doc.
FIRST occasionally puts out empty updates.
fyi — field view could be useful
Also Rules Update #6 https://firstfrc.blob.core.windows.net/frc2019/Manual/TeamUpdates/TeamUpdate06.pdf
Good scouting discussion: https://www.chiefdelphi.com/t/what-data-will-your-scouting-collect/340292. More to good scouting than just raw production metrics
@Ted Larson Freeman ^^^
Is there a "strategy lead" among the students or maybe a few students interested in working on strategy? The time seems right to start connecting dots on our team's strategy for competitions, including scouting, alliance/match narratives like Binnur & I have suggested, drive coach/team materials like pre-match planning sheets to use within alliances, and plenty of other possibilities. I know a lot of people are already 100% busy with CADing/building the robot, but maybe there are others who are not who could start working on some of this. Thanks.
@Chris Rininger I can do it, I learned a lot from last year and I have a better understanding of what needs to be done.
@Harper Nalley Thanks! Binnur and I have both recommended our team create our own version of this strategy document created by the Snow Problem RI3D team. Maybe we could start with that? https://drive.google.com/drive/folders/1lRS2b08bcc58ljoN1MTSXZuYcg-AuBJX
@Alexander Perkins will be working with Ted on scouting, by the way
Yes, let’s discuss this tonight. Alex is going to do the data analysis, but we also need someone to update the mobile scouting app. We should have a group decide what we will collect in the app.
Deepest of Deep Space Resources: rules tests, maps, etc. https://www.chiefdelphi.com/t/the-deepest-of-space-resources-all-the-deep-space-resources/337490
Video from alumni competition for 2019 — watching through the snippets, I observed couple of things 1) the field will be busy and challenging to navigate between the robots and the field elements —> the pre-coordination w/ the alliance partners will be crucial; 2) getting off the L2 platform and getting on the L1 platform is challenging —> the sooner we can test our drivetrain (w/ some added weights, though I recall we always had challenges on that...) on the platform w/ the correct surface material the better I will feel :)
I spent some time reading the Q&A - a few gleanings: https://docs.google.com/document/d/11E1wZwaWs4LRRdki6iCPcRqSr1ZzDOIHNuv7108xXgo/edit?usp=sharing
Here’s a FUN episode tonight on preparing for competition: https://www.chiefdelphi.com/t/competition-preparation-live-8-30pm-et-w-1114-3132-2468-503-125-giveaway/346004 @Harper Nalley @Alexander Perkins @Kenneth Wiersema @Ted Larson Freeman @Chris Mentzer @Cruz Strom
For anyone interested in the week 0 competition: https://spartronics.slack.com/archives/C2CPRJ87M/p1550093007000100
Pretty good pre-match strategy board https://www.chiefdelphi.com/t/2019-strategy-board/346635
Good insights into what strong teams who expect to lead alliances are looking for when scouting teams for alliance picks. https://www.chiefdelphi.com/t/what-are-you-scouting-for/347768
If distributing cargo from the loading station to other members on the field is valuable, then our drivers may want to experiment to see if our chute is capable of 'chuting' cargo to targets in a controllable way.
Long thread on defense... worth reading for drive team and strategy people. https://www.chiefdelphi.com/t/deep-space-is-going-to-be-ruined-by-defence/347551 Speaking of strategy, where is our work in progress @Harper Nalley? A couple of us suggested doing work similar to Snow Problem RI3D - was that ever started? Thx
Just read the rest of the thread. It sounds like a lot of people expect alliances to play 2 on offense & 1 on defense. Playing 3 on offense while the opponent sends a defender will result in congestion from 4 robots on a half field, while the 2 undefended robots on the other side will be more efficient with less congestion. I think our robot being low & heavy (& geared fairly low) with traction wheels will make our robot desirable for defense. @Ted Larson Freeman Our scouting data analysis will ideally normalize offensive by the amount of time a robot plays offense vs defense during a match, so it will be good to maybe have a slider that goes from 100% offense & no D to no offense & 100% D.
I was planning on starting strategy work after watching the Mount Vernon competition. I think that would be the most effective use of my time since I don’t want to go off on a wrong path and waste hours.
So I just realized that Skunkworks is going to be at both Mount Vernon AND Auburn Mountainview. We are going to want to watch what they do especially closely.
While I think it is true that week 1 will be quite informative when it comes to strategy, I also think there is work that could be done now. Robot in 3D teams did fairly elaborate strategy work ups and there are lots of threads on Chief Delphi. I recommend at least coming up with what your document or presentation or spreadsheet or whatever will look like and how it will interface with scouting and the drive team.
Okay, I will try to start working on that at lunch tomorrow.
Honestly, doing something VERY similar to what Snow Problem, specifically anticipating alliance compositions (e.g. us + 2 high bots, us + 1 high bot & another low bot, etc.), and how we think about strategy in the context of those alliance compositions would be super useful. You'll find a link in earlier posts to the channel.
Okay, thank you!
No problem - thanks for working on it!
@Harper Nalley just pointing again to that well-thought-out Snow Problem strategy doc. Just creating “our version” of this would add value to drive team and probably scouting as well.
I looked through it and I agree
Strong argument for alliances to use all 6 null hatch panels in early season /quail matches, and given the state of our ability to handle panels, this probably doubly applies to us unless we see a dramatic improvement before our first competition. https://www.chiefdelphi.com/t/please-use-null-hatch-panels/348612
Never Mind, the red alliance was given the ranking point for the penalty rather than filling the rocket up
Based on reveal videos, there are many teams going for hab 3 climb & a fair number managing to be successful at it. Need to be fast & reliable to stand out, especially with no hab 2 climb currently.
@Ted Larson Freeman @Justice James @Ethan Rininger @Alexander Perkins Regarding the scouting app, I do some lurking and occasionally make a suggestion on the Green Alliance, which is a pretty large group of teams who collaborate on a scouting app. (We might have joined them if there was confidence about multi-platform phone compatibiltiy as good as AppSheet has.) For reference, here are the scouting data items they're collecting:
Thanks for the list, that looks pretty comprehensive. Here's what we have currently.
Your name (FirstName LastName)
Starts on Level 2?
Crossed HAB line?
Starts with hatch panel?
# of hatch panels placed during autonomous
# of cargo placed during autonomous
# of hatch panels on the cargo bay
# of hatch panels on the bottom of the rocket
# of hatch panels on the middle of the rocket
# of hatch panels on the top of the rocket
# of hatch panels missed
# of cargo in the cargo bay
# of cargo in the bottom of the rocket
# of cargo in the middle of the rocket
# of cargo in the top of the rocket
# of cargo missed
Climbing (Level 1, 2, 3, 2 with friends, 3 with friends, didn't climb)
Played defense successfully
Weak to defense (tippy, easily pushed, etc)
# of fouls
# of tech fouls
We mostly scout the same things.
The Green Alliance has all of below:
"eventkey": - Event location
"matchtype": - I don't know what this is
"matchtypenumber": - I don't know what this is
"scoutteam": - We're all on the same team.
"autobottomrocketpanels": - We count the total number of panels scored in autonomous
"autobottomrocketcargo": - We count the total number of cargo scored in autonomous
"commentsnotpresent": - This might be a good one to check, but most teams who are no shows don't have very good RP averages
"commentstop_heavy": - Weak to defense.
We check if teams drop cargo and hatch panels, as well as how their defense is.
@Justice James feedback on scouting app (others feel free to pile on & create a thread)
- First off, overall it looks really good. We're well positioned to scout this year! Thanks to you and everyone who worked on it.
- Since competition is not being collected in the interface, will you tag rows in the scouting results spreadsheet with a competition ID after the fact?
- From a data visualization perspective, it might be better to ask: Starting Position? with Level 1 and Level 2 as the response options.
- Similarly, it might be good to ask: Starting Game Piece? with hatch panel and cargo as the response options (think of a pie chart - better to chart those two things rather than yes/no)
- One thing that would be good to scout is who is good at placing game pieces at obstructed-view targets (e.g. the hidden back hatches on the rockets). Part of this is... who has a good driver camera set up and knows how to use it? Maybe this is more something to ask scouters to watch for and mention in the comments if they spot a driver really good at this. Or maybe it is part of pit scouting, if the team decides to go for that.
- I'd like to propose an additional defense metric: % of tele-op time playing defense. Adding this will allow normalized tele-op offensive metrics to be calculated. For example, if a robot scores 2 cargo ship hatch panels & 1 cargo ship cargo, AND they play defense for 1/2 of tele-op, then their normalized tele-op offense metrics would be 4 cargo ship hatch panels and 2 cargo ship cargo. I suggest this also because I believe defense will be played a lot this season, and having this data could end up being quite useful if we're leading or 1st pick in an alliance, and we're looking for the best defensive robot still available for our 3rd robot.
- That's all my feedback. Great work so far!
@Chris Rininger thanks for the feedback!
- I'm using separate sheets on the scouting spreadsheet for different competitions (one for Auburn, one for Glacier, etc). Similarly, pit scouting has its own sheet.
- Alright, I've changed that to three options. It should update for everybody.
- We're definitely doing pit scouting, maybe Friday and absolutely Saturday. I'd like to ask about cameras there, just because it'll be hard to tell from the stands.
- I originally wanted to avoid metrics because of how inaccurate they can be, but that seems pretty easy to judge. I'll add it next to the successful defense question.
@Justice James @Ted Larson Freeman @Alexander Perkins @Ethan Rininger I'm not sure if any of you are aware of this. The Blue Alliance makes all its event, match, team, etc. data available via a set of APIs (link: https://www.thebluealliance.com/apidocs) that could be mashed up with our scouting data potentially. Also, here is a link to a Google Sheets add-on that accesses the API: https://www.chiefdelphi.com/t/tba-requests-google-sheets-add-on-for-blue-alliance-data/166636
@Justice James I just invited you to the Peninsula Alliance Slack because there is interest in the teams sharing scouting data (we did this with some teams last year, and it was valuable). Would you please coordinate with Lauren and Naomi from 3223? Thanks. Should be as simple as sharing Google Sheet data with read-only access. One thing: before sharing, please review free form comments and scrub any non-GP comments. And when training team, let them know to keep comments GP. Thanks!
@Chris Rininger I've created a pit scouting forum, accessible from the top left hamburger menu. Do you have any feedback on it? I wanted to leave it pretty open-ended, since it's not being used for data analysis. Images are the only thing not yet working (in the spreadsheet at least)
I’ll look at pit scouting app, though pit scouting is not something I have researched much. Different topic: I was reading this thread: https://www.chiefdelphi.com/t/2019-defensive-rating-systems/349065/4. It makes me think instead of (or in addition to) “played defense successfully” we should have a count of “defensive impacts” or something like that, probably on the Tele-op tab rather than end game. It gives the Tele-op scouter something to count if the bot they’re scouting is playing defense.
Regarding pit scouting, I like it but that number of pictures may be too much for some teams. I recommend creating a script to make sure newer team members are GP. “Do you mind if I take a few pictures of your robot?” Even better would be to say, “Hey, I saw your team win that match against...” And then ask about taking pictures. If the answer is “just a quick one” or “sorry, too busy”, then respect that. The questions, on the other hand, seem good and should be answerable by someone not working on the robot. I would add the question: “What is your team’s approach to driving practice?”
Here is a first take on plotting yesterday's scouting data. I've used a rough scoring function (e.g. counting hatch panels and cargo in the middle or top of the rocket slightly higher). That exact function should be decided by the team, so don't treat this ranking as definitive.
is climbing reflected in this? can it be?
Yes, we just need to decide how to score it.
ah - slippery
Here's a second attempt to plot the scouting data, adding a climbing score at Dana's suggestion (in magenta). The climbing score is 12, 6, 3, or 0 points. It changes things quite a bit, demonstrating the importance of the choice of scoring function.
@Ted Larson Freeman Very interesting and useful for the next competition! Will it be possible to quickly generate this for the Saturday night scouting conversation at Glacier Peak? This past weekend, we looked at raw tabular data and a bit of pivot table-generated aggregate data, but this latest chart incorporating the scoring value of climbing with other forms of scoring seems better. I think the pick list could be generated using just this view, in fact, possibly supplemented by views of robots who are strong hatch panel placers and L2 climbers (assuming we'll be focusing on cargo and L3 climbs).
Yes, the goal is to have several people on the team who can make these plots at the end of each day (and even during each day). It’s a simple task to adjust the scoring function to whatever the team decides to use. There will be some trial and error, as there is no one right answer.
Just took a look at the scores at PNW District Championships; seeing a Rocket bonus ranking point every third match - wow!
Teams have improved !!!
Would it be possible to get some similar visual analysis of the scouting data from our second event?
It’s been checked in to the git repository. I can post the plots here as well.
My auto-generated Google Sheets graphs and Ted's R graphs are on the first sheet.
There is an issue with those plots, which is corrected in the latest files checked in to git (plotscores2019.R and GlacierPeak2019.ipynb). To illustrate with an example, consider a team that fails to climb in one match (0 points) and climbs to the third level (12 points) in the second. The average climbing score for these two matches should be 6 points. But if we have two scouts recording data for the first match and only one for the second, and we simply average all observations, we'll take the average of (0, 0, 12) and get 4 points. To correct this, we have to first group the data by match and team, and then by team--see the function getsummarydata in the files mentioned above. Here is plot that corrects this issue.
Here is the same data plotted vertically. The correction mentioned above does have an impact. Team 1983 has moved from 5th to 3rd place with this correction, for example.
LATEST UPDATE: Karthik did a 24-minute version, and if you want to shorten even further skip to Strategic Design starting at 8:40. So there you go - down to 15 minutes if you skip that first part. If you like it, maybe invest time into the long one below.
Karthik Kanagasabapathy presented an updated version of his Strategy presentation in Detroit. It's long - nearly 2 hours - but it is well-produced & full of updated insights (including strategy thoughts about no bag day at around 1:14:05) from one of FRC's thought leaders. The first 15:20 can probably be skipped. Also, starring 1:20:30 he presents a full 1/2 hour on scouting. Here's an UPDATED link that is higher quality than the original one: https://www.twitch.tv/videos/416680583
@Chris Rininger Thanks for sharing !
@Paul Vibrans has left the channel
Who will facilitate and record results of the strategy assessment on kickoff day this year? Last year I think Ronan led. Since the approach has several steps and there are several deliverables (tabs in the spreadsheet), it’ll be good to go over it with a few students prior to kickoff.
@Steve Erickson has joined the channel
@Max Morse has joined the channel
@Ian Cosman has joined the channel
@Freeman Tuohy has joined the channel
@Henry First has joined the channel
@David Scheiderman has joined the channel