really good competition software

[Sam Phippen]

Hi Everyone,

I wrote some really good competition software here: http://github.com/samphippen/which-match-is-it. Rob gave me a hand. I’m going to send some puppet patches so this can run on badger shortly.

Thanks

—

Sam Phippen

[Peter Law]

Hi,

Sam wrote:
> I wrote some really good competition software here:
> http://github.com/samphippen/which-match-is-it. Rob gave me a hand. I'm
> going to send some puppet patches so this can run on badger shortly.

A quick look shows that this is backed by some yaml files, and not
poltergeist...

I've been working (admittedly quietly) on getting poltergeist to
support things for this year. I'm currently in the process of tidying
things up before adding the new stuff we need (the major thing being
two arena support).

Whilst it doesn't currently have an external API, the plan is that it
could if needed, but mostly that it shouldn't do (as it will generate
static files which get pumped at badger for serving).

I think that throwing that away would be bad, as I thought that (aside
from the stress of making things happen) it actually resulted in a
pretty decent view of stuff being available last year (and yes, it has
support for a changeable delay in the schedule).

Where did you plan to get the yaml files for this to use from? (One
option might be to have poltergeist generate them I guess).

Peter

[Rob Spanton]

On Sun, 2014-03-02 at 16:24 +0000, Sam Phippen wrote:
> I wrote some really good competition software here:
> http://github.com/samphippen/which-match-is-it. Rob gave me a hand.
> I'm going to send some puppet patches so this can run on badger
> shortly.

Back story: I was annoyed that we still didn't have any competition
software that could do the minimal amount of required stuff (telling us
what match we are currently in).

R

[Sam Phippen]

On 2 Mar 2014, at 16:35, Peter Law <peter...@gmail.com> wrote:

> Hi,
>
> Sam wrote:
>> I wrote some really good competition software here:
>> http://github.com/samphippen/which-match-is-it. Rob gave me a hand. I'm
>> going to send some puppet patches so this can run on badger shortly.
>
> A quick look shows that this is backed by some yaml files, and not

> poltergeist…

That is correct

>
> I've been working (admittedly quietly) on getting poltergeist to
> support things for this year. I'm currently in the process of tidying
> things up before adding the new stuff we need (the major thing being
> two arena support).

Cool

>
> Whilst it doesn't currently have an external API, the plan is that it
> could if needed, but mostly that it shouldn't do (as it will generate
> static files which get pumped at badger for serving).
>
> I think that throwing that away would be bad, as I thought that (aside
> from the stress of making things happen) it actually resulted in a
> pretty decent view of stuff being available last year (and yes, it has
> support for a changeable delay in the schedule).

Sounds like it might be harder to work with than some yaml files.

>
> Where did you plan to get the yaml files for this to use from? (One
> option might be to have poltergeist generate them I guess).

A file system

[Peter Law]

Sam wrote:
> Sounds like it might be harder to work with than some yaml files.

Actually, it's less work (from badger's perspective) because all it
needs to do is throw the files at a browser and the user can see
what's going on. No further processing required. All the work is done
on a machine that's _not_ being hammered with requests (and done on a
push basis).

>> Where did you plan to get the yaml files for this to use from? (One
>> option might be to have poltergeist generate them I guess).
>
> A file system

Ok, let me rephrase: where's the data coming from? As far as I'm
aware, at this point, poltergeist is _the_ canonical source for this
data and it doesn't output in this format currently.

Peter

[Peter Law]

Hi,

I've just had another look at this, and there are a number of issues:
* Non-unique match numbers
* Poor storage of who is in each match
* The assumption that both arenas will remain perfectly in sync
* No compensation for delays > MATCH_LENGTH

Some further detail on each follows (in order)

A match number is not a unique id for a given match, instead referring
to a pair of matches which happen to occur at the same time. This is a
problem when trying to work out where a team should go, as well as
when trying to tie a match's scores back to its teams and/or schedule.

The storage of who is in each match is currently a space-delimited
string of TLAs. This is not going to be converted to an array by the
yaml loader, and should instead be a proper array.

While it would be nice if both arenas could be kept perfectly in sync,
we know from experience that it's hard enough to keep one arena on
time. I think it would be wise to have the option of having separate
delays for each arena.

I think we need to work out what's going to happen if we end up with a
delay of more than the length of a single match, particularly around
the boundaries of the match sets. While a small number of matches
could just overrun into, say, lunch, a larger delay might require
dropping a 'round'.


I think most of these can be fixed, but I'm going to focus on poltergeist.

Thanks,
Peter

> --
> Sam Phippen
>
> --
> You received this message because you are subscribed to the Google Groups
> "Student Robotics Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to srobo-devel...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.