Smallpeice 2014
13 views
Skip to first unread message
Andy Busse
Aug 12, 2014, 4:16:40 PM8/12/14
to sr...@googlegroups.com
Hello folks,
As (I hope) most of you are aware, from 28th July - 1st August we ran
our third summer school with the Smallpeice Trust and ECS, based in ECS'
labs and The Cube, so here's the "week in review" post. Feedback from
students and supervisors is being compiled by Smallpeice, and will make
its way onto trac when I see it.
I know I've left quite a bit out here - those involved, please fill in
the blanks. I'd really like this to happen next year, and documenting
what to keep the same and what to improve can only help.
tl;dr: A big improvement on last year's event, thanks to the effort of a
number of blueshirts. Still room for improvement, but we've basically
got the format right now. Much less firefighting, much more fun.
Positives:
* The number of teams (about 5 out of 10) using sensors on the robots
was encouraging. Holding it on Monday afternoon helped, and having the
worksheets much simpler and focussed on building sensors worked well
too. They can still be improved upon, but the basic format here now works.
* The (basic) python worksheets were tackled by a much larger number of
students before the week (over 50%).
* From what I could tell of the python workshops (now two hours long),
most had something non-trivial working on the simulator after leaving.
* The organisation of the week helped hugely, and now feels right.
Electronics workshop on the afternoon of the first day, python on the
morning of the second, it slots together in a very relevant way. Only
thing I might want to add in here is a 20-minute "Mechanical" talk on
the Tuesday morning to introduce what's available to build robots out of
(and to some extent, how), to try and alleviate the blender situation of
tools and bits.
* SR's relationship with both ECS and the Smallpeice Trust has improved
further. Both want to repeat this next year (I think Dave Oakley wants
more students on the next one), and I believe we should, too.
* Think of all the benefits you get when a load of blueshirts come
together to run an event. Lots of healthy discussion on game ideas,
prototyping of an arena wall situation, some videos got filmed, and lots
of fun was had.
* I'd say we're now in a position where we can use the summer school
format as a test-bed for SR ideas/technologies. To some extent this
happened with testing a game idea and an arena wall prototype. For
example, things like changes to the competition software could be tested
here - it's an event small enough that firefighting isn't a major
headache. It feels a lot like SR competitions of old (circa 2010)
* Smallpeice supervisors were very helpful this year.
* Most of all, 49 students had a fantastic experience of a real,
challenging engineering project which for the majority will have a
positive influence on what they choose to do after leaving school. Might
even get some SR2015 teams out of it.
Room for improvement:
* There were some component ordering issues that meant we didn't have
everything the weekend before; partly my fault for not poking the
situation early enough, partly due to Denis and the ordering system, but
everything did arrive in time that the students weren't adversely
affected (and contigency plans to go to local hobby shops were in place,
too)
* Using the "legacy" kit was a challenge, both in terms of generating a
pyenv for the game (I'll leave those details to Alistair), and due to it
not being as robust as the current generation (a handful of MBv3's got
fried through incorrect wiring, despite stringent checking).
* A lot of prep was left until the month before the event - some of this
was due to people not knowing their availability for the week until
then. Thanks to the efforts of blueshirts who poured their time into
making the week happen.
* Elec labs turned into a bit of a blender. We ought to have insisted on
teams clearing their areas before moving to the cube.
* Not everything fit into the vault on Friday, so some rearranging had
to happen the week after.
Thanks,
Andy
As (I hope) most of you are aware, from 28th July - 1st August we ran
our third summer school with the Smallpeice Trust and ECS, based in ECS'
labs and The Cube, so here's the "week in review" post. Feedback from
students and supervisors is being compiled by Smallpeice, and will make
its way onto trac when I see it.
I know I've left quite a bit out here - those involved, please fill in
the blanks. I'd really like this to happen next year, and documenting
what to keep the same and what to improve can only help.
tl;dr: A big improvement on last year's event, thanks to the effort of a
number of blueshirts. Still room for improvement, but we've basically
got the format right now. Much less firefighting, much more fun.
Positives:
* The number of teams (about 5 out of 10) using sensors on the robots
was encouraging. Holding it on Monday afternoon helped, and having the
worksheets much simpler and focussed on building sensors worked well
too. They can still be improved upon, but the basic format here now works.
* The (basic) python worksheets were tackled by a much larger number of
students before the week (over 50%).
* From what I could tell of the python workshops (now two hours long),
most had something non-trivial working on the simulator after leaving.
* The organisation of the week helped hugely, and now feels right.
Electronics workshop on the afternoon of the first day, python on the
morning of the second, it slots together in a very relevant way. Only
thing I might want to add in here is a 20-minute "Mechanical" talk on
the Tuesday morning to introduce what's available to build robots out of
(and to some extent, how), to try and alleviate the blender situation of
tools and bits.
* SR's relationship with both ECS and the Smallpeice Trust has improved
further. Both want to repeat this next year (I think Dave Oakley wants
more students on the next one), and I believe we should, too.
* Think of all the benefits you get when a load of blueshirts come
together to run an event. Lots of healthy discussion on game ideas,
prototyping of an arena wall situation, some videos got filmed, and lots
of fun was had.
* I'd say we're now in a position where we can use the summer school
format as a test-bed for SR ideas/technologies. To some extent this
happened with testing a game idea and an arena wall prototype. For
example, things like changes to the competition software could be tested
here - it's an event small enough that firefighting isn't a major
headache. It feels a lot like SR competitions of old (circa 2010)
* Smallpeice supervisors were very helpful this year.
* Most of all, 49 students had a fantastic experience of a real,
challenging engineering project which for the majority will have a
positive influence on what they choose to do after leaving school. Might
even get some SR2015 teams out of it.
Room for improvement:
* There were some component ordering issues that meant we didn't have
everything the weekend before; partly my fault for not poking the
situation early enough, partly due to Denis and the ordering system, but
everything did arrive in time that the students weren't adversely
affected (and contigency plans to go to local hobby shops were in place,
too)
* Using the "legacy" kit was a challenge, both in terms of generating a
pyenv for the game (I'll leave those details to Alistair), and due to it
not being as robust as the current generation (a handful of MBv3's got
fried through incorrect wiring, despite stringent checking).
* A lot of prep was left until the month before the event - some of this
was due to people not knowing their availability for the week until
then. Thanks to the efforts of blueshirts who poured their time into
making the week happen.
* Elec labs turned into a bit of a blender. We ought to have insisted on
teams clearing their areas before moving to the cube.
* Not everything fit into the vault on Friday, so some rearranging had
to happen the week after.
Thanks,
Andy
Alistair Lynn
Aug 12, 2014, 5:27:42 PM8/12/14
to sr...@googlegroups.com
Hi Andy-
Thanks for firing the analysis cannons.
> * The number of teams (about 5 out of 10) using sensors on the robots
> was encouraging. Holding it on Monday afternoon helped, and having the
> worksheets much simpler and focussed on building sensors worked well
> too. They can still be improved upon, but the basic format here now works.
I think that's a lot higher than we get sensors beyond the webcam on
robots at the main competition. I wonder if we might look at how we
could integrate Giorgos's tutorials into the normal SR process?
> * The organisation of the week helped hugely, and now feels right.
> Electronics workshop on the afternoon of the first day, python on the
> morning of the second, it slots together in a very relevant way. Only
> thing I might want to add in here is a 20-minute "Mechanical" talk on
> the Tuesday morning to introduce what's available to build robots out of
> (and to some extent, how), to try and alleviate the blender situation of
> tools and bits.
+1
> * Think of all the benefits you get when a load of blueshirts come
> together to run an event. Lots of healthy discussion on game ideas,
> prototyping of an arena wall situation, some videos got filmed, and lots
> of fun was had.
The arena wall situation probably deserves a separate thread. We also
had two new people helping out—new blueshirt Henry and potential
blueshirt Matt, who both substantially pulled their weight over the
week.
> * I'd say we're now in a position where we can use the summer school
> format as a test-bed for SR ideas/technologies. To some extent this
> happened with testing a game idea and an arena wall prototype. For
> example, things like changes to the competition software could be tested
> here - it's an event small enough that firefighting isn't a major
> headache. It feels a lot like SR competitions of old (circa 2010)
+1. I was strongly reminded of SR2010/SR2011, although our all having
the extra experience helps a lot too.
One thing to note here is that Tom and I (with quite a bit of help
from Peter) ran srcomp during the Friday competition, and after some
munging beforehand I'm pleased to say it ran without a single hitch.
Seems like we finally have reasonable competition software.
> * Most of all, 49 students had a fantastic experience of a real,
> challenging engineering project which for the majority will have a
> positive influence on what they choose to do after leaving school. Might
> even get some SR2015 teams out of it.
If you're wondering why this isn't 50, it's because one didn't turn up.
> * There were some component ordering issues that meant we didn't have
> everything the weekend before; partly my fault for not poking the
> situation early enough, partly due to Denis and the ordering system, but
> everything did arrive in time that the students weren't adversely
> affected (and contigency plans to go to local hobby shops were in place,
> too)
I hear we only had one Allen key for the grub screws in the wheel
mounts, about which Denis laughed continuously for five minutes.
> * Using the "legacy" kit was a challenge, both in terms of generating a
> pyenv for the game (I'll leave those details to Alistair), and due to it
> not being as robust as the current generation (a handful of MBv3's got
> fried through incorrect wiring, despite stringent checking).
The pyenv changes to get back the MCv3 and JIO code weren't as bad as
they could have been, thought it would be nice if pyenv was modular
enough that they could be slotted back in rather than having to revert
to a year-old pyenv and cherry pick commits on top of that.
The only royal pain in the arse as far as pyenv went was squidge, the
window manager. The splash screen is baked into the binary for some
reason, which means having to go through a rather involved VM
procedure to recompile it. I overlooked a detail the first time
through (the text at the bottom is white and that went onto a white
background), which was a lot more difficult to untangle than it would
have been if the splash screen was just a png somewhere in pyenv.
Quite a few MCv3s went pop. I spent a fair bit of the early part of
the week building the arena so I didn't witness this in person but I
understand teams got their kits checked before plugging them in, only
to later unplug them for changes and haphazardly replug them leading
to the usual power-into-motor-output problem.
> * A lot of prep was left until the month before the event - some of this
> was due to people not knowing their availability for the week until
> then. Thanks to the efforts of blueshirts who poured their time into
> making the week happen.
Particular credit here to Giorgos, who somehow managed to get all the
ordering sorted despite not having done anything like it before and in
parallel with an internship.
> * Not everything fit into the vault on Friday, so some rearranging had
> to happen the week after.
As mentioned on the other list, there's rearranging left to be done
too—tomorrow at the vault at 2PM for anyone who happens to be free and
in Southampton!
Alistair
Thanks for firing the analysis cannons.
> * The number of teams (about 5 out of 10) using sensors on the robots
> was encouraging. Holding it on Monday afternoon helped, and having the
> worksheets much simpler and focussed on building sensors worked well
> too. They can still be improved upon, but the basic format here now works.
robots at the main competition. I wonder if we might look at how we
could integrate Giorgos's tutorials into the normal SR process?
> * The organisation of the week helped hugely, and now feels right.
> Electronics workshop on the afternoon of the first day, python on the
> morning of the second, it slots together in a very relevant way. Only
> thing I might want to add in here is a 20-minute "Mechanical" talk on
> the Tuesday morning to introduce what's available to build robots out of
> (and to some extent, how), to try and alleviate the blender situation of
> tools and bits.
> * Think of all the benefits you get when a load of blueshirts come
> together to run an event. Lots of healthy discussion on game ideas,
> prototyping of an arena wall situation, some videos got filmed, and lots
> of fun was had.
had two new people helping out—new blueshirt Henry and potential
blueshirt Matt, who both substantially pulled their weight over the
week.
> * I'd say we're now in a position where we can use the summer school
> format as a test-bed for SR ideas/technologies. To some extent this
> happened with testing a game idea and an arena wall prototype. For
> example, things like changes to the competition software could be tested
> here - it's an event small enough that firefighting isn't a major
> headache. It feels a lot like SR competitions of old (circa 2010)
the extra experience helps a lot too.
One thing to note here is that Tom and I (with quite a bit of help
from Peter) ran srcomp during the Friday competition, and after some
munging beforehand I'm pleased to say it ran without a single hitch.
Seems like we finally have reasonable competition software.
> * Most of all, 49 students had a fantastic experience of a real,
> challenging engineering project which for the majority will have a
> positive influence on what they choose to do after leaving school. Might
> even get some SR2015 teams out of it.
> * There were some component ordering issues that meant we didn't have
> everything the weekend before; partly my fault for not poking the
> situation early enough, partly due to Denis and the ordering system, but
> everything did arrive in time that the students weren't adversely
> affected (and contigency plans to go to local hobby shops were in place,
> too)
mounts, about which Denis laughed continuously for five minutes.
> * Using the "legacy" kit was a challenge, both in terms of generating a
> pyenv for the game (I'll leave those details to Alistair), and due to it
> not being as robust as the current generation (a handful of MBv3's got
> fried through incorrect wiring, despite stringent checking).
they could have been, thought it would be nice if pyenv was modular
enough that they could be slotted back in rather than having to revert
to a year-old pyenv and cherry pick commits on top of that.
The only royal pain in the arse as far as pyenv went was squidge, the
window manager. The splash screen is baked into the binary for some
reason, which means having to go through a rather involved VM
procedure to recompile it. I overlooked a detail the first time
through (the text at the bottom is white and that went onto a white
background), which was a lot more difficult to untangle than it would
have been if the splash screen was just a png somewhere in pyenv.
Quite a few MCv3s went pop. I spent a fair bit of the early part of
the week building the arena so I didn't witness this in person but I
understand teams got their kits checked before plugging them in, only
to later unplug them for changes and haphazardly replug them leading
to the usual power-into-motor-output problem.
> * A lot of prep was left until the month before the event - some of this
> was due to people not knowing their availability for the week until
> then. Thanks to the efforts of blueshirts who poured their time into
> making the week happen.
ordering sorted despite not having done anything like it before and in
parallel with an internship.
> * Not everything fit into the vault on Friday, so some rearranging had
> to happen the week after.
too—tomorrow at the vault at 2PM for anyone who happens to be free and
in Southampton!
Alistair
Harry Cutts
Aug 14, 2014, 1:27:11 PM8/14/14
to sr...@googlegroups.com
Hi,
On Tuesday, 12 August 2014 22:16:40 UTC+2, Andrew Busse wrote:
tl;dr: A big improvement on last year's event, thanks to the effort of a
number of blueshirts. Still room for improvement, but we've basically
got the format right now. Much less firefighting, much more fun.
Excellent! I wish I could have been there.
On Tuesday, 12 August 2014 23:37:42 UTC+2, Alistair Lynn wrote:
The arena wall situation probably deserves a separate thread.
Please do, I'm intrigued.
Harry Cutts
Harry Cutts
Andy Busse
Aug 16, 2014, 2:29:53 PM8/16/14
to sr...@googlegroups.com
Hi folks,
The results of the student's feedback forms are in (I received a snail
mail this morning). I'll ask Smallpeice for permission before putting
the detailed version on trac, but at a glance:
* Overall score down 1% to 84%. This is mostly because they've added a
"catering/halls" line, which has pulled the "venue" line down by 15%
* "Workshops" scores are up to 80% (Python, up from 69%) and 75%
(Electronics, up from 55%)
* Everything else under "course content" within a couple of % of last
year's scores.
* "Overall opinion of the course" at 92%
Nice one, folks - Hard work's paid off, and we had some ideas on how to
further improve the workshops too.
Thanks,
Andy
PS: To see last year's summary, see
https://www.studentrobotics.org/trac/wiki/2013/Smallpeice/Feedback
The results of the student's feedback forms are in (I received a snail
mail this morning). I'll ask Smallpeice for permission before putting
the detailed version on trac, but at a glance:
* Overall score down 1% to 84%. This is mostly because they've added a
"catering/halls" line, which has pulled the "venue" line down by 15%
* "Workshops" scores are up to 80% (Python, up from 69%) and 75%
(Electronics, up from 55%)
* Everything else under "course content" within a couple of % of last
year's scores.
* "Overall opinion of the course" at 92%
Nice one, folks - Hard work's paid off, and we had some ideas on how to
further improve the workshops too.
Thanks,
Andy
PS: To see last year's summary, see
https://www.studentrobotics.org/trac/wiki/2013/Smallpeice/Feedback
Reply all
Reply to author
Forward
0 new messages