probability of pneumatics element to the game seems higher from the teaser
@rose_bandrowski has joined the channel
@Ethan Rininger has joined the channel
@Kate Treviño-Yoson has joined the channel
@adrien_chaussabel has joined the channel
both feature cylinders full of high pressure matter that actuate things
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
I took a snippet of just the field for reference, printing, whatever. Here it is.
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
@declan_freemangleason has joined the channel
Great stuff on strategy analysis, as well as scouting and statistics like OPR and their usefulness.
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)
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
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
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 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?
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...
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.
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 🤓
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?
@joncoonan 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 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
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).
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 @chrisrin 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).
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!
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....
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.
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.
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
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
Week 0 matches have already started. Watch the streams and learn what to expect when we're on the field: https://www.thebluealliance.com/gameday#layout=1&view_0=2017week0-0&view_1=2017week0-1
Currently watching - I'm seeing a lot climbing, balls on the ground, and not a lot of accurate shooting
And a lack of accurate autonomous shooting as well - I've seen a lot of teams shoot in autonomous and miss
*Thread Reply:* joncoonan: autonomous shooting is hard to do. Have you noted any key starting positions that we need to be aware off??
*Thread Reply:* They keep changing positions. I think they are using the time to debug and vary positions
Do we want to color code the different sections/catagories or just seperate them off from one another
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 commented on @jack’s file Match Scouting Sheet prototype: Some edits: Lets change the intake speed to be relative to HELIOS What is the difference between "tried" and "incomplete" for climbing? Accuracy should be a percent Needs auto gear checkbox
How are you planning on using the data received? is it going into a spreadsheet? If so, would numerical scales perhaps be better (i.e. instead of intake reliability being a word response, a percent is used instead, or rank their climbing ability out of 5)
@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. @chrisrin
@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!).
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
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
@channel if you are scouting, please make sure you are at the stands scouting!
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.
Scouting things, in no particular order
*Thread Reply:* 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.
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.
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
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 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.
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
*Thread Reply:* @jack 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.
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.)
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:
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?
A few more observations where I think #programming can help:
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?
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.
Add an autonomous strategy to drop a gear at the side station. I think we can do this with our accurate driving ability.
@declan_freemangleason 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.
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
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! https://itunes.apple.com/lv/app/cardinalscout/id1106712826?mt=8
check out this robothttps://www.youtube.com/watch?v=ewTCvLp5EUo&feature=em-subs_digest
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 : nice find! Do you think they are running all 5 off one motor controller? Looks like that might be true.
*Thread Reply:* 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.
*Thread Reply:* I assume they are putting 4 controllers in follower mode, and using one as the master.
*Thread Reply:* I didn't see where their encoder is, but they must have one somewhere.
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.
@rose_bandrowski I think it would be better for a student to ask :-)
I sent them an email 🙂
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
I can't recall having a practice field last year but my memory may be bad
We're going to spend most of our 6 hour unbag working on the robot i'm pretty sure
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 @whobbs1496 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!
@coachchee : 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_freemangleason 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.
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_freemangleason 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 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 and I discussed: Before we have the robot:
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 your record/playback available for doing this move is another one we should plan for — as I recall, you need to have record buttons remapped. unless there is an objection from programming team lets plan for that as well as
FirstWA has just now started posting the videos of the Auburn Mountainview event on YouTube: https://www.youtube.com/playlist?list=PLwES-SbpsnxyFZ0HbHDeZVoCDW0zrnl7l
It looks like they're only posting the Mount Vernon videos from today on that playlist 😢
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
The Mount Vernon rankings are out and I was wondering if that could help us.
@channel 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
Both - more details coming soon in #announcements
If the team needs extra devices, I have a couple of old iPads you could use
Have you though of how to get the data off the devices at the competition? Where there is no network?
Data is compiled afterwards at the hotel - the app stores the data on the device it is installed on and can then easily be exported via .csv files and placed into a spreadsheet via a script. Comments are placed in manually based off of the above sheet
But what about the last few matches on the morning of alliance selection? Do you make your choices before the qualifications are over?
We do that anyway. At the very end I think we'd probably be running more off the comments
Last time it worked well having people individually scout teams on the second day. I reckon we go for that again
We could use this new system for the first day and then narrow down on the second day
Please make sure whoever you assign to scout are staying in the hotel with us. Jack C., Jack S, Timo, Declan, Finn, Lia, (6) These 6 are staying with the team.
The following are staying in the same hotel with their own family. They are Ethan, Brian, Mike Nelson (3) . They can also scout. Please make sure all 9 have devices with the APP. If they get tire maybe they can lend their device to the other teammates (10) who are not staying overnight.
FYI, not the entire team is on this channel. Only 43 out of 65 (mentors and students).
@riyadth any spare iPads would be amazing; I have a feeling some people will forget to install the app / have phone troubles
*Thread Reply:* @jack i am charging the iPads and will install the app this evening. Do you need them before Friday?
*Thread Reply:* @jack 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.
They are James Slattery
James Sovick Andrew Peterson Kaedric Holt Chris Mentzer (staying overnight ) Cruz Strom Lucas Nalley Rose Bandrowski Samantha Rosen Sophie Holzer Sean Hooyer
Just in case you don't know, the app requires IOS 10.2 or later, people with iPhone 4s' or earlier won't be able to download the app.
@jackchapman, @timolahtinen, @liajohansen, @Ethan Rininger, @brianhutchison, @michaelnelson: 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, @jamessovick, @andrewpeterson, @kaedricholt, @Harper Nalley, @sean_hooyer, @Sam 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)
@coachchee 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 . Yes for Friday night.
On the app it counts high boiler balls by 2? Shouldn't it be three??
@jack 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 Niklas Prün Michael Nelson Luke Frank Peter Hall Brian Hutchison
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.
@andrew_peterson 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.
Assignments: @seanhooyer : 492, 753 @michaelnelson : 948, 955 @andrewpeterson : 957, 997 @lucasrininger : 1318, 1425 @Ethan Rininger : 1540, 2046 @jamessovick : 2147, 2148 @bodbaird : 2374, 2471 @rosebandrowski : 2521, 2550 @Clio Batali : 2811, 2907 @jackchapman : 2980, 2990 @joncoonan : 3024, 3219 @declanfreemangleason : 3223, 3238 @whobbs1496 : 3393, 3663 @sholzer : 3674, 3693 @brianhutchison : 3711, 4061 @liajohansen : 4125, 4173 @timolahtinen : 4450, 4488 @alexlf : 4495, 4513 @Charlotte : 4662, 4918 @chrismentzer : 5085, 5198 @Harper Nalley : 5295, 5450 @Sam Rosen : 5468, 5920 @mariesachs : 5937, 5970 @Cruz_Strom : 5975, 6343 @Kenneth Wiersema : 6350, 6445
@michael_nelson has joined the channel
Please make sure you put your name in the comment section for each robot that you scout
@timo_lahtinen You only assigned 50 of the 64 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
@channel 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
@channel I would like to have the document completed by 8pm
2148 and 5937 have declined to go to regionals so we don't need to scout them, however we now need to scout 4131 and 488
Rules update 20 https://firstfrc.blob.core.windows.net/frc2017/Manual/TeamUpdates/TeamUpdate20.pdf Not really worth posting, but just for keeping up.
Scout Assignments: @liajohansen : B1 @Sam Rosen : B2 @jamessovick : B3
@sholzer : 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.
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
@channel if you are attending worlds please read below carefully. In order for us to get a general idea of how our competitors preform, you all now have a scouting assignment to complete before Monday.
Each of you has been assigned teams to watch and take notes on. You should be watching 4 matches per team. (watch their 4 most recent matches) On this document write up your notes on that team's averages during their matches.
I would recommend using the Blue Alliance (https://www.thebluealliance.com/) to find your team, and videos of their matches should be linked. Please make sure your name is in the comments section.
Put a check mark on this post if you have read up to this point.
Assignments: @bodbaird 114, 281, 604, 832 @jackchapman 1319, 1410, 1619 @joncoonan 1778, 1836, 1868, 1912 @lukefrank 2230, 2383, 2444 @whobbs1496 2583, 2587, 2682, 2848 @peterhall 2896, 2903, 2910 @brianhutchison 2996, 3039, 3132 @timolahtinen 3562, 3835, 3931, 4005 @alexlf 4400, 4401, 4403, 4488 @Ethan Rininger 4513, 4613, 4915 @lucasrininger 4941, 4944, 4965, 5002 @CruzStrom 5429, 5431, 5454 @Kenneth Wiersema 5496, 5516, 5588, 5663 @Clio Batali 5705, 5737, 5818, 5887 @sholzer 6023, 6055, 6305 @liajohansen 6366, 6429, 6434 @Charlotte 6517, 6739, 6754 @chrismentzer 2534, 1744 @finnmander 2950, 4635, 5458 @mariesachs 6340, 3309, 6442
If you have any question please ask @timo_lahtinen or @whobbs1496
When we arrive we will also be sending representative to each pit to confirm our data.
https://docs.google.com/document/d/1JUwQUKxYPr5j50ACvnsCQ6AcjXO11uep7qALbt9y_5s. Here's the link to the document
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.
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
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
You only need to send 1 representative if I remember correctly
well they say on there at least one, but three preferably
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
@whobbs1496 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.
I am going to print the scouting data and put it in a binder
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
We will have two people probably timo and one other go around to all of the pits
Time and another person will take about 4 hrs. I suggest more than 2 people.
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 🙂 and condolences for failures by alliance partners 😞. Never give up!!
Match results are here: http://frc-events.firstinspires.org/2017/HOPPER/qualifications
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.
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.
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.
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:
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
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 — 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
got it! that makes more sense, as I remember you w/ excel 🙂
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.
@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...
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
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
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
Snow Problem's Strategy White Paper - seems pretty well done & worth reading for an outside perspective: https://www.chiefdelphi.com/media/papers/download/5268
I mentioned this a few days ago, and I'll say it again: I think we should have a strategy virtual team this season. The complexity of this year's strategy is an order of magnitude higher that the past couple years IMO. What we're doing now is setting directional strategy in the context of what to design and build, but actual game strategy will need to go deeper. It will need to involve more prep than the past including IMO a strategy playbook for the drive coach and drive team that contains our pre-thought-out point of view of the right approach to various scenarios. Also, between the power-ups and the power struggles over the scale and switches, in-game dynamics are going to be downright crazy and preparation will increase our chances of making good in-game decisions. I'm interested in getting this going if others are recognizing this same need. Thanks.
I concur !!!!!! Captains please initiate group by finding someone to lead from leadership.
Here also is the Green Horns strategy paper (see the Snow Problem one posted earlier). It’s yet another take on things, including some strong numerical analysis of scoring, cycle times, etc Highly recommended. https://www.chiefdelphi.com/media/papers/3423
@paul_vibrans A few comments on your document:
@Sean_Williams has joined the channel
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
*Thread Reply:* 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
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.
@chrisrin 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
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/1_rz_dzWBM-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.
*Thread Reply:* https://twitter.com/twitter/statuses/950543625506775041
*Thread Reply:* stairs are a great protyping tool!
*Thread Reply:* 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)
The ideal energy for throwing a cube can be computed. Will the numbers support the concept?
@chrisrin 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 .
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.
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...
*Thread Reply:* 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.
*Thread Reply:* 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.
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
*Thread Reply:* 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 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
*Thread Reply:* 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
*Thread Reply:* 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?
*Thread Reply:* That’s good to know even if our question isn’t answered completely
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?
*Thread Reply:* 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":
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.
*Thread Reply:* 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
*Thread Reply:* I think that might be something we think about as an addition to the module.
@Harrison Gilmore 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.
*Thread Reply:* 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.
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.
Mike's thoughts on a strategy and depends on a shooter.
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
@mrosen 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
Thank you Chris, this really tells us the importance of an effective intake arm huh.
Chief delphi thread that relates to the MCCC
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 🙂 )
*Thread Reply:* Also, the risk of accidentally pulling down on the scale (& drawing a foul) seems pretty high - will need to be careful.
*Thread Reply:* Reinforces the need for slow and smooth lateral and front/back control when trying to place cube.
I think being able to place into the scale will make us stand out if this is any signal.
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
*Thread Reply:* @Ethan Rininger Saw this thread discussing data items to include on scouting sheets: https://www.chiefdelphi.com/forums/showthread.php?t=161268&highlight=score
*Thread Reply:* Here's a doc on scouting that @jack 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.
This is just a general scouting ideas sheet, feel free to add any ideas that may come to you
@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.
*Thread Reply:* 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.
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?
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
@Ted Larson Freeman has joined the channel
@chrisrin 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_freemangleason) on that direction. Thanks!
@binnur 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 🙂
Understood 🙂. 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 !!!
*Thread Reply:* Good start 🙂 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.
Great. Good to see you don't have HW, but you do in my class for Thurs. Done ? @whobbs1496
@binnur 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.
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!
*Thread Reply:* 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 🙂
Would it be possible to make one while cueing if necessary?
check w/ @declan_freemangleason in theory, yes - but would need to be loaded into the code + robot. would not want to try it on the fly 🙂
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.
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.
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.
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
*Thread Reply:* Whoa that's really cool!! Maybe useful for drive team?
*Thread Reply:* 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). @MartinVroom @justicejames @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
*Thread Reply:* 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?
*Thread Reply:* @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
*Thread Reply:* 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?
*Thread Reply:* 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
Link to collaborative scouting slack channel
@declan_freemangleason 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.
I found this last night, its out dated, but I think some things can still apply
This is the scouting/strategy template. This document covers the various robot archetypes, robot data sheets, and the match scenarios.
Thanks @Harper Nalley!
@chrisrin @channel 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
Looks like the official event is getting ready for elims matches... perfect time to tune in & see what this game is like.
*Thread Reply:* Watching one score go up every second while the other score stays at zero makes me nervous for the team with zero!
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
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
*Thread Reply:* Maybe not useful now, but likely to become more useful as teams learn to drive, place, pick, etc.
*Thread Reply:* Agreed -- this will be similar to last year's game where the shooter became the tie breaker for the gear robots
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
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?
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
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
It doesn't... really help that much?
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
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
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
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
Drive Team Playbook - Pre-match Planning: https://docs.google.com/document/d/1VREUxIOMKtLdwU-Mntv1xlWEd-HDDLUNL9qTYtIxw4g/edit?usp=sharing
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=PL_qx68DwhYA_8Q_wwHHXF4ee8hJFWRbxO
@Ethan Rininger and @chrisrin 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!
@channel 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.
*Thread Reply:* 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.
*Thread Reply:* Okay, thank you! I will spend some time intervals thinking about what part of this could be automated.
*Thread Reply:* 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
@channel 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?utm_medium=email&utm_source=transactional&utm_campaign=Share+the+App+Conversions#appName=SpartronicsPowerUpScoutingPublic-553736-560994&page=form&row=&table=AppSheet+Scouting+Test&view=AppSheet+Scouting+Test_Form
Hmm doesn't seem to install on my phone (Android)
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
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
@coachchee 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.
Thanks - ok to share with Mark T as well? He mentioned he had a little Tableau experience.
*Thread Reply:* if we are talking about the tableau code, it is for the robotics team -- so, anyone in the team can use it
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 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
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
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.
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.
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
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 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/12Mdco5faKAfU4IWKfoegiXNLTxJOUhFf_7UbMLA3PpU/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 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.
*Thread Reply:* 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
*Thread Reply:* Okay anything I should do tonight before coming to glacier peak
@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?
All, HERE is the link to use for the scouting app. It seems like the one Sean shared is an old one maybe. https://www.appsheet.com/newshortcut/3b6e7b78-6a89-4043-8971-4d7a2370c44a
@adamrideoutredeker has joined the channel
I've just uploaded some preliminary plots of the Mt. Vernon scouting data, similar to yours, @chrisrin, only with the categories plotted separately: https://docs.google.com/document/d/14zwAW_C0qrUyLq3YW8CtzmFkgQ1ShX6cIuPXmy76u04/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
@joncoonan 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.
*Thread Reply:* "how much defense played" is a bit wonky too. @peter_hall did your app crash at mt. vernon?
*Thread Reply:* 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
*Thread Reply:* When you say 'Ethans Spreadsheet' do you mean (https://spartronics.slack.com/files/U2VBT49AN/F9WEZ94S3/spartonics_scouting_data_-_mt) or the new spreadsheet? (https://docs.google.com/spreadsheets/d/1onkXw3H0cOdIBHrvE1TvCut1VA-GmCwQsbCaLFhlSKs/edit?usp=sharing)
@chrisrin 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.
*Thread Reply:* 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.
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.
@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.
@Darwin Clark That’s great! We’ll synch up tomorrow.
@chrisrin 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.
@channel 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.
@joncoonan 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:
import matplotlib 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 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.
*Thread Reply:* Internal dialogue! Sounds deep :) Happy to see you are enjoying the data explorations!
*Thread Reply:* Isn't that just another way of saying that you're talking to yourself? 😃
@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/A1_House_of_Quality.png/500px-A1_House_of_Quality.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
*Thread Reply:* 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
@jackchapman @ronanbennett @chris_mentzer Would one of you please invite the strategy group to the channel if it hasn't been done already? Thx
@Merrill_Keating has joined the channel
@Jack Scheiderman has joined the channel
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/1R9gRATbALqLMz4mwRNsOCn35hURJ6EGdUf_QsVvkL34/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?
*Thread Reply:* 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.
*Thread Reply:* 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.
*Thread Reply:* 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.
*Thread Reply:* 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.
*Thread Reply:* 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
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.
@john_sachs Could you explain how you reached those numbers at the meeting?
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: https://www.chiefdelphi.com/t/comprehensive-strategy-guide-reflections-from-a-1329-vet-for-deep-space-linked-google-doc/337163/2 https://www.chiefdelphi.com/t/game-strategy/337152
*Thread Reply:* 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.
*Thread Reply:* 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.
@Darwin Clark here's a revised "house of quality" spreadsheet for this year's game.
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:
*Thread Reply:* 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 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.
*Thread Reply:* 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?
*Thread Reply:* 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?
*Thread Reply:* 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.
*Thread Reply:* @Mark Tarlton FWIW, we ran with an unmodified FOV of ~45 deg last year.
*Thread Reply:* 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
*Thread Reply:* 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?
*Thread Reply:* 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).
*Thread Reply:* 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. @chrisrin 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.
*Thread Reply:* 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.
good set of whitepapers from Ri3D Snow Problem https://drive.google.com/drive/folders/1lRS2b08bcc58ljoN1MTSXZuYcg-AuBJX
This hatch panel placer design is pretty simple with just three pneumatic cylinders, but has a lot of leeway in placing distance. https://www.youtube.com/watch?v=ZSrDXWIV6cg
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
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?
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!
*Thread Reply:* 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/1O5Uqb_a_9GQSHt8A86cbIZOJTkmM9oZGTJlwmsi92uI/edit?usp=sharing And the original Chief Delphi post: https://www.chiefdelphi.com/t/do-you-want-to-specialize-poll/336066
Rules Update 02 -Look for these here https://firstfrc.blob.core.windows.net/frc2019/Manual/TeamUpdates/TeamUpdate02.pdf 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=PLkZ6_Ld1x9Y9KHbO_6yFjb5xq11inq0Tw
*Thread Reply:* Observations:
*Thread Reply:* 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...
*Thread Reply:* Sandstorm defense not allowed if I’m remembering correctly
*Thread Reply:* 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.
*Thread Reply:* 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.
https://firstfrc.blob.core.windows.net/frc2019/Manual/TeamUpdates/TeamUpdate03.pdf New rules update... everyone might want to take a look at rule G4.
*Thread Reply:* >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.
*Thread Reply:* 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.
*Thread Reply:* As of Rules Update 4 (https://firstfrc.blob.core.windows.net/frc2019/Manual/TeamUpdates/TeamUpdate04.pdf), this was removed.
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
*Thread Reply:* 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.
*Thread Reply:* 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
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
*Thread Reply:* Is this the right link? I see an empty doc.
*Thread Reply:* FIRST occasionally puts out empty updates.
fyi — field view could be useful https://www.chiefdelphi.com/t/8k-2019-top-down-orthographic-field-views/337019?u=binnur
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