Hack Hitchin

The Flinger takes shape….

November 30th, 2015

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

Ball Flinger

 

 

 

 

 

 

 

 

First stage of assembly

 

Fly wheel assembly

 

 

 

 

 

 

 

 

 

The flywheel assembled with kevlar anti expansion strengthening.

 

 

General view with ball pusher arms installed

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

 

Posted in Pi Wars, Pi Wars Old, Raspberry Pi, Uncategorized | No Comments »

Mad dash

November 29th, 2015

Like many other teams, we’ve now appreciating how much there is left to do with only a week before the competition. On the bright side, we’re all managing to put in a bit of crucial extra time. Tonight we met at our space (I think for the first time we’ve ever hired it on a Sunday) to work on our modules:

I (Mark) was working on the wire routing, with Paul’s help:

2015-11-29 20.02.19

 

 

 

 

 

 

 

 

(Our speed controllers don’t quite fit, so we lost time hacking at the prints to make room)

 

Dave (also with Paul’s help) was working on getting the LCD display working, so that we can easily see what menu/challenge code we’re running:

2015-11-29 20.02.49

 

 

 

 

 

 

 

 

(Hopefully we can get a video of it working tomorrow, it’s looking really slick)

 

Rob was working on turning my terrible code into something that actually works:

2015-11-29 20.02.26

 

 

 

 

 

 

 

 

Mike was working on his solid looking ball launcher for the skittles challenge:

2015-11-29 20.01.59

 

 

 

 

 

 

 

 

And here’s the robot as it stands now, a nice looking but empty body shell and an overly complicated RC car:

2015-11-29 22.20.15

 

 

 

 

 

 

 

 

What’s left to do?  well, by challenge:

Obstacle course:

  • We could enter this now but it’d be nice to have all the components in the new body shell. That needs a load of wiring doing
  • Practice driving

Skittles:

  • Mount arms to the servos on the ball launcher
  • All the wiring (both power and signal)*
  • Write some code that allows the wii mote to control the servos and the spinner motors*

Pi Noon:

  • Design and print a wire holder*
  • Practice driving

Straight line speed test:

  • We could also enter this now but we really want to do it autonomously
  • Design and print the distance sensor holder / bumper
  • Design and print the second (boost) battery holder
  • Turn my pseudo code into real code

Three point turn:

  • Finish designing the camera/line sensor mount and print it out
  • Design and print the beacon
  • Get the basic code working*
  • Tune the timings*

Line follower:

  • Finish designing the line sensor mount and print it out*
  • Turn my pseudo code into real code*
  • Tune it*

Proximity alert

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

* = high priority

T-6 days? Agghhhh!

Posted in Pi Wars, Pi Wars Old, Raspberry Pi | No Comments »

Driving onwards

November 28th, 2015

On the previous drivetrain blog post we’d found that cordless drill motors were excessively large and powerful for a piwars robot. We continued the drivetrain search, this time looking for smaller motors that could work in a one-per-wheel (four motors total) configuration. From last time we know that we want a total power output of around 120watts, or 30watts per motor. At this point we were hoping that we could use the small ‘1000rpm’ gearmotors we’ve used on small combat robots before.

 

_MG_7522alt yellow and black colour scheme

 

 

 

 

 

 

 

 

 

 

 

 

 

 

They give our beetleweight (~1.5kg) combat robot great performance and it looks like other competitors are looking at them too. From previous testing we also knew they had a stall current of ~6A at 12V (72W input) so they look like they might work here. As before, we went to enter them into the drivetrain calculator , but found the 1000rpm motors weren’t listed in their motor database.So this time  we put together our own numerical model (spreadsheet) of the torque, acceleration etc, allowing us to change the parameters and see what happens to the performance: This is something we’ve used successfully many times before, for combat robots to dragsters:

acceleration calculator

So they’re ok but it looks like they top out very quickly. The top speed is much below the 12m/s we were aiming for. What can we do about that? The usual options are: change the gear ratio (complex for us) or use larger wheels (increasing effective gearing, is more easily acheived but increases the stress on the motors). Another solution is running the motors above their rated voltage (something thats very common in combat robots). This also increases the stress on the motors(overheating). Playing with the drivetrain calc again, we found that increasing the wheel size worked up to a point (about where the motors stopped having enough torque to wheelspin), then the overall time started to increase again:

wheel size

accleration results 1

 

 

 

 

 

 

So we can get a good improvement there but its still not quite as fast as we’d hoped for (1.2s). As expected, changing the voltage also worked but running the motors at 36V is a long way from their rated voltage.

Playing with the inputs more showed a combination of increasing the voltage and the wheel size could get us pretty close to target:

accleration results 2

 

 

 

 

 

 

24v 95mm traction limited

 

Picking the 95mm, 24V design, we can see from the graph that we have more than enough torque (we’re traction limited) for most of the time and the finish speed is pretty high at ~9m/s, much more than we’ll need for the other challenges. Since the 95mm, 12V performance still looks pretty good, we now wondered if we could run at 12V for most of the challenges, just adding the extra battery pack for the speed challenge. This would reduce weight and stress on the motors when we don’t need the extra speed. As before, we quickly mocked up a drivetrain test platform to confirm the model:

second concept

laser cut chassis

 

 

 

 

 

 

Well that looks promising 🙂 The robot is about as fast as before but it’s now much easier to fit the electronics in. Reliability seems good, apart from the occasional wheel falling off… It also has a tendency to wheelie or roll over, so we’ll have to be careful for component placement to keep the centre of gravity low or limit the peak deceleration a little. Its still a little difficult to get the robot to reliably move slowly though (like we’ll need for the proximity challenge) but now the motors are smaller, we can fit smaller wheels just for that challenge, effectively changing the gear ratio and slowing the robot down:

second concept - small wheels configuration

 

 

 

 

 

 

 

 

So that’s the drive train sorted, better get the code started now 🙂

 

Posted in Pi Wars, Pi Wars Old, Raspberry Pi | No Comments »

Raspberry Pi Zombie

November 27th, 2015

or “How I Fell in DooDoo and Came Up Smelling of Raspberries”

OK. Picture the scene. It’s late on a Friday night, and you’ve been hacking on your Pi Wars robot all evening. It’s been productive. Between you and co-roboteer, you’ve ironed out glitches in your Remote Control code, you’ve soldered up the wiring looms, and you’ve even designed and printed custom parts to mount the pi onto the baseplate you laser cut earlier. You’re robot building machines. Go you. High fives all round.

Flushed with success, you both decide to power up the pi and take it for a spin. So, you plug in the USB cable that you wired up to that adjustable 5v regulator earlier to step down the power from the lipo battery, and… uh. I’m pretty sure the activity light doesn’t normally do *that* when it’s booting. what the..? yank the power! yank the freaking power!

Welcome To Cockupsville. Population: You

facepalm

OK. wait a second. what just happened? Well, remember that 5v regulator you wired up earlier? The key word there was adjustable, Dingus. And you didn’t check it, did you? You buzzed every single other thing you soldered, but you forgot to check that the output voltage was actually, y’know, ADJUSTED to 5v. So you just sent how many volts into your Pi? 12? Excellent work. well done. Slow hand clap.

You decide to check the damage, hoping against hope that the Pi just kind of wouldn’t notice that you just rammed 12v up it’s tiny USB port and you can pretend like nothing happened. After all, no blue smoke came out, so … fine, right? Fine. Probably fine.

Except, no. Adjusting the voltage regulator to 5v (triple checked – bit late now, but whatevs) and trying to boot again does nothing. Well, not exactly *nothing*, but only some flickering of the activity light and no actual booting. Saddest of sad faces.

Alas Poor Pi

yorick

So that’s that then. You’ve fried your pi. It has gone toes up. Time to give it a viking funeral.

But. BUT. A bit of Googling seems to suggest a few things:

  1. There is such a thing as a polyfuse
  2. They can heal themselves when they’ve tripped.
  3. Actually flipping *HEAL THEMSELVES*
  4. The Pi has one on the USB power input.

So you leave it an hour and, with great hope in your dumb little heart, you plug it in.

Nothing. Just a bunch more flickering. Probing across the polyfuse seems to suggest that it’s maybe a bit better, but still a loooong way away from being useful as part of a functioning computer. sigh.

M. Night Shyamalan style plot twist

dr_frankenstein

Fast forward two weeks. You’ve nearly forgiven yourself for frying a perfectly innocent Pi. You’ve ordered a replacement and plumbed it in to your Bot, and you’re sitting at your desk idly surfing the web when you see out of the corner of your eye that poor little dead Pi, half hidden under a pile of papers. “I wonder…”, you, um, wonder.

So, you dig out a phone charger and a cable, and you plug it in. <DEITY> be praised! It’s booting. It lives! You’re like the Doctor freaking Frankenstein of consumer electronics! Except that he made a sort of patchwork quilt of chopped up people and you’ve reanimated a credit card sized computer. Same thing apart from that though. Probably.

Step aside Pi Zero, I give you Pi Zombie!

zombie_pi

So, there you have it. You too can get away with stuffing 12v into a 5v hole, if you’re very, VERY lucky. But what have we learned? Well, we’ve learned:

  • If someone gives you an adjustable voltage regulator and tells you that it’s set to 5v, don’t believe a damn word of it.
  • Stick your multimeter across EVERYTHING.
  • Raspberry Pis don’t like 12v up them, Corporal Jones.
  • Polyfuses are an actual thing. They freaking HEAL THEMSELVES, people. Insane.
  • Sometimes you can fall in the doodoo and come up smelling of Raspberries.

Posted in Pi Wars, Pi Wars Old, Raspberry Pi, Uncategorized | 1 Comment »

Technical Drawings: Interface

November 26th, 2015

Since there’re multiple people all working on different elements of the hardware, we’ve found it useful to share CAD and technical drawings describing the key interfaces. For example, here’s the latest drawing should the overall layout and the key mechanical interfaces:

piwars v0.4

 

 

 

 

 

 

 

 

Posted in Pi Wars, Pi Wars Old, Raspberry Pi | No Comments »

Getting a bit of a track record…

November 26th, 2015

We saw the pictures of the tracks for the PiWars challenges and figured the best way to test our robot was to build our tracks so we checked out all the specs and figured out a cutting list . Then we had an evening of construction.

Here’s our skittles track

Skittles Challenge

Three point turn track

3 point turn track

Speed run track modelled by Mike (left) and Rob (right)

Speed Run Track

Posted in Pi Wars, Pi Wars Old, Raspberry Pi | No Comments »

Development of the ball flinger

November 26th, 2015

So for the skittle challenge we did some thinking and testing and figured that just “nudging” the ball in the direction of the pins wouldnt cut the mustard so to speak. We needed something a tad more energetic. Resident ingenious person Mark quickly rustled up a 3d printed contra-rotating mechanism to give the bowling ball a spot more oomph!

Here are some tests

The first couple of tests used the small ramp but the ball was getting too much air so we swapped things around for the subsequent tests.

Here is another video

Things we learned from these tests:-

  • Lose the ramp. In this case getting air is not good.
  • Balance is your friend. 3D hubs and spindles are not well balanced and cause huge vibration.

It is difficult to see but the rig was difficult to hang on to once the wheels got up to speed. So we went back to the drawing board and Mike took on the task of fashioning Mk2. This time we would have steel shafts and a metal chassis. First models for the Mk2

2015-11-20

2015-11-20 (1)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The second version tidied up a bit…

 

2015-11-20 (2)

 

 

 

 

 

 

 

 

 

 

 

 

 

2015-11-20 (3)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Cutting some metal

 

2015-11-21 (1)

 

2015-11-21 (2)

2015-11-21

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

A revised hub was printed without the built in spindles to try and make it less out of balance to reduce vibration.

Mk2 Solid hub

 

The Mk2 flywheel assemblies are finished and look like this.

 Mk2 Flywheel finishedBoth Mk2 Flywheels finished

There is still quite a lot to do to make the assembly on which the flywheels will be mounted and which will be attached to the front of our robot. Here are some views of the cad of the rest of the assembly.

 

 

 

Ball Flinger Assy Cad Model Iso View Ball Flinger Assy Cad Model Side View Ball Flinger Assy Cad Model Front View

Some laser cutting for the main support arms, 3d printing for the smaller arms and a bit of metal bashing for mounting brackets. Finished off with a bit of wiring. More updates as the assembly comes together.

Posted in Pi Wars, Pi Wars Old, Raspberry Pi | 1 Comment »

Pi Wars-drivetrain

November 2nd, 2015

Speed with control

The drivetrain of the robot plays a key role in many of the pi wars challenges: success in the speed challenge, line following, three point turn, proximity alert, obstacle course and pi noon all put demands on the drivetrain to do well. Some of these demands are somewhat conflicting, the proximity alert requires the drivetrain to allow very small, precise movements, the obstacle course requires great torque and off road ability, the line following and speed challenge is about acceleration and top speed whilst the three point turn needs very repeatable, controlled movements.

 

Starting with the speed challenge, let’s see what’s needed for the best possible performance. Ignoring aerodynamic aids to increase downforce, most grippy tyres can provide a coefficient of friction of about 1. What does this mean in practice? IIf the robot weighs 1kg (or 10N), the tyres can provide a maximum of 10N of grip before they’ll slip. From F= ma, this tells us our maximum possible acceleration would be 10m/s^2, or the robot could get 10m/s (~22mph) faster every second! So what if we accelerated that fast for the whole course? what time could we finish in? There are standard equations for constant acceleration that relate time, speed, acceleration and distance. The one we need is s=ut+1/2at^2 or the distance covered is the initial speed times time plus half the acceleration times the time squared. Re-arranging and using an initial speed of 0, we get time equals (2s/a)^0.5 or, for our 7.3m track, (2×7.3/10)^0.5 or 1.2seconds! That compares quite well to last years winning time of just over 3 seconds. What does that mean for our drive train? Well, it obviously needs to be able to provide enough torque to create 10N of traction, so for 50mm wheels that would be a total of 0.25Nm (which could be shared amongst multiple motors, e.g. 0.125Nm or ~1kg-cm each for two motors). But that’s not enough to identify suitable motors, we also need to know how fast they need to spin. From our initial figures, we know that if we accelerated at 10m/s^2 for the whole 1.2 seconds, then our finish speed would be 12m/s (~30mph!). Using our 50mm wheels again, this means we need motors that can rotate at ~3000rpm. Looking at the motors on [motor database], the low gear ratio banebots look the most suitable

But there’s more to choosing a motor than just its stall torque and no load speed. we need to know the weight, size and cost. Again the banebots look ok, all though they’re a little long, we wouldn’t be able to put them side by side and fit within the size constraints. The motor cost looks ok at £xx and the weight is xxkg, both acceptable. But we’ve overlooked something: the torque curve. Whilst the gearmotor can produce enough torque at zero speed, as the speed build the torque drops off, until the usable torque is zero at the ‘no load’ speed. So our initial acceleration would be as planned, it would soon drop off. What we actually need is a motor that outs out enough power to sustain the acceleration. With a constant torque requirement, the maximum power point occurs at the end of the run, when we’re at maximum speed. Providing a traction force of 10N at 12m/s requires a power output of Fxv=120watts, much more than the small banebots motors we selected earlier. Since the torque typically decreases linearly with speed, the peak power output of DC motors is usually at half of no load is 0.5 x max torque x 0.5 x max torque. Filtering our motor database result again with this new selection criteria, we can see that the new winners are the banebots 540 motors with low ratio 36mm gearboxes. These are much bigger than the 370 size motors (~50grams) we were looking at before, weighing 150g each, making two of them possibly weigh more than some of the competitors weigh in total.

 

Again, since we’re going for the ultimate solution, let’s see if we can make them work, even if they are a bit extreme. Since these motors are actually unavailable now and used to cost $43, is there a cheaper alternative we can test with? The 550 size motors are very common in RC cars, but they tend to have gearboxes with two outputs and a differential, not much use for the tank style driving we’ll be doing. Cordless drills also use that style motor, often with an integrated gearbox and bearings. It’s for this reason they’re quite common in the smaller with classes of combat robots

Isoscreenshot2

 

 

 

 

 

 

 

The only issue is their stock gearing is a little high for what we want, they tend to come with an output speed of ~500rpm for the cheap ones, or 350 and 1300rpm for the more expensive two stage gearing models.

2015-11-26 22.39.00

 

 

 

 

 

Neither these really work for us but luckily for us the gearbox in drills tend to be two or three stage planetary gearboxes.

planetary gearing

 

 

 

 

 

 

 

 

 

 

 

This actually makes it quite easy to remove a stage of gearing, making them much faster, back to our target speed of ~3000rpm. Ok, so they’re quite cheap (~£15), they’re very powerful (~100watts) and we think we can make them fit and the gearing is about right. Lets build a test chassis and see how it performs!

Here’s the first go at a layout, using two motors and belt drive. Once the bearings and wheels are accounted for, the drivetrain take up pretty much the full with allowance but they still fit.

first layout

 

 

 

 

 

 

 

 

 

Here’s more detail added, with a battery, speed controllers and screws added. It’s starting to look a bit difficult to package the electronics, sensors etc, with the tracks taking up so much space but let’s see if the motors are as good as the look on paper.

first concept layout 2

 

 

 

 

 

 

 

 

Here’s the first printed parts starting to be assembled.

2015-11-26 22.53.34

 

 

 

 

 

 

 

 

See other blog post for details of making the tracks
And here’s some test videos:

 

So, as predicted, the drivetrain is large and stupidly powerful. But it looks like it’s a compromise too far: the other secondary requirements of the robot are going to suffer. The control electronics (pi, ADC etc) are going to be difficult to mount, the sensors and bolt-on modules are difficult but most importantly, it was impossible to make the small/slow/precise/repeatable movements required for the proximity and three point turn challenges. A future post will cover what we come up with.

 

 

Posted in Pi Wars, Pi Wars Old, Raspberry Pi | No Comments »

Pi Wars-Tracks

November 2nd, 2015

Making *working* caterpillar tracks is hard

Caterpiller tracks are well known for their utility in traversing rough terrain, so seem like the ideal choice for the assault course challenge. With the right materials they can also provide amazing traction on smooth surfaces so could be useful for the speed challenge. Many previous competitors have successfuly used caterpillar tracks so this is not a new idea but, as with many of the elements of our pi wars entry, we’d like to try something a bit new.

tracked_pryobottracks on a digger

(image courtesy of Brian Corteil)

From the motor selection blog post, we’ll need large drive wheels to meet our speed target. The large wheels will also help us climb over the obstacles so this is not a bad thing there either. Trawling ebay, model shops and robotics sites, off the shelf tracks are available but only in relatively small sizes or with hard materials, so it looks like we’ll have to make our own.

lego tracks

Making tracks from scratch usually starts with chain or other interlocking elements, then adding treads or rubber pads. Many small items are required and they’ve often very labour intensive.

3d printed tracks

(image courtesy of https://hackaday.io/project/6106/logs)

Oogoo, a new, low cost, method of makign soft rubbery items has been shared on instructables and looks promising for making tracks. So far it has been used to make some great looking robot wheels but no one has used it for competitionor fo rmaking tracks. In principle, all we need to do is make a 3d printed mold, mix up the ingredients and cast a track.

oogoo

(image from http://www.instructables.com/id/How-To-Make-Your-Own-Sugru-Substitute/)

Here’s our design for a track:

first concept

Key features:
Central rib on the inside to align the track and keep it on the rollers/wheels
Drive nubs on the inside so the drive wheels transfer their torque to the track
small paddles on the outside to increase grip when climbing steps.

To design the mold we first had to create a new model of the track in its relaxed, circular state. To make the mold design, we simply subtracted the track design from a solid block, then split it up to allow it to be removed.

round tracktrack mold

 

 

Here’s the printed track mold:

05-_MG_8715

To make the track, we first used vaseline as a release agent on the mold. Then we mixed up the cornflour and silicone sealer ingredients and spooned them onto the mold and closed it up:

01-_MG_871106-_MG_871607-_MG_8717 08-_MG_8718 09-_MG_8719

 

The main issues we had was that the mixture stuck to the spoon easier than it stuck to the mold, so it was very difficult to evenly fill the mold. The track mostly came out looking great but there are a few missing or thin patches. The biggest issue though was that the track came out too long, so it didn’t stay on the rollers:

26-_MG_8736 27-_MG_8737

But it looked promising enough to try again. The options we discussed were incorporating some form of reinforcement (string or cloth) to stop the track stretching and riding off the rollers, adding side plates to the rollers to keep the track on, or to make the track undersize such that its stretched when in place. Given the first track came out much too large, a new mold was needed either way. Given the thickness of the track, the side plates would have to be quite short or they would be the only thing touching the ground. We though it might still ride over the flanges, so We decided to start with trying the ‘stretchy’ version first. By making the initial diameter smaller, we could make the mold smaller, allowing us to print the inner mold in one piece. We hoped this would make filling the mold evenly much easier.

This time we tried something new with the molding, laying out the mixture on greaseproof paper first to try to make it more even, but otherwise the process was the same:

32-_MG_8742 39-_MG_8749 41-_MG_8751 42-_MG_8752 48-_MG_8758

This track came out better, there were less voids and it stretched nicely into place:

56-_MG_877057-_MG_8771

Unfortunately, it still rides off the rollers:

 

So we tried crowning the wheels, a standard technique for getting flat belts to stay on pulleys:

58-_MG_8772

And that didn’t work either. So it looks cool but its still useless 🙁 Watching the video again, it looked the drive nubs might actually be hindering the track staying on the rollers. As a last ditch attempt, we tried cutting the nubs off.  The track stayed on better but still not positive enough to be driven around on a grippy surface 🙁
Looking again, other tracks (large and small) appear to have a more significant centralising feature. For now though, we’re going to drop back to wheels so that we have something to start testing with.

Posted in Pi Wars, Pi Wars Old, Raspberry Pi | No Comments »

Pi Wars blog post 1

November 1st, 2015

Right, first things first: we want to win Pi Wars. We’ve got a reputation to maintain (cough *interhack space robot wars champions* cough). Ok, in reality we saw how much fun the event was last year and thought we should get involved. But whilst we’re at it, we may as well do as well as we can. So this first post is our first look at the different challenges and how the scoring is calculated, so we know what we need to do, where to concentrate and what sort of compromises we might need to make on the robot design.

The challenges:

  • Skittles (maximum 180 points, new event)

This is a classic game of skittles with the robot launching the ball. An additional ‘ball firing device’ is allowed, so it looks like it’ll need consistency in speed and aim. Sensors may need to detect the ball and the pins but there are no bonus points for doing it autonomously. It also looks like there might be a fair bit of luck involved in the event that can potentially provide the most points hmm….

skittles

 

  • Obstacle course: (maximum 105 points, (assuming 6 obstacles as last time)

Last year this involved driving around a serpentine course with various obstacles, mostly with rough or angled surfaces but this year will be an all new course. We assume it will still require manouverability, traction, ground clearance, speed and control. Sensors probably won’t help (gyro for handling?) as its an RC event.

Assault-Course

(image courtesy of ChrisHannam.co.uk)

 

  •  Straight line speed (maximum 105 points, returning event)

A simple 24foot dash from a standing start, with extra points for autonomously avoiding the two side walls. Speed and control required, with sensor(s) to detect the wall and possibly wheel speed/position.

 

  • Pi Noon: (maximum 55 points, assuming 3 rounds, new event)

This is a new event, all we know is that we need the robot to be able to support a 3mm rod on the front or back. We assume it will be some sort of duel that requires speed and manouverability. It’ll be under RC control, so we better practice our driving.

 

  • Three point turn: (maximum 70 points, returning event)

This event involves driving a precise pattern and returning back to the starting point. Speed helps but its mainly about control as there are bonus points for finishing in the starting box. We’ll definitely need sensors that can detect the key marker lines and or/wheel position, robot orientation and position.

 

  • Line follower: (maximum 65 points, returning event)

This is a classic robot challenge, who can follow a black line the fastest around a course. Like the straight line speed test, this will be about speed and control, with the sensors needing to reliably detect the line and having a good algorithm for maintaining speed and the correct heading.

 

  • Proximity alert: (maximum 55 points, returning event)

This returning event is quite unusual for a robots competition, its which robot can stop closest to a wall. This is about having very fine control of the robot and a precise sensor.

 

  • Aesthetics: (maximum 40 points, returning challenge)
  • Build Quality: (maximum 40 points, returning challenge)
  • Blogging: (maximum 40 points, returning challenge)
  • Code quality: (maximum 30 points, returning challenge)

 

So in summary, we need a drive train that’s fast and controllable and can take us over and around obstacles, we’ll need sensors to detect lines, walls and possibly orientation, and some way of firing a ball accurately at some skittles.

 

Posted in Pi Wars, Pi Wars Old, Raspberry Pi | No Comments »