Item added to basket:
TeamPMK arrived at the Highgate School at 8:30 am which gave us 90 minutes to set up the Bank Shot Field, ready our kit, set the cameras and steady ourselves for the challenge ahead.
Team C2 arrived slightly after us and were located in one of two of the Design, Technology and Engineering rooms - though being a tool-less platform, there was no need for any of the kit in the workshops!
Much like Team C2, TeamPMK have experience of building demo robots for IQ (Paul) and a couple of years of experience on VRC (Liam) but zero experience of building a VEX IQ Challenge robot......especially not in such a short time frame!
We arrived on the day with a VEX IQ Starter Kit with Controller (we knew there would be no time for sensors today!), a Competition Add on Kit and a small box with a few parts that were left over from demo robot builds......but in total less than £300 worth of kit.
Keeping a record on the day, we had a time lapse camera, GoPro, iPad and phone to capture photos, video and audio.
The Bank Shot game had been revealed back in April at VEX Worlds 2015, so Paul was fairly familiar with the game - but it was new to Liam. So the first 15 minutes was spent brainstorming ideas and some of the key rules onto a white board. With such a short build time, we knew that decisions had to be made quickly......but these can often be the worst kind!
Knowing that one of the key aims for this day was to be able to produce support material for new VEX IQ Challenge teams, we opted for a design that was a touch more difficult than others and would be difficult to get done in one daybut that many teams may consider.
By the time we'd finished, we had an 'ideal' design (a dual catapult loading from a central hopper) but we knew this would be unrealistic, so opted for a single catapult fed by an intake. We also had a very simple 'dump and scoop' robot as a "if all else fails we can fall back on this design". Because we are outside of the school year, the buildings internet was down, so there was no way of 'researching' ideas......we were on our own!
The robot would be made of up three major elements, which is similar to many robot designs. The chassis/drive train; the intake and the 'shooter'.
We agreed that for the best manoeuvrability a five omni-wheel based holonomic-drive would be the way to go. Liam, having had experience of similar builds in VRC began on this straight away. Working on the 13″ x 13″ footprint and building to the maximum size. This would require 3 motors - half of the permitted number allowed - but we felt it was important to have speed and flexibility in the drive. The five wheels and 'H' shaped chassis also give a solid base for any robot.
Paul set out on the catapult design, quickly mocking up a hand pulled, elastic band powered version on a square base that worked at the first attempt. After this shock and surprise, he set out on adding a motor to this to further prove the concept was sound. This proved slightly trickier. Mounting a VEX IQ beam onto a gear to work as a sort of 'cam launcher' it took many iterations to get one that allowed constant rotation and pushed the catapult launcher back enough to score.
But score consistently it did. This was achieved at about the same time Liam completed the drivetrain and so now working together we looked at how we could easily integrate the two elements (without redesigning either).
Just over two hours into a six hour build and we had almost mounted the working catapult to the drive train, but the smell of freshly delivered pizza had started working its way into the build area and so we took a short break for a Dominos (other pizza delivery services are available).
The limited time for design has led to us having two key elements of the robot which don't immediately 'fit' - one of the great benefits of the IQ system is the speed at which you can trial - and not for the first time in the day this meant we could get the catapult mounted and tested in a matter of minutes.
The next task was the intake, the catapult was working reliably, but we were hand loading and this was not possible in the game! Dual rollers that would pick up the balls and 'feed' the catapult were fairly straightforward to construct. The more difficult task was to mount this on the chassis so that it was low enough to grab the balls, angled to keep the balls moving and would feed into the catapult - again the flexibility of the system benefitted us and within minutes the intake was on and working.
Liam fired up ROBOTC and we dropped some fairly basic code on to the Brain so we could test all aspects of the robot. First full run and we moved, picked up a ball, loaded the catapult, fired and scored! With over an hour left we had successfully scored a 3 pointer!
We know however we can't just watch the clock for the last hour - so we work to improve small elements of the design now we have a 'complete' robot.
Liam tweaks the drive train, re-gearing for improved speed. Paul reworks the catapult cradle, which was still the same one from the first initial test. It's amazing how very small changes to this drastically affect the distance the catapult flies!
Driving practice then begins, the various control options are discussed and Liam codes the personalised joystick preferences for the drive, intake and catapult. All is going well until......with less than 10 minutes to go, disaster strikes! The rotating catapult launcher refuses to fire and the stability of the motor mount is less than optimal. Some quick tweaks and we are back on track.
More driving practice needed and some further coding required, but we have a robot that is scoring points and, most importantly, doing to consistently. The speed at which we can feed balls into the catapult is not as fast as we'd like and only firing one ball isn't ideal......but it works and TeamPMK is happy with what we have achieved!
Further videos and documentation will follow that look in depth at each of the stages and some of the learnings taken from the day.
Dan and I arrived at Highgate School at 9am which gave us an hour to get organised before the build began. On the way in, we passed the school's impressive VRC and VIQC trophy haul.
Team C2 and Team PMK were based in two adjacent rooms. Each team had their own VEX IQ Bank Shot Field set up in their room to aid with development and testing. We set up a Raspberry Pi with camera module in each room which would take a photo of the build area every 15 seconds and would later form the basis of our time lapse videos. We also had a standard digital camera to record some of our discussions as the build progressed.
We took a lot of kit with us and you can see on the time-lapse video that we have five IQ bins of parts, but this doesn't mean that what we built could not be done from standard kits. In fact, there is nothing more in our final robot than what can be found in the Challenge Team Bundle. Because VEX IQ teams are limited to 6 motors, it really helps to keep build costs down!
Dan has never built with IQ before but has competed in VRC for a number of years so knows how to build a good VEX robot. Chris has built plenty of IQ display robots but has never built a competition legal robot.
Before the event, we had familiarised ourselves with the Bank Shot rules so we knew the design constraints that we had to work within. As we are limited to 6 hours for design and build, our design discussion would need to be condensed into about half an hour and this was probably the biggest challenge of the build. We needed to come to an agreement on tactics and robot design very quickly so that we could get started with the build.
IQ teams should spend much more time on research, designs and game tactics before building.
We agreed that as there are no "possession" rules in Bank Shot (i.e. robots can hold as many balls as they like at any one time) we should build something that can collect and store a large number of balls. Holding more balls allows us to spend less time driving up and down the field and more time scoring balls in the goal. Being able to park on the ramp is essential so we need ground clearance to be able to get onto the incline and we need all-wheel-drive to give us maximum traction up the slope.
The hardest thing to agree on was what method to use to get the balls into the goal. We came up with a number of ideas and were torn between a catapult and a flywheel launcher. We weren't sure if the IQ motors were powerful enough to make a flywheel launcher so we decided to spend some of our build time creating a prototype of each.
Dan had prototyped an elastic powered catapult and Chris had built a dual flywheel launcher. The catapult would certainly give us the distance we needed, but we were concerned about how quickly we could reload and fire another ball. The flywheel also looked promising. We had done some rough calculations and worked out a gear ratio to test it - as it happens, the prototype was geared to high and couldn't achieve the maximum speed but the concept seemed sound and we could fire balls a short distance.
Back to the whiteboard for more discussion. We knew that we only had 6 motors to work with and however we build the chassis, it will definitely need 2 motors to allow the robot to drive and steer.
One motor would be assigned to collecting balls so we had three left to play with for the launching system. Both systems had their benefits - the catapult only needed one motor which means 2 left for other things. The flywheel needed 2 motors to get enough power which only left us with 1.
Our main concern with the catapult was still reload time so we committed to the flywheels. Now we had the systems identified, we could sketch out the overall design for the robot.
It's 12 o'clock already, 2 hours into a six hour build and we haven't started building anything yet. To make matters worse, someone has just come in to our build room and told us that Team PMK are already scoring balls in the goal. That's a worry, but we are confident that we have a good design and if we stick to the plan, we'll be OK. To the build area!
We decide to split the jobs - Dan is on chassis duty whilst Chris will continue to develop the flywheel launcher. We only have 2 omni-wheels so these will go on the front and the robot will steer by pivoting round the rear wheels.
It's proving tricky to find the balance between speed and power for the flywheel. Chris has tried quite a few gear ratios and is now looking for a happy medium with a theoretical speed of around 900rpm. Friction is our enemy here and we need to reduce any unnecessary losses in the system by ensuring everything can spin freely.
We meet with Team PMK on neutral ground in-between our build rooms. The decision is made to order some pizzas in to minimise downtime. A short discussion on toppings and sides ensues followed by a battle with the online ordering system. Finally, the order is placed and we head back to the builds and await our delivery.
We are now halfway into the build and we have a basic chassis and a working flywheel launcher. Using ROBOTC, Chris writes some code to accelerate and decelerate the flywheel using a toggle button. This reduces the load on the gears when the flywheels are switched off.
Pizza arrives and forces another short distraction from the build but we can't waste too much time, we need to get back on the case and crack on with the structural parts of the build.
Build resumes and both Dan and Chris focus on the frame for the body of the robot. This will form the area on which balls are stored and will also be where the flywheel assembly is mounted. The flywheels weigh a fair bit, so it needs to be strong and well braced to support the weight. We also need to consider the lateral forces that are put on the structure when the robot turns so cross-bracing is essential.
With the chassis and body taking shape, we can now trial fit the flywheels. They fit, but the structure is a little flimsy still. However, this will be rectified when we plate the top of the robot where the balls will be stored. This will prevent the twisting that is possible at the moment.
Dan focuses on creating a conveyor system through the centre of the robot. This will take the balls from the bottom to the top of the storage area and will also serve as a method of loading the flywheels. Chris is tasked with building the intake roller that will collect the balls. This needs to be wide enough to collect the rows of three balls in one movement. We didn't have any of the new long IQ drive shafts so another solution is needed for mounting all the intake rollers. The standoffs are perfect for this and also allow the completed assembly to flex a bit as the balls are pushed underneath.
We are very conscious of the fact that the only thing that has been tested is the flywheel, everything else is theoretical at this stage! We don't know if the chassis can haul the weight of the robot up the ramp and we don't know if the conveyor will pull the balls up the slope of the robot. We set about writing the code to test the conveyor and then we need to mount the intake roller to the rear of the robot
With just seconds to spare, our robot takes to the field for the first time. The manoeuvrability is excellent and the intake roller works perfectly. This system was fairly well tested by teams who competed in the Sack Attack VRC season so we were confident in the intake.
The flywheels are still having some friction issues, but it didn't stop us collecting 6 balls and scoring them in the goal.
Just in the nick of time, mission accomplished.