Having built a pair of working prototype rocker bogie wheel assemblies, I turned my attention to the main body of the rover. Initially I just used a simple box shape, keeping the front of the chassis well back from the front steerable wheels to avoid collisions. The rear of the chassis had to overlap the area where the rear steerable wheels servo links came under the body in order to fit the top pivot for the linking bar assembly. But I now had a basic chassis design which enabled me to complete my CAD model and see a working mechanical model of the full rocker bogie suspension.
A rendered animation of the rocker bogie suspension
To avoid the rear wheel steering links colliding with the underside of the body, I modified the box so that the bottom was shorter than the total length of the body. This gave the servo steering links more clearance where they passed under the body. I made the front section of the body just long enough to fit in the Raspberry Pi 3 plus two additional support pillars to provide a second pair of holes for the main pivot bolts to pass through. This gave a more rigid main pivot axis assembly than if the bolts just passed through one piece of 3mm sheet material on each side.
I mounted the Raspberry Pi 3 board in the box, with the USB and Ethernet ports poking through a cut out. This was technically the first Raspberry Pi case I had ever designed. The rear of the box still needed to extend far enough back to support the linking bar assembly on the top. To allow this, the base of the box stepped up to a lesser depth at the rear.
The body design with a step up on the underside at the rear
to allow the steering links to pass underneath the chassis
At this stage I was still pondering over how to build the linking bar assembly. I had modelled a bracket to hold the horizontal linking bar, which I was going to have to 3D print. I also needed to solve how to attach fittings to the ends of the cylindrical bar to link to the rocker arms. At about this time, somebody posted a picture of the NASA Mars Curiosity rover in a lab in reply to one of my progress posts on Twitter.
Image Credit: NASA/JPL-Caltech
Up to this point I had not realised how large the real Mars Curiosity rover was! But I also noticed the linking bar was a flat bar, not a metal rod as I had modelled based on the JPL educational scale model project which inspired me to design a Pi Wars sized version of my own. That looked a lot easier to build. The picture also gave me another revelation. I did not need to mount the bar on the back of my rover. It could go in front of the main pivot axis of the body. This gave me more room as the body already extended further out in that direction to accommodate the Raspberry Pi. It also better distributed the weight of the body between the horizontal pivot axis and the top mounting point for the linking bar.
I now had a complete design worth building a prototype of. I laser cut it all from 3mm plywood because this was cheaper than plastic, easier to modify with small tools after cutting the pieces and I could re-purpose all the off-cuts and waste pieces as kindling to light the fire at home.
My first prototype, almost fully assembled (one rocker bogie arm is attached here)
This first mechanical prototype enabled me to verify that the design worked in practice. It also allowed me to test how much motion was possible in the rocker bogie arms before the rear steering legs collided with the underside of the chassis. I was not sure there was enough range of movement, and it also made me realise the weight was not well balanced around the main pivot axis of the chassis. I needed to think about how to solve these problems, and also work out how to fit all the electronics and a power source into the body.
Using my newly learned skills in CAD and laser cutting I started to build the rocker arms for my robot. I was pleased with the way my servos fitted into the arm, but concerned that using the servo itself as the only mounting point for the steering leg was not going to be strong enough. That tiny screw attaching the horn to the servo just did not feel like it would handle all the strain put on the robot leg.
My first prototype steering leg assembly
I had only attached one leg to the first part of an arm and already I was needing to redesign. Some browsing of possible bolt styles I might use online led me to shoulder bolts. These have a solid cylindrical section (the shoulder) with a short threaded section on the end. I redesigned my leg and arm ends to attach the leg using a long shoulder bolt as the axis. A nylon spacer provided the required separation of the leg from the arm. Moving the servo along enabled me to attach the servo horn to the leg via a hinged link. The shoulder bolts were also perfect for the other pivots in the rocker bogie arms. So with the entire arm remodelled in my CAD software I was ready to assemble a complete version.
My first attempt to put it all together in laser cut 3mm plywood proved that the design would work, but I could not fit the nuts onto the small bolts which held the servo mounting plates in place. I had not left enough room for the nuts to fit alongside the spacers on the pivot bolts. It was at this point that I discovered the collision detection feature of the CAD software and sure enough it highlighted the problem in my CAD model. Lesson learned I made some more adjustments and was finally able to build and assemble a complete pair of rocker bogie arms.
The same week I learned I had got into Pi Wars 2019 I also managed to grab a place on a training session for the laser cutters at MakeSpace. These were the machines I had primarily wanted to use to make my robot when I joined MakeSpace and now I had done the induction I just needed to work out how to convert my CAD model into a file format I could use on the laser cutter. Or so I thought.
The first problem was how to turn a 3D model of a part into a 2D outline for cutting. I was using SolidWorks CAD software and this has a drawings feature where you can generate 2D engineering drawings for different views of the parts and assemblies you have modelled. These drawings automatically update based on any changes you make to the modelled parts, which is very handy. But the file format for SolidWorks drawings is not supported by the software which the laser cutter uses. So the drawings had to be saved in a intermediate format which can be imported into the laser cutter software. Initially I was doing this directly as DXF format. A simple 'Save As' from SolidWorks to create a file I could import into a laser cutter project.
I cut the parts of one of the forward arms of my rocker bogie suspension which needed to hold a servo, and the parts assembled around the servo perfectly. It was all going very well.
Cutting my first parts on the laser cutter
My assembled servo mount
The servo fitting snugly in the mount
Next I cut the parts for a steering leg, and while they went together without any difficulty, there was a lot of play in the plate holding the motor. I started to think about the tolerance of the parts I was cutting and I soon had a lot of questions which I needed to learn the answers to. I had modelled my parts in CAD software to the exact dimensions I wanted them. But clearly when you cut them out with any sort of tool some material is removed by the cutter (in my case vapourised by a laser, but the same applies to a saw where some material is removed by the blade). Thanks to the maker community on Twitter I learned that the width of the cut produced by a tool is called the 'kerf'. Once I knew that I was able to search online and learn about offsetting (adjusting for the kerf). If I modelled a part to be 30mm wide then the drawing output from my CAD program defined a part which was 30mm wide. But when I cut this on the laser cutter the resulting part was only around 29.8mm wide due to the kerf. This was not so significant for how the part looked, but my tab and slot fittings were just a little loose fitting due to this.
There appeared to be 3 approaches people suggested:
Specify an offset in the CAD program.
Offset my drawings in a 2D drawing program after exporting them from the CAD drawings.
Specify offsets in the laser cutter software.
I also realised that I needed to consider the sizes of holes for my various bolts and screws. I had used a 3mm hole size for an M3 bolt in the CAD software. But if I wanted a freely rotating M3 bolt without excessive wobble then 3mm was not quite right. The hole needs to be slightly larger than 3mm, but the kerf will mean a 3mm circle will be cut slightly larger. So what size circle does the laser cutter need to be given to get a hole just the right amount larger than 3mm for the bolt to fit freely but not too loosely? I also discovered that the offset features in some CAD software were not present in SolidWorks. I think this may be because while a hobbyist might be happy to apply offsets to their drawings where they are cutting parts themselves, a professional using a 3rd party to do their cutting does not know the kerf settings of the cutter to be used, so they leave it to the cutter operator to apply.
So for me there was no option 1. At the time I did not know whether option 3 was possible in the software on the MakeSpace laser cutters either. So I went for option 2, applying my offsets in a 2D drawing program. Various articles online pointed to using an offset feature in Adobe Illustrator. But I did not want to buy an expensive 2D drawing program when free alternatives were available. My go-to free 2D drawing program is Inkscape. This has a feature on the Path menu to Outset or Inset a shape. But this appears to apply a hard coded offset amount and distorted the shape of my parts adding curves to angled corners.
A part with lines outset/inset using Inkscape
(original outline in black, outset/inset lines shown in red)
(the largest circle on the right side is 6mm diameter)
Inkscape also has a feature called Dynamic Offsets where if you select just a single outline and then choose the Dynamic Offset option on the path menu (or Ctrl+J) then you get a drag handle and can adjust the line offset by hand. By duplicating each line I could manually offset it by approximately the line width (setting the line widths to the amount I wanted to offset them. There was still a little distortion of the shapes, but these were insignificant for the amount of offset I needed.
A part with dynamic offsets applied by hand in Inkscape
(original outline in black, offset lines shown in red)
This enabled me to explore different amounts of offset and cut some parts to see what amount of adjustment gave me the right fit. But having to adjust every shape by hand dynamically was time consuming. It also made me realise that I needed different offset settings for different aspects of my parts. My 6mm shoulder bolts used in various pivots between parts needed a different amount of adjustment of the hole size than the machine screws holding parts in fixed positions, which was different to the slots cut to take tabs on the edges of other parts.
I think perhaps option 3 (specify offsets in the laser cutter software) is preferable in the long run, but would require me to adjust all my hole sizes to include some aspect of hole size adjustment. (If I want a 6mm shoulder bolt to rotate freely then I want a slightly larger hole size than 6mm. I should model that hole size in CAD so that when I apply an offset for kerf in the laser cutting software the resulting hole is cut to exactly the size I modelled in the CAD software). At this point I asked a friend at work how SolidWorks recommend doing this, and he pointed me to the free version of DraftSight, as 2D drawing program from Dassault Systemes (who also own SolidWorks). Draftsight features an offset feature which allows you to specify the offset amount numerically. So I developed a workflow to manually apply offsets of different amounts to my various drawing parts using DraftSight.
I discovered that importing DXF files into DraftSight resulted in curves being converted into short sections of straight lines. So my nice rounded edges became jagged. This was avoided by exporting the drawings from SolidWorks as DWG format files. These can be read by DraftSight without converting the curves. I then had to weld all the line segments back together into single outlines for each part in DraftSight. Then I could apply a single offset to the entire outline of each shape (rather than to each line segment individually). Finally I exported the drawing in DXF format to take the file into Inkscape.
At this stage all my shapes have two lines for each feature of a part. The actual CAD drawing outline and the offset outline I want the laser to cut along. In Inkscape I coloured these cutting lines red, leaving the original lines black. That way I could easily verify which offset I have applied and that it is on the correct side (outside for the outlines of parts, and inside for cut-outs/holes in the part). The final step was to save the coloured drawing with offset lines in DXF format and import this into the laser cutter software, telling it to not cut the black lines, and applying cutting settings to the red lines. I was also able to add text to engrave into the material in Inkscape in a 3rd colour if needed and apply settings in the laser cutting software to engrave the shapes outlined by lines in that colour.
At last I was able to cut out parts on the laser cutter which were exactly what I had designed in my CAD model, and start to build my robot.
When the Pi Wars robotics competition announced the 2019 event with a space theme, it was clear that the various NASA mars rovers would be a source of inspiration for many potential competitors. I saw a few mentions of Rocker Bogie suspension on Twitter in connection with the competition. I had not heard this term before so I looked it up online. Wikipedia had an article with an animated graphic which had a caption saying it was not actually correct. I was intrigued, but still not sure what it was. I had my balance bot idea and felt that submitting an entry which was just saying I would build a mars rover inspired robot probably wouldn't make the cut for Pi Wars 2019. So I dismissed the idea at the time.
What changed my mind was the publication by JPL of an open source educational model of the Mars Curiosity rover with full build instructions. Their website has a nice animation of their model rover which shows how the rocker bogie suspension really works using a differential pivot (link above: click on the rover to switch to the engineering model and then click the hotspots on the model). It looked like a really interesting build, and felt more likely to succeed in the Pi Wars competition than my balance bot idea. So I based my application on the idea of shrinking the design down to fit within the Pi Wars competition limit stated in the rules.
In the month leading up to the submission deadline, I had started to learn CAD software for the first time. By the entry deadline I had modelled a steering leg from parts which could be cut from 3mm acrylic sheet.
I included this picture in my application. This is what I wrote on my application form:
My plan is to design and build a 6 wheel drive rover with full rocker-bogie suspension. The design should be able to turn on the spot, and drive over uneven terrain while keeping all 6 motor driven wheels in contact with the terrain. I have seen that the most common good performing design for a Pi Wars robot is a standard 4 wheel drive rectangular chassis, but I saw so many of them at the event last year I felt there should be more variety. So I was looking for ideas for something that would be more visually and mechanically interesting. After several months of trying to build a 2 wheeled balancing robot, I have learned a great deal, but also realised this is probably too big a step for my first entry attempt. I’ll never have the time to learn all the computer vision and autonomous driving code if I stick with that plan. So I decided to embrace the Space Exploration theme. After discovering the JPL Mars Rover open source design I am working on designing a scaled down A4 footprint version which I plan to build from acrylic, using the micrometal gear motors and moon buggy wheels as used on the Coretec Robotics Tiny 4WD robots. My aim is to build something visually exciting and mechanically interesting using affordable components. Other components I have bought (but not learned how to use yet!) include a PixyCam2, and a brushless motor and ESC with a view to build a Nerf dart firing mechanism.
To my delight I got a place in the 2019 competition. Now I had a lot of learning to do. I joined Cambridge Makespace in order to learn how to use a laser cutter and start working on turning this idea into reality.
In my previous post I described the problems my initial attempt at coding a balance bot ran into. Specifically the vibrations or shockwaves from the motors turning on and off swamp the accelerometer readings in noise. So instead of measuring the direction of gravity acting on my robot, the accelerometer is measuring the accerleration forces of these shock waves through the chassis. The robot just vibrated noisily and fell over because I could not measure angle of tilt of the chassis this way. Then it shot off across the room lying down. This second aspect was more concerning initially as it risked damaging my robot. So I dealt with that first.
Once the robot had toppled over, the motors are not able to right it again. There is an angle of tilt beyond which gravity wins over the power of the motors I have. At less steep angles of tilt the robot tries to drive at speed across the room, attempting to get the wheels back underneath the centre of gravity of the robot. I did not know exactly what angle the robot was unable to recover balance beyond, so I just picked 45 degrees from vertical as a starting point (I can tune this value later when I have the fundamentals working). If the robot was tilted at an angle of over 45 degrees from upright, then I set the code to keep the motors off. That way the drive is automatically off if the robots is lying down, and turns off pretty quickly when it falls over.
Now I just needed to work out how to effectively measure the angle of tilt using the IMU when the motor vibrations mask this information read from the accelerometers alone. My IMU is a 9dof chip (that's 9 degrees of freedom). These come from 3 sets of sensors each of which is measuring along 3 orthogonal vectors (x, y and z axes). We've already talked about the accelerometer (measuring changes in directional forces acting on the chip). The other 2 types of sensor are magnetic field strength, and gyroscopic. The gyros measure the rate of rotation around each axis. If we know how fast something is rotating and we measure this for a short enough time interval (so that the reading we take represents the average over the whole time period) then we can work out how many degrees we have rotated during that time. This allows us to work out the change in tilt angle of our robot since we last knew the angle of tilt, so we can update the angle in our code.
I found example code doing this where the time interval was stored in a constant for their program, based on how long their code loop took between readings. But this appeared flawed to me as what if the code in my loop varied in how long it took to run? So instead I just captured the time just after taking a reading, and then on the next reading I could work out how long had elapsed since the last reading. If you mount your IMU chip so that one of the 3 axes is parallel to the axle of your balance bot wheels then you only need to read one of the 3 axes of the IMU gyros. So with this code we can determine how much our robot tilt angle has changed in the last loop cycle. To work out the actual angle of tilt we also need to know what angle we started at. The gyros cannot tell us this, so we need to use the angle calculated from the accelerometers first. This is OK as long as we read this when the robot motors are off and the robots is not being knocked about. The perfect time is when the robot is being tilted upright to start with, or it is lying down with the motors off not moving at all.
My code design so far is structured as follows.
The loop is timed at the start. This means the first time around the loop the calculated time elapsed will be wrong, but we don't use it on the first pass round the loop so that does not matter. By the time we start reading the gyro we will know now long we have been in the loop.
We start in accelerometer mode, and stay in that mode until we get stable tilt readings. This ensures we know the true tilt angle read from the accelerometers while the robot is stationary.
Once we know the tilt we can switch to gyro mode. By this time we have been round the loop more than once, so the time elasped calculation is correct for the current loop iteration. We use it to work our how much we rotated according to the gyros in that time.
We add/subtract the amount of rotation since the previous loop iteration from the tilt angle we last calculated, to update it to the new tilt angle.
Initialise:
Set measure mode to Accelerometers Initialise last loop time to zero Loop: Get the time now Calculate the time elapsed since last loop iteration (time_now - last_loop_time) Update last_loop_time = time_now If Measure mode is Accelerometers: Calculate angle of tilt measured from the accelerometers
If angle is very close to last measured angle: Switch measure mode to Gyros
Else (measure mode is gyros) Read rate of rotation around axis of wheels (using the gyro) Calculate how far we rotated since last tilt calc (degrees rotated per second * seconds elapsed)
The psuedo-code above hopefully explains the basic approach, but there is a problem with it. Once we switch to gyro mode, we only ever calculate tilt based on the previously calculated tilt. So any inaccuracy in the measurements can result in the calculated value drifting from the actual tilt angle. Only a small amount of drift will cause the robot to try to maintain an angle different to the perfect balancing angle, and the only way to keep that angle is to keep moving. So the robot will quickly start to head off at speed across the room. Now we are driving the motors we cannot rely on a precise reading from the accelerometers, so how do we correct for this drift in the gyro calculated reading?
I get a lot of help from fellow makers on Twitter, and in this case extra credit must go to Keith's Pi Tutorials for pointing me at the following resources. The problem of determining when something is level against the background vibration of motors is the same for autoleveling flying drones like quadcopters. Keith pointed me to the following website http://www.brokking.net/yabr_main.html which in turn links to a couple of tutorial videos on YouTube on autoleveling quadcopters. The first video is here and links to part 2 in the comments:
After thinking and playing with these ideas I realised that while the quadcopter example is having to level in 2 directions (pitch and roll), our balance bot case is much simpler. We only need to consider one axis of rotation, the axis of our wheels axle. Our robot only needs to rotate around this one axis to self balance. The technique in summary is to mix a small amount of the tilt angle calculated from the accelerometers alone with the tilt angle calculated from the gyros. The accelerometer calculated tilt values are very noisy, but over time their average represents the constant force of gravity. So mixing in a very small amount (~0.05%) to the gyro readings does not throw off the calculated tilt significantly, but it is enough to correct for the drift in the gyro readings over time.
With this knowledge I was able to get some initial code working which gave me a reliable tilt angle whether the motors were on or off. I was able to start experimenting with PID tuning next, but that will have to be another post. What I had realised was that this was going to take me too long to perfect for my first Pi Wars competition entry, and another idea had come along which looked much more suitable for my submission for a place in the 2019 competition. We'll look at this in my next post.
I've always wanted to build a self balancing robot, and I thought it would make a very visually interesting Pi Wars competition entry. Some searching online and some pointers from members of the maker community on Twitter led me to a number of projects on YouTube with links to blog articles and code. But all these examples seemed to be of the 'recipe' format. By this I mean they contained detailed instructions to build the exact same robot as the author, using the same parts. Then just deploy the provided code (mostly onto an Arduino) and VOILA! A self balancing robot. If only things were that simple.
I didn't just want to build someone else's project. I wanted to understand how it actually worked, and build my own robot using the components I had. I wanted to understand the theory and the code so I could design my own. So I started to dig deeper into one of the examples. I learned that the feedback from a tilt sensor is generally processed by a PID algorithm to control the power and direction of the motors to try and maintain an upright position for the robot. It all sounded simple in principle. Use a sensor to measure the angle of tilt, feed this value along with the desired angle of tilt into a PID controller library and apply the output to the motor drivers.
So what is PID?
Before you Google it and find the page on Pelvic Inflamatory Disease, we are talking about a PID Controller, or Proportional Integral Derivative controller. You might find the Wikipedia page of interest. There is a PID controller library available for Arduino, and the author Brett Beauregard has written a series of very detailed blog articles about the theory. Here I will just talk about the usage of his library for a balance bot. In simple terms, you keep reading the angle of tilt between your robot and the force of gravity. On each loop through your code you feed in this measured angle, and the PID Controller calculates a power value to apply to the motors to bring this angle closer to the desired angle. For a stationary balancing robot, we want the robot to be upright and the motors off. If the robot is starting to topple over then the angle moves away from this desired upright angle and power is applied to the motors to restore balance. The greater the difference between the actual measured angle and the desired 'upright' angle, the more power is needed to allow the motors to restore balance. But too much power and the robot is tilted over the other way. So the PID controller constantly needs updating with the current tilt, and needs to apply a new correction to the motors.
The PID Controller also takes 3 input values which control the output for different changes in input over time, and these need to be tuned to make a stable robot. These tuning constants are referred to as Kp, Ki, and Kd. I was pointed to this video which demonstrates the effects of different values for these constants.
Most of the example code I came across supplied values for all 3 constants. But I learned that these values depend on the physical characteristics of your robot. How heavy is it, and how the weight is distributed. How fast your motors are and how much torque they generate. So there are no 'magic values' you can just use. You need to tune your own robot once you have built it. So we had better look at what I actually built.
A Self Balancing Robot Development Board
To prototype and build a proof of concept you don't need a bunch of fancy machinery and a workshop. I started with a sheet of plywood from my local DIY store, a hand saw and the patio table in the garden as a workbench (so I didn't need to sweep up my mess!).
In my parts boxes, I already had the following:
An Arduino UNO.
A pair of Adafruit motor driver breakout boards.
A set of PiBorg motors and wheels.
A Sparkfun 9dof IMU breakout board
I had no idea what sort of motors I needed so I took the approach of just trying out what I had to hand first, before going out and buying something I possibly didn't need. Here is what I built.
I simply cut a rectangle of plywood, and bolted everything on. I used cable ties to hold the batteries in place. The physical build did not take long at all. You can use any motor driver boards which can handle the stall current of your motors (this is now much current the motors will draw if they are powered but are prevented from turning). I used the example code from the IMU board I had to read the angle of tilt from vertical using the accelerometers. In my case, the angle was 180 degrees when the robot was balancing upright. Using this information I just needed to use the PID library to calculate the motor power needed to maintain balance, in a loop so it constantly updates based on any change in the tilt value. I am not going to give the full code here, but instead try to explain the principles I was using. We'll look at some actual fully working code in a follow up post.
The PID Controller takes the following inputs:
PID pid(&input, &output, &setpoint, Kp, Ki, Kd, DIRECT);
The variable names with & in front indicate these are pointers to the variables in my Arduino program. So any changes made to their values anywhere in my program will be available to the PID controller code. I wanted my robot to maintain a tilt of 180 degrees, so my setpoint value was 180. Kp, Ki and Kd are the tuning constants I needed to set to appropriate values for my robot. Input is the value of tilt I was reading from my accelerometer, and output is the power and direction I needed to run my motors. The PID library needs to know the range of values I want my output to range between, so I also had to setup the PID controller with this information:
pid.SetOutputLimits(-100, 100);
So now the PID controller knows my motor output values need to be in the range -100 (full power reverse) and +100 (full power forwards). In the main program loop, I now just needed to read the tilt from the IMU, run the PID Controller calculation, and apply the output power to my motors. Or so I thought. It turns out there are a number of complications I had not taken into account (and which the example project I was trying to follow did not use). What actually happened when I turned it on was that my robot just vibrated very loudly and fell over. Then once it hit the floor it shot off across the room with the top of the board scraping along the floor!
It turned out that the motors were put into full power forwards, which generated a shock to the IMU making the accelerometer read a very high value. This cause the PID controller to put the motors into full reverse, causing an opposite direction shock to the board. This repeated on every iteration of the loop. So the motors alternated between fast forward and fast reverse. The whole thing was shaking, causing the buzzing sound and the tilt values being calculated were not related to the angle of tilt of my robot at all, but to how hard it was being shaken by the motors.
At the time I did not understand what was wrong, so I posted my failure on Twitter:
Finished my first #PiWars hardware test platform and wrote Arduino code for balancing. It completely fails to work! Vibrations from the powerful motors changing direction shakes the accelerometer so much it cannot provide useful angle of tilt data. It just shakes violently. pic.twitter.com/4WL7ZynsL8
Pretty quickly got some great pointers to more information. Clearly I had more reading to do. In my next blog post I will explain how these problems in my initial design were solved.
As I already lead a code club and volunteer at youth groups to give Raspberry Pi and robotics workshops, it makes sense for me to get involved with mentoring school team entries for Pi Wars. This may prove to be a distraction from my own plans for a Pi Wars entry, but I expect it will actually focus my thinking on design and building robots. I am sure it will also expose me to a great level of creativity and ideas which will benefit my own entry. My daughter was inspired to enter the Pi Wars 2019 competition after attending the 2018 competition as a spectator, and originally the plan was to encourage her to put in an individual entry. But then she got one of her school friends interested and I had two children wanting to work on an entry. So I contacted their school computing teacher to see if they were interested in running a school team entry (or multiple teams). Their teacher was very interested in the idea, and I am now tasked with preparing and giving a school assembly on Pi Wars early in the new school year (with around 20 days remaining to get entries in).
Over the school Summer holidays I have been working with my daughter to guide her and her friend to start building a robot chassis and writing some Python code. We chose Lego Technic and a tracked tank like design. This enables rapid prototyping and learning a lot about the mechanics of building a working tank chassis.
A highly successful evening coding her #PiWars robot. We hacked the holiday cottage, borrowing the DVD player HDMI cable to use the TV as a screen to debug network issues & borrowed the AAA batteries from 2 remote controls for the @ThePiHut game controller. pic.twitter.com/qbMSci0o5q
We had a lot of fun building the chassis over the holidays, and took it all away with us to work on while on our Summer family holiday.
We created a state table for the controller joystick positions and what the motors should be doing for each combination. Then wrote some pseudo code encode the design ready to convert to Python for her #PiWars robot. #STEM#GirlsInStempic.twitter.com/eibix6lOcF
We used a state table to design what she wanted the motor control code to do in response to different positions of controls on a game controller. This was a great success in coaching her to create a design, and then realising that design in code. My daughter was really engaged with the project and it has kindled a desire in her to learn Python. After the holiday we visited our local library and she picked out two childrens 'Learn Python' books which she has started to work through at home. A very successful start and a great example of how a project like a Pi Wars entry generates the drive to learn new skills and overcome challenges.
Now I need to overcome the challenge of giving an assembly at my daughter's school to inspire other children to enter the competition this year.
