Modification of Record model to support pre-scouting.

[rye]

Currently there's not really a model for pre-scouting. I'd like to suggest that we change the Record model to support pre-scouting.

I think that all that needs to get done is we should not require match_number or match_id to be present and instead enable the use of a recordType dynamic attribute that would always get set. If recordType were present and equal to match, we would throw an error unless match_number were present. If it were equal to prescout, we would ignore that and just create the record without a match_id.

Alternatively, we could create a new model for storage of prescouting data, or associate it with teams. If we associate it with teams, however, we'll need to overwrite existing pre-scouting data as new information is obtained, which would prevent having multiple records of pre-scouting data for redundancy and comparison.

Also, we need to add support for images. We can upload images and store them on the server, but we need to implement that.

[claire271]

I like the first option. Last year, we stored the prescout record ID as part of the filename, so that we could associate each of the images to a team through the DB. That's just a suggestion for what we could do this year.

[rye]

We could just store the filename of the image file in the database as well (i.e have it download the images and then modify that field in the database to where the image is located).

[claire271]

That should work.

[Sammidysam]

So you mean something like have an enum called kind within the Record? An enum sounds more efficient than a String in this case.

We could use this library. https://github.com/thetron/mongoid-enum

[Sammidysam]

A problem with using a Record for pre-scouting, though, is that

• a position is required for a Record.
• because no match will be present, we will not be able to associate the Record with the competition.

At this point, it seems cleaner to make a pre-scouting model. We don't need Records to be heavily dynamic.

However, I don't really know what pre-scouting is about. Is it before the match, or just basic information about the robot? I assumed it was basic information about the robot, and thus I would prefer a separate model that belongs to a team and a competition. It is good to associate it with a competition because a team could possibly be using a different robot at a different competition, or it may get tweaked. There may be rules against that, but I don't know FRC at all.

[rye]

I don't want to use another library for such things as providing Enums; string comparison is enough of a brainless task that loading and requiring another library is able to be considered as a pointless waste of time.

We can easily remedy the problems with position requirements and competition requirements by implicitly writing out error throws under certain scenarios (e.g. if "kind" == "match" throw errors if "match_number" and "position" aren't present, else if "kind" == "prescout" throw errors if "competition_name" isn't present. Then, we can have both competition_id and match_id as fields, and just set one of them to nil if applicable. We could set competition_id to track Match.find(match_id)'s competition_id field (or to be static if match_id is nil), and make the competition_id field always present. Since we have dynamic attributes, a different set of attributes can be sent by prescouting pages than by match scouting pages.

Pre-scouting takes place whenever. It's gathering specific, technical information about the robot like drive train type, strategy, etc. It's almost impossible to do that from the stands, so most will walk around and interview others.

[claire271]

Do we have to associate the teams with the competitions in the records table. Can't we have a separate table?

[rye]

That's what we mean by having a separate model. I'm up for that.

[cg505]

I think using a separate model would be cleaner.

[rye]

That seems to be becoming the consensus.

[Sammidysam]

@tigerh: We used to have a Participations table that was used to associate a team with a competition (it only held a competition_id and team_id), but then we realized that all teams will play at least one match in any competition that they are in (that better be true), so we can deduce what competitions a team has been in and what teams are in a competition through what matches are in the competition and what matches a team has played. Once we realized this, we removed the Participations table, as it was not needed. If it would help in any way to bring it back, we could, but we do not feel like it would be useful.

What are we planning on naming the prescouting model? I assume it would contain the following as general attributes that will always be present:

field :notes, type: String

belongs_to :competition
belongs_to :team

validates :competition_id, :team_id, presence: true

[claire271]

I wanted that table because it would allow us to have a list of teams for a competition before scouting, which would make selecting the teams easier.

[Sammidysam]

In the case of team numbers, it's probably easier to write it out. Especially with something like 40--50 teams in a competition. That is a bit much for a select list. If not, we can get it down to six by using the defaults. We could have somebody managing the server set a teams variable in the defaults to a list of the teams that will be participating in the next match before each match. It would look like "teams": [461, 868, 1024, 2048, 3096, 4012]. Then the client could load that to populate the list. Alternatively, we could look into the server controller setting the next match before it occurs, which would put into defaults the teams and match number. Both would then be automatically loaded into the scouting form.

[claire271]

It worked well with all the teams in a select.

[vmai]

Having a good way to filter out the teams for each competition in data visualization would be very helpful. Sure, we don't need to view all 40-50 teams in a select menu on the scouting form, but being able to view them all at once on the data visualization filter them by competition will be very nice, assuming we stick with the current design for that page.

[Sammidysam]

@tigerh: How many teams?

@fishyfish235: Yep, that is present. As long as a team has played at least one match in a competition, /competitions/:id/teams (where :id is the id of the competition) will include it in the returned array. This works well, as you would not want to compare teams that have not yet played a match.

[claire271]

All the teams at the competition. Also the 100 at Newton.

[vmai]

In our datavis, we also could've chosen to not filter out competitions. So we very well could've had about 200 teams in a single select menu.

[rye]

As long as the select menu were to support for keyboard entry I can't see having >20 teams menu being a problem.

[claire271]

It also helped with reducing errors in selecting the team. Especially with prescouting with the touchscreen tablet.

[vmai]

Yep, select menus do support keyboard entry so it wasn't really a problem.

[rye]

I'd also suggest some kind of auto-completing text box that would embolden which part either hard- or fuzzy-matches the current entry. For example, if you have a bunch of teams but only one with 4 in its number, you could type "4" and it would bring it up. Of course, if we're dealing with 4-digit numbers that's not really a problem, but we could also incorporate searching by name or location.

[Sammidysam]

So do the solutions I proposed suffice, or would it really help to bring back the participations table? I really like the defaults solution for making the scouting team select easy.

[claire271]

I think having at team list for the competition would really help with prescouting. I'm curious, how much does the participations table complicate things?

[Sammidysam]

(Adding to last comment) The server (implementation) could automatically change the next match once the size of /matches/:id/records is greater than or equal to six if we implement match schedule handling.

[claire271]

Can we have both?

[rye]

I don't like autoincrementing like that because if one of the scouts becomes disconnected, the others may get messed up.

[claire271]

How about keeping track of the match number on the client side, or have a separate counter on the server for each client?

[rye]

I think that having hardware to do that (a LCD with buttons below it) would be more appropriate, especially for the BeagleBone hardware since we're switching to it.

Having counters client-side sounds like a good idea. I think we should add match-schedule uploading and then the client can store which position it's in and track that number in the match-schedule.

[Sammidysam]

Yeah, I thought of that problem. It's safer to have someone managing it if we go that route. If we handle match schedules, then we could just have one person hit a "Next Match" button or something.

[claire271]

We should definitely have match schedule uploading.

[Sammidysam]

To which server? I assume implementation.

[Sammidysam]

Sorry for avoiding the question about difficulty of the participation table. I wanted to see what the pre-scouting page looked like to see why it mattered, and it took a bit to get back to my computer.

Adding the participation table would not increase the complexity; it would rather reduce it. I could also add a post request to a path such as /competitions/:id/add_teams that accepts a JSON array of team numbers that would then create a participation for each team and that competition. Considering that there is a need of having the list of teams in a competition before all of the teams have played in a match, it would be fine to add it back. We can also do both have someone set the current match and have a participations table.

We still need a verdict about the pre-scouting model name and if the fields and relations I put were okay.

[cg505]

There is actually a lot of stuff from prescouting that should stay the same from year to year, such as drivetrain type. Do we want to hard code that stuff or leave it up to the implementation?

[Sammidysam]

Doesn't the robot being used change from year to year?

[claire271]

I'd leave it up to the implementation.

[vmai]

I agree. Some teams care about different things than we do.

[Sammidysam]

Could I bring attention back to these comments that relate more to this issue?

[cg505]

I was responding to those comments, suggesting that we add fields for these things that will stay the same year-to-year. However, it looks like we don't want that, so :+1: on the proposed model.

[Sammidysam]

I'd still like to know what name it should have and a final yes on adding participations from @tigerh.

On Jul 22, 2014, at 11:45 AM, cg505 notifications@github.com wrote:

I was responding to those comments, suggesting that we add fields for these things that will stay the same year-to-year. However, it looks like we don't want that, so on the proposed model.

— Reply to this email directly or view it on GitHub.

[Sammidysam]

I also think adding fields for those would be great. I thought you meant keeping their values the same. Could you give me a list of fields?

On Jul 22, 2014, at 11:45 AM, cg505 notifications@github.com wrote:

I was responding to those comments, suggesting that we add fields for these things that will stay the same year-to-year. However, it looks like we don't want that, so on the proposed model.

— Reply to this email directly or view it on GitHub.

[claire271]

I support adding the participations table back in.

[Sammidysam]

Then I will add that eventually. Not sure when. How urgent is it in relation to the progress of the implementation?

I am still awaiting a name for the pre-scout model and a list of fields of pre-scouting that will be present every year no matter what the game is.

[rye]

​I think it's important to note the difference between "participations" and "pre-scouting." Participations are simply a class for joining competitions and teams together; they're used to model a team's presence at a competition. Pre-scouting does use such a relationship between teams and competitions (as robots can and do generally change between competitions but rarely at competitions), however it should support fields and there should be capacity for multiple pre-scouting records to be entered and compared. Pre-scouting will obviously be non-functional if it is not added, so it's fairly important.

In regards to which fields, ​I'd suggest allowing dynamic fields but not adding anything else. This is simply because the things that a team wants are subject to change (even between competitions), so it'd be a good thing to let the form generate what it wants.

[Sammidysam]

Sounds good to me. Should I make the pre-scouting model belong to a participation then? I'd advise against that, because I've encountered some hell doing that in other situations.

[cg505]

No, I would say it should belong to a team and a competition, and that's it. It's a little redundant, but that's okay.

[Sammidysam]

I fully agree with you.

On Jul 22, 2014, at 7:53 PM, cg505 notifications@github.com wrote:

No, I would say it should belong to a team and a competition, and that's it. It's a little redundant, but that's okay.

— Reply to this email directly or view it on GitHub.

[rye]

I agree with not chaining up pre-scouting with participations.

[Sammidysam]

Could we decide on a name for the pre-scouting model?

[cg505]

Robot? That's the main point of pre-scouting.