Hack Hitchin

Pi Wars has many challenges where fast acceleration and cornering are important for the fastest times. Certainly last year Piradigm, whilst it wasn’t the most powerful robot, when running well it was still traction limited in the Minimal Maze and Over The Rainbow Challenges. This year the Straight-ish Line speed test may also require good cornering and the Pi Noon challenge always favours good drivers (or code!) even more if the chassis has good handling. We’re hopeful that our software and hardware this year will be capable enough that extra traction would increase performance. To that end, we’ve started testing a novel ‘vortex generator’ style of generating downforce:

Before we explain the weird design,  some background:

Formula one cars corner much faster than normal cars due to their aerodynamics: as they move along,  they use wings to deflect the air upwards, pushing them into the ground, increasing grip without increasing weight. This works great if you have the power and speed to do that. unfortunately most Pi Wars challenges are completed at less than 5mph, so the wings would need to be huge to have any effect.

In another, more closely related analogy, Micromouse robots need to accelerate and corner quickly to solve their mazes in the fastest time. As designs have developed, the winning teams in this competition now all use fans to generate downforce. The mice have a flexible skirt under their chassis, much like hovercraft have, but these are arranged so the fan sucks the air out, creating a low pressure even when the mouse isn’t moving, sucking the robots to the ground. This works well since their course is very flat and smooth, so the skirt has almost no leaks. Check out their incredible performance in this video from a competition this year:

Inspired by those, and the small toys that can run on ceilings, I first included a downforce generator in one of my projects in my entry for power tool drag racing:

This design was a little different to the above mechanisms, it used a vortex suction generator, which is a vaned, high speed spinning bowl that spins the air rather than sucking it, to generate the required low pressure with lower power consumption and less reliance on a good seal with the ground. The theory is that because the air is spinning, there must be a pressure gradient to keep the air going in a circle. Since the outside of the bowl is at atmospheric pressure, the centre must be at a much lower pressure, sucking the bowl down.

For Pi Wars we’re hoping to use a similar design but on a smaller scale, and only if the rest of the system is fast enough to benefit from it. So far we have 3d printed the above CAD:

And done some spin up tests in a test rig:

In this test, we held the rotor above a metal toolbox, that was supported by some scales. We were hoping to both test if the rotor could survive the very high speeds required and,  if it did, what level of downforce we could generate (measured by the lift or reduction in weight of the toolbox). For the test we were stood well back, with a full face shield on in case the worst happened.

From the test video, you can see it was a successful test: the rotor survived spinning up to ~14000rpm and generated over 900grams of downforce, despite having over 5mm of ground clearance! For comparison, from the latest CAD model we have of the overall robot design, we’re expecting the all up weight to be about 800grams. Which means we should be able to corner at up to 2g, if we have sufficient control.

On the software side, we’ve been further researching kalman filters and how we might be able to fuse encoder data with the data from the IMU to give us the best possible positional information, and we’ve also had a few more components arrive:

multiplexer, ToF sensors, IMU

I recently received the email from Piwars reminding us that the end is in sight. “Thanks Mike and Tim!”

I don’t know about the rest of you, but it certainly gave me that same warm fuzzy feeling inside that you get when you wake up knowing you are late for work!

Where are we with our robot? Well, that is a very good question. We meet as a group at least twice a week to push the project forward, but we also use our evenings and weekends as well. Although we did get stuck with EM interference issues for a good couple of weeks, we have now recovered from that and made a huge surge forward with getting TITO 2 ready for the impending challenges.

• TITO 2 , although still in prototype mode, has now successfully and repeatedly navigated our mock up of the Minimal Maze. Seeing it do this really helped me believe that we will get it ready in time.
• We also have tested TITO 2 on the straight line speed track, however not at full speed…not even close. I’d like to get a few more runs at this to dial in our tweaks so that it doesn’t touch the sides.
• Our RC mode has also been tested (to the dismay of Mark who very kindly spent at least 40 hours 3D printing the shell). We know that it at least works in this configuration, but there are some significant improvements to be made, as the general consensus is that it is “a little twitchy”. That and the tank steering mode has made it nearly undriveable to all but experts (ie Mark).
• Line following has hit a snag. Our sensor board is clearly suffering an injury of some sort and so we may have to fall back to OpenCV and a Pi Camera. As we have little to no code for this yet, I’m not even slightly concerned………
• Slightly Deranged Golf is basically RC mode with a ball moving attachment. This attachment is yet to be added to the bot but has been tested in prototype stage.
• Pi Noon is again basically RC mode. Once we’ve sorted the steering and throttle issues, I’m sure we will have this pegged!
• Skittles. This one always fills me with joy. We have made progress and have a prototype that will actually do this. I mean, it’s not tested in any way shape or form. But surely that’s just minor details?

Here are a few short videos showing off what we have accomplished so far.

So, after checking back in with you I hope you can see that we are moving forward!

Sorry for no posts recently, it appears life can get really busy, really quickly!

Since the last post we haven’t been idle though. The prototype bot is now drive-able both remotely and autonomously using distance sensors. We have a short video of it following a wall (albeit very slowly), but it is doing it!

https://drive.google.com/open?id=0B2Socfm_uuw9VDBXbFZIaGZmelE

Whilst busily working away testing sensors, we encountered a problem…and I quote Martin

“After some initial success with autonomously driving our test chassis using an old analog distance sensor, we set about upgrading to some snazzier laser distance sensors with much better resolution, talking to the Pi Zero over I2C.  In the test setup the sensors dutifully reported the distance they measured, but as soon as we tried to actually drive the robot the sensors started to reset themselves, losing their bus addresses and returning garbage values. As the problems started when we started turning the motors, the suspected causes were either noise on the power supply, or radio interference.  

Hi World,

I promised proper coding and possibly some testing…well I may have to disappoint. Coding has happened (although as some of it’s mine I wouldn’t class it as proper) but we have only limited testing so far, no vehicle movement, just individual components.

We have been attempting to find a secure way to attach our wheels to the motors. Last year we 3D printed wheel hubs and they worked, mostly. In last years testing they proved reliable, reliable to fall off that is, so we resorted to glue which meant minimal ability to replace motors or wheels should something break….which it did on the day (rear left gearbox on motor was having huge issues). So this year, something new.

The silver round metal object is our lovely new aluminium wheel hub. Its tiny which is both good and bad. The centre hole is 4mm and fits our motors beautifully, however the grub nut and 4x bolt holes are just too small for the forces we expect to shove through it. Not mentioning that the ebay special has an american standard screw thread which none of us can find in our spares boxes.

So, onto the work that needs to be done. We need to re-tap them, but obviously we can’t keep the hole the same size as the new thread would be so weak against the old thread. So we are upsizing them from M3 (ish) to M4. This will give (hopefully) a stronger grip for the bolts that will be holding the wheels onto the motor shaft.

And the result, 4x colour coded allen cap head bolts for added stealth. I say stealth, amusingly the first test 3D print of the lovely new wheel hub (designed by Mark last year and lovingly modified by Paul for the new bolts) was done in a blue ABS plastic as that was what was still in the 3D printer. Group members have already shown a liking to the blue/black combo, so we will have to wait and see which colour scheme we end up with.

Mark in the photo to the left can be seen working hard (as he usually does) re-tapping the aluminium shaft blocks, and the rest of us can just be seen performing all kinds of ungodly wiring and coding stuff. The really really badly tangled wiring mess in front of Mark is my desk, but they always say “If a cluttered desk is a sign of a cluttered mind, of what, then, is an empty desk a sign?”.

So, coding. There is currently two of us working on this task and we are taking last years code as an example of what and what not to do. The on-board hardware has changed significantly to reduce size and weight so a lot of the old code is no longer useful as it was for talking to devices no longer present.

This little sketch is our first stab at trying to organise what talks to what and how many modules we will need. Safety is always paramount with us, so we will be utilising last years method of always having something listening to the controller so the motors can be put into neutral at ANY point, no matter what its doing. This will probably be done with the launcher thread running permanently in the background always listening for a specific button press and locking our any other modules access to the motors if needs be.

And we then segway into course construction:

What you can see here is Brian and Johnny thinking way too hard about the course measurements. They are perfectionists (which I love) but are slightly stifled by the lack of measuring tools. They have found an old school ruler in one of the cupboards and are using that to measure and cut wood for the minimal maze task. Rather them than me.

So with course prep going on and lots of wiring and coding progressing, I REALLY want to see a vehicle test in the next week. I think we can do it (if I pull my thumb out). I know it will boost the teams confidence if the thing actually moves in a controllable way.

Watch this space…..

Oooooh there is so much I want to share you you all about our newest robot…but can’t. Sorry, sworn to secrecy 🙁

Don’t dismay, here is what I CAN tell you:

Over the last couple of years I’ve assisted in building several wheeled bots and prototypes (actually, counting back in my head its more that I realised). These range from tiny little three omni wheeled mico-pi noon entrants all the way up to our beloved bighak. One thing that they all have in common during the building stage is we haven’t ever built a rig testing station. By that (excluding bighak due to its size and weight) they have all rested on a china mug when performing motor tests. Normally this induces a fair amount of fear in me as the vehicle spins up the dangling wheels to their full speed (not always in the same direction as each other and not always stably…) and having loose wiring precariously close to the rubber grippy tires.

World, say hello to our newest creation:

It may not be the most photogenic, but this is a big thing! We now have a ‘safe’ way to test our prototype AND drink our cups of tea, something not previously possible.

Now, we’ve had to do this previously but as I’m in charge of the blog I’d thought it required mentioning so that future Pi designs might be tweaked. Every time we come to mount the Pi (or pi camera module) we very quickly remember that the mounting holes are M2.5. If you didn’t already know, M2.5 bolts are not generally available from hardware stores as they are tiny. The smallest I’ve seen is M3, of which I now have a small stock with nylock nuts to pair with. Just to be clear, I’m not saying they are impossible to come by, far from it. A quick google will probably show loads of places to buy them online. What I’m trying to get across (and probably failing) is that not many DIY projects use them and so I don’t tend to hold a stock of them at home. This has previously led us to do something drastic:

What you can see here is me finger turning a 3mm drill bit through an existing 2mm mounting hole. I’m using my fingers and not a drill mainly because the drill is cordless and not charged as I had forgotten I’d needed to do this 🙁

Before I get any grief, please don’t try this at home. I’m a responsible adult who will take responsibility if I break my own Pi. I don’t want to be responsible for anyone else who copies me.

Onto the “new” toy, ah the wonders of the second hand market! Last year we used a Wii controller with it’s nunchuk to drive our robot wirelessly. This year we wanted to improve on this as we were basically holding two separate controllers yet only really using one hand/thumb to drive thing. I’ve been researching PS3 controllers and have done a fair few tests with positive results when interfacing with a Pi and Python. Whilst the PS3 controller is ergonomic I don’t like how the thing pairs with the bluetooth adapter. It isn’t a simple button press and requires knowledge of the ‘dark side’ to get it to work. This means if the PS3 controller broke or ran out of juice mid contest we’d be frantically typing on a laptop to try and pair a backup. So, back to the Wii controller it is because this easily pairs each time the robot boots by pressing 2 buttons on the controller. this means we can have many spares and no-one needs divine knowledge as to which one is currently paired.

Whilst I was passing by a favorite second hand shop in town, they happened to have a Wii classic remote going cheap. I knew the Wii had plastic remote holders in the shape of guns and steering wheels and that they had balance boards and the like, but I wasn’t aware that these were made…probably shows just how much use my Wii actually got 🙁

I bought the controller and hurriedly ran home like Charley from the chocolate factory to see if I had purchased something useful or whether I’d wasted my money. I was in luck, the CWIID python module supported it (mind, this took a fair bit of googling and github searching to find the exact text state to request from the module and each button ID to test for).

If you have very good eyes you might be able to see a load of text on the screen behind the controller above. Each one of those is a test for a button state and a print line to report a button pressed.

So, at this point we have a basic test rig and a basic controller input. Next up will be proper coding and hopefully testing.

Before we go any further lets agree to keep any costs between us. I wouldn’t want my family knowing exactly what I’ve spent on my hobbies instead of holidays 😉

So with that out of the way, the basic drive-train has been decided and building started so next we need to focus on some of the challenges. Golf first as it has peeked our teams interest for most comical effect. Amusingly the photo above actually shows us doing first feasibility tests on using an arm mounted putter on a cheap lightweight servo. When I say putter, I actually mean metal ring with a pencil stuck to it 🙂

I can’t believe how many ‘unlikely to succeed’ ball moving suggestions we have gone through on the golf challenge. It started with the simple yet effective servo mounted putter pausing slightly with a variable power solenoid kicker and ended with gas powered combustion ball launcher. Seriously, someone (probably me) actually thought it might be funny to “fire” the ball….not a good idea, not power adjustable between shots and DEFINITELY not guaranteed to keep the ball touching the ground at all times.

Still, we haven’t actually settled on the putter idea as the solenoid one keeps rearing its little head because it seems ‘simpler’ and ‘less prone to mechanical failure’. On testing the metal putter idea above it was quickly noticed that any competing solenoid idea would either have to have a reasonable mass on the moving arm or be extremely powerful to have any chance of moving the ball any distance. Then comes the adjustable power problem….so, so far the putter is winning.

The first round of tests were done using an Arduino Mega the team member writing the test code to make a servo move had one to hand, but obviously we won’t have room for such luxury in our bot so the second round of testing will be done on the Arduino Nano, shown with a carefully placed Raspberry Pi NOIR camera in shot. The reason for using Arduino’s to control the servo is basically PWM timing accuracy. Obviously the Raspberry Pi will be in control of the whole system and will tell the Arduino exactly what to do at any point, but why not sub-out some of the low level work to devices that are designed to do this kind of thing day in and day out. That said, the Arduino will also be used for multiple things in combination with the Pi. One such task will be analog to digital conversion as the Pi has no analog GPIO pins and a Nano is a very cheap way to incorporate this feature.

Now that the drive-train design has settled down, we thought it wise to buy spares of everything. 8x motors, 8x motor controllers (ESC’s) and lots and lots of connectors and wire. Last year we went through soooooo many cheap ESC’s. Since then we have found a decent supplier, albeit from Australia, and have stocked up. Plus it made the delivery cost more efficient, well that is what I’m telling my wife.

Well, onward we go and always attempting to avoid the bunkers 😉

Well, after having our entrance accepted maybe we should actually get on and build something.

The Piwars challenges have evolved since the last competition. Some are similar and need only tweaks to the our previous design where as other challenges are new but kind of build on previous years challenges. We’ve been thinking about this for some time (my excuse for not actually doing any work until now) but now is the time to put some parts together and build a drive-able bot.

First things first, planning. Do we dismantle Tito, our old bot, or building from scratch?

Previous Piwars robot called TTOS aka Tito.

Overwhelming emotions seem to be stopping us destroying our previous creations plus we intend to make our new bot smaller lighter and based on a pi zero so other than wheels and motors (which have been hammered in testing and competing) not much else is transferable.

Laser cut prototype frame/chassis.

Mark Mellors kindly designed and laser cut a frame onto which we can to attach our motors and ESCs so that we could start putting stuff together. I put together the basics of a wiring loom. Its modular (detachable connectors in key positions) so motors and/or ESCs can be swapped out in case the magical blue smoke is accidentally released 🙂

We suffered last year from at least one damaged gear box so this year I’d love to have an easily replaceable drive system should the worst happen.

Prototype wiring loom

Experience from last year showed that building a robot and being able to drive it competitively are two separate things. We were a little close to the deadline last time as we were still writing….erm I mean tweaking… code on the morning of and in between challenges. So this year we are all very keen to get a drive-able prototype together everyone can practice driving and have confidence that we could actually complete a challenge or two.

Prototype progress so far:

• Frame laser cut.
• Motor clamps 3D printed.
• Motors bolted to frame.
• Motors wired with detachable connectors to ESC’s and battery.

Prototype part assembled.

What an event! We came away exhausted but with smiles on our faces and three prizes! Here’s how we did in each event:
Skittles – 1st

The skittles challenge was one of the only ones where our innovations really paid off, our attachment worked just as we’d hoped and we got spares on every round. We even managed to get a strike on our practice go! We only had one minor issue- there was a slight issue with one of the rotor motors that meant it didn’t always spin up properly but we managed to overcome this on the day by repeatedly spinning up and slowing down until both rotors were spinning properly. The laser pointer worked great for lining up, knocking the pins down to get the spares was really satisfying, we had so much ball speed we not only knocked the spare pin over, we smashed it into the backboard! (back board added just because of our attachment : – ) We also had a very minor issue with maneuvering. We knew we would be very front heavy, but the front tyres compressed so much that the attachment hit ground, adding friction and reducing the grip the rear tyres had. Luckily Mike had time to make some nice little ptfe skids and put lead ballast in the ‘booster’ battery holder. This meant we could actually maneuver, but it was still slightly challenging to line up sometimes.

score: 8,2  9,1   9,1

Speed challenge – 1st

The time spent choosing the motors/voltage/wheel sizes really paid off here, and we got times within 0.1second of what we predicted! Unfortunately we didn’t get the sensor feedback working in time but luckily it wasn’t actually required. Four grippy wheels, tuning the motor speeds to be equal and aiming straight was all that was needed to avoid the sides. We really should have done more tuning beforehand, as we hit the sides on the first few runs whilst dialing the motor speeds in but after that it went straight as an arrow. When we did hit the sides, we just lightly glanced off or continued relatively straight whilst sliding along the sides, so the front bearing guide worked as hoped. Starting at the back of the starting box also allowed us to get some speed up before entering the timed section, saving about 0.1s (fairly significant when your overall time is 1.5s :-). The motors didn’t seem to mind being significantly overvolted for that short period, so we might actually be able to go to an even higher voltage next time, if we can find some suitable motor controllers.

times: 1.618s, 1.54s, 1.526s

Proximity – 3rd

This event was a total fluke for us! We didn’t manage to get the code for our secret (blog post to follow), super accurate sensor finished in time so we were just using a regular IR sensor as many others were. In the hour of testing we got on the day, we were getting +/- 5-10mm of noise in the stop positions, so we settled on a fairly conservative target of 13mm. When we got on the course, the judges commented that many robots using IR had really suffered, so we were then even more nervous. On our first run we got 4.5mm! That was a great, lucky start but we were worried, was that just random luck or was the wall colour or reflectivity causing the robot to stop late? If we got 4.5mm+/-5mm or more, we were quite likely to hit the wall on the next run! We decided to risk leaving the code as it was and lined up for another run. We got 4.5mm again! We’d never been that close or consistent in or practice runs. Maybe the wall reflectivity was actually doing us a big favour. We had originally been testing with a wooden wall, then switched to paper. We had found that the paper might be more consistent but it’s always hard to tell when the results are quite variable. We crossed our fingers and went for the third run: 0.5mm! What a set of results! We were more shocked then anything after the dodgy test performance. It was clearly a fluke but we were just happy we had finished without incurring a fault. We weren’t sure he we’d do in the results, as we’d heard of others getting 0.5mm results and several with consistent few ~3mm scores. In the end we got third.

scores: 4.5mm, 4.5mm, 0.5mm

Three point turn – 7th

This was another challenge where we had grand plans of clever sensors that didn’t quite pan out due to being behind with the code. Like the proximity challenge, we spent an hour on the day of the competition tuning the timing in the basic code we had. We knew the floor surface would have quite a strong effect on the turn speed, so we tested on the closest surface we could find: the textured tiled floor. It didn’t take too long to get the timings pretty close and our test results were surprisingly repeatable. Once we got on the actual playing surface of the challenge though, we quickly found we needed to change a few parameters. On the first one we over shot and drove straight off the platform after the first turn. Luckily there’s just enough time allowed to tune your code once you’ve started the challenge, so we quickly ran back, got the laptop and guessed some new numbers. On the second attempt we were much closer but again slightly went outside the playing surface on the second leg and overshot the finish at the end. Again, we tuned the numbers and went for it again. It wasn’t a perfect run but we at least got back behind the starting line. Dave proved himself as the master of guessing the magic timing numbers , every one of his guesses gave the spot on correction we needed for that element.

times: 16s, 16.04s, 14.5s

Obstacle course – 9th

We were quite hopeful of doing well in this challenge as we had speed, grip, ground clearance and a reasonable amount of driving practice under our belt. We weren’t too worried about most of the obstacles as they were less severe than the wooden obstacles we’d attempted in testing; the one unknown was the turntable, it looked like it might be tricky to line up and time the entry. We’d also noticed in some of the previous challenges that the gearbox that started clicking during testing now wasn’t reversing correctly, so the robot didn’t turn around the centre as it usually did. Rob did a good job of compensating for the dodgy gearbox, getting through the first few obstacles with no faults. The gearbox really scuppered us with turntable though, he struggled to line up and the robot didn’t accelerate straight forwards when asked to, causing us to get caught by the rotating bollards. By an unlucky design fluke, the bollards were a close fit with the gap between our wheels and we got wedged. We have nearly enough grip to climb vertical walls so we initially hoped we’d be able to climb out but we then got wedged against the wall and couldn’t move. In retrospect, we should have been clearer on the rules as none of us knew what the penalty was for getting rescued, so we took some time deliberating. If we’d known it was no penalty for a rescue, we would have moved the robot much more quickly and could have got a much faster time. The rest of the course was uneventful, although we were slightly disappointed with the run over the seesaw. In testing, we’d found the robot was fast enough to hit small wooden blocks and fly quite a distance, so we were hoping we could hit the ramp at speed and finish the course in the air. In reality, the dodgy gearbox hindered s again, and Rob couldn’t quite get it lined up as he hoped. We were still in the air over the finish line, but only because we were bouncing… Still, 1:26 with one rescue wasn’t too bad, good enough for 9th place. We shouldn’t dwell too long on the could haves and might have beens, but after looking at the video for our obstacle run, if we’d rescued the robot immediately after we got stuck, we could have finished in less than a minute with one rescue (no penalties), possibly putting us in first place.

time: 1:26 with one rescue

Pi Noon – second round

Our first round was over very quickly: Rob expertly maneuvered TTOS alongside Bedford Modern then turned in for the kill, popping the balloon in less then ten seconds! The second round didn’t go as well. Mark volunteered to drive this one (mistake?) and we hadn’t had chance to replace the dodgy gearbox (definitely a mistake), so turning was hampered. Westpark Club had the interesting idea of mounting the balloon/spike on the back of their robot, pointing forwards, making it easier for them to keep the balloon out of the way. After a short period of jostling for position, with TTOS failing to get around their side/back, the two robots came together. Westpark Club had lined up better and burst our balloon first. We were out.

Line following – not placed
Before the day we had made the mount for the line sensor and got some simple code written, but it was completely untested. As soon as we saw the course we knew it was pointless to distract ourselves with trying to get it working. The course was so narrow and twisty that we would really struggle to get around it. We had designed our sensor mount to work best on relatively fast line following courses, with no turns over 90 degrees and lots of space between turns, like the course was last year. Those courses favour a sensor that is well in front of the centre of mass. This tight course strongly favoured robots with the sensors very close to the centre of turning, allowing them to follow the very twisty bends and switch backs. So a no score on this one.

Code – 20th

Our low position in the coding probably reflects more on how little coding we’d done when we submitted it than the actual quality of the code. We’ll do better next year!

Aesthetics – 9th

Given we were one of the few entries that didn’t have a mass of wires sticking out, we were hoping to score higher in this challenge.

Build Quality – 9th

Like the aesthetics ‘challenge’, we were hoping to do fairly well here, as the core robot was solid and had some nice features.  Maybe not actually having enough room for the wiring and connectors let us down, or maybe we didn’t ‘sell’ the design enough to the judges.

Blogging – 12th

Not a bad score, considering we didn’t start until pretty late in the day and some of the other blogs were excellent.

Overall – 3rd!

A fantastic result for our first time at the competition! With a bit more consistency and preparation, we’re hoping for higher next year

🙂

Other awards

Most featured
We knew we’d got more attachments than many of the other competitors but hadn’t considered this was an award during the run up to the event, so we were quite surprised when we were announced as the winner!

The team’s been working hard the last couple of days. Let’s compare the progress against the job list from Sunday:

Wiring in the new body:

• 12v power/motors: done (Mark  + Paul)
• 5v power: done (Paul)
• Analogue signals: half done (Mark)
• Pwm signals: not started
• Lcd: done (Dave)
• Other digital I/O: not started

Obstacle course:

• Practice driving: not done

Skittles:

• Mount arms to the servos on the ball launcher: done (Mike)
• All the wiring (both power and signal)*: mostly done, some routing issues (Mike)
• Write some code that allows the wii mote to control the servos and the spinner motors*: not started

Pi Noon:

• Design and print a wire holder*: done (Laser cut, Paul)
• Practice driving: not done

Straight line speed test:

• Design and print the distance sensor holder / bumper: done (Mark)
• Design and print the second (boost) battery holder: not done
• Turn my pseudo code into real code: not done

Three point turn:

• Finish designing the camera/line sensor mount and print it out: done (Mark)
• Design and print the beacon: started (Mike)
• Get the basic code working*: Dave and Rob have spent two evenings finding and fixing bugs. Getting there but still lots to do
• Tune the timings*: not started

Line follower:

• Finish designing the line sensor mount and print it out* done: (Mark)
• Turn my pseudo code into real code*: not done
• Tune it*: not done

Proximity alert

• Turn my pseudo code into real code*: not done
• Design and print the attachment for our probe: not done
• Tune it:not done

* = high priority

T-4 days? Agggghhhhhhh!

As part of night’s work the Ball Flinger has started to take shape….

First stage of assembly

The flywheel assembled with kevlar anti expansion strengthening.

Ball pusher servos and arms installed… now to wire it up and attach the speed controllers