Is this the cause of P21’s dodgy wheel?

Up close to P21’s back right wheel encoder

P21 has had a dicky back wheel since it fell off the roof during filming of the Obstacle Course for PiWars at Home. The motor runs, but the speed is not well controlled, so I assume the problem is related to the encoder.

After the competiton I dismantled the back axle, reseated the connectors, and all seemed to be fine again… for a while.

But recently I’ve been testing a new game for the Sidmouth Science Festival and was frustrated to see that the robot was quite unreliable when aligning on the game pieces. I set to re-tuning the vision system, because that’s always the source of any problems, isn’t it? But this time that didn’t really help.

Finally I realised the robot was sometimes dragging it’s back wheel. I dismantled the back axle again (which is too fiddly and frustrating) and removed the motor.

I see that one of the encoder Hall sensors is leaning out from the magnetic wheel on the motor; see above. Hopefully this is the real source of the problem. I suppose this is due to the fall, but it’s hard to see how.

My plan is to re-print the lower half of the back axle (since it is damaged), re-align the Hall sensor, then put the whole thing back together… But I think I will swap the offending motor with one of the front ones; I really dislike rebuilding the back axle!

Sidmouth Science Festival

Each year, Sidmouth (in the southwest of England) has a science festival.  This, year it takes place between the 8th and the 17th October 2021.

We like to go to the festival for the rocket car contest. If you’re an avid follower of our blog, you may recall that our entries won the rocket car contests in 2017 and 2018; see this blog post.

This year, on the 16th of October, there is to be a robot workshop where families can build, drive and code robots.  We have agreed to demonstrate P21, probably doing a derivative of the Tidy Up the Toys challenge.  However, we decided to make some changes to the robot (and a new arena) first:

  • The TUtT gameplay will change.  The arena (which I hope will be on a tabletop) will have a robot parking bay at one end and a “stack zone” at the other.  People will be able to place the blocks in the arena, then press a go button (either P21’s existing start button, or perhaps one on the arena).  The robot will collect the boxes and re-stack them in the stack zone.  Possibly there will be a P21 camera view displayed on a monitor somewhere.
  • The end zones on the arena will be coloured so that the robot can use them to localise.  We will use walls to stop the robot from falling from the table; the walls will also be coloured so that the robot should be able to avoid them visually too.
  • We may use barrels instead of boxes since they have the same width from any direction; this means the robot can approach them from any direction to lift them too.
  • We might take a look at P21’s headlights.  We don’t know what the lighting is like in the demonstration venue; it would be a good idea if P21 could provide it’s own illumination of the game arena if required.
  • Finally, we’ll update the start-up and shut-down procedures for the robot; SSH-ing into the Pi to do a demonstration is going to be too slow!

So, if you find yourself near Sidmouth on October 16th, come and say hello!

The Results

The waiting is over; the results of Pi Wars 2021 at Home have been announced. And I’m delighted to announce that we won the Advanced Category!

Here’s a link to the results, the videos we submitted for our entry and some extra videos that were made by P21’s camera as the robot performed the challenges.

All that remains is to say a huge thank you to Mike, Tim and Dave for organising another wonderful event. And another thank you to those that judged the (several hundred!) videos.

As a family we really love taking part in Pi Wars. We really hope there will be another competition, and that it can be in person too!

The Bad News & the Good News


First the bad news: we may have been too ambitious when filming the obstacle course. PiDrogen has taken a significant tumble and is now in “dry dock”. I can’t tell you what happened right now (you’ll have to wait to see the out take at the end of our obstacle course video at the competition), but it was from a substantial height!

Now the good(ish) news: we rarely dismantle PiDrogen’s back axle, it’s too fiddly. But one of the motors is stuck on full power so there’s no choice. So here’s a rather rare picture inside it…

Inside P21’s back axle

To be honest, I’m amazed there wasn’t more damage.

The Obstacle Course

Yikes!  It’s June.  18 days left.  Better get on with it.

When we record the obstacle course, we plan to be running PiDrogen’s recording strategy.  This records a video from the robot’s camera and marks it up with various information, a bit like a Head Up Display (HUD).  See below.

The HUD reports the heading of the robot (assuming it was booted facing due North, measured by the IMU), the pitch and roll angles (also from the IMU), the battery voltage, and the forward speed.  An artificial horizon is used to represent the pitch and roll angles.

The plan is to submit an uninterrupted video from a phone (as required in the rules) but use snippets from PiDrogen’s camera as a picture-in-picture.

When the software was written, the maximum speed of the robot was estimated (i.e. not measured) at 1.9ms-1.  But when I thought about it, covering nearly two metres per second seems pretty quick.  I thought I should check my facts before submitting any videos!

The speed estimation was based on the following data:

  • The motors are rated at 350RPM at 12v with no load.  However, the robot uses 4S LiPos which deliver between 16.8v (fully charged) and 12.4v (when the battery protection circuit shuts down).  For the calculation I made the assumption that the motors would still rotate at 350RPM when driving the robot (i.e. under load) due to the additional voltage.
  • The obstacle course wheels are 104mm diameter.

So, the estimated speed = 350RPM x 104mm x π / 60 = 1.9ms-1.

Today we measured out a 5 metre course on our drive and timed the robot driving the length of the course at full speed using fully charged batteries.  We took four measurements, two in each direction (since the drive isn’t quite level).  The measurements were taken by hand (so are not likely to be particularly accurate), so were recorded to 0.1s accuracy.

The times measured were 2.2, 2.8 2.6 and 2.9 seconds.

The average time is 2.6 seconds. 5 metres in 2.6 seconds equates to a speed of 1.9ms-1.

Cool, the estimate was right!  That’s satisfying / a relief!

YACA5 Update

Sorry!  I forgot to update the blog on the new catapult arm. (See my previous blog entry).

Sadly, it didn’t make a difference on the Feed the Fish game.  But I’ll explain it anyway.

Nerf Rival balls are obviously made with a mold which has two hemispherical parts.  It is clear to see the seam where the two parts come together.  The balls also have dimples like a golf ball.  YACA5 has slots so that the ball seams can be aligned with the flight path.  I wondered if aligning then might make them fly more consistently.

As I said, it doesn’t.

However, I have realised that not all Nerf Rival balls are born equal.  I test fired 40 balls 10 times each.  Some balls were on target 10 times.  One ball only flew correctly 4 times out of 10.

Perhaps the best hint I can give here is this: test your balls and pick the best!

Yet Another Catapult Arm

I’ve fallen into the trap of searching for the Holy Grail of Feed the Fish: that is 15/15 shots.  I’ve done so many “takes” that the course has gone darker (from tyre rubber) where the robot makes a right-angle turn to line up on the aquarium! 

This is my latest attempt at designing a more reliable catapult arm which I will call YACA5:

Yet Another Catapult Arm V5

If it works, I’ll explain it in another blog post.

Wish me luck!

Take a look at our Aquarium!

I’m rather proud of our aquarium. Here’s a picture:

iPads need less cleaning than real fish.

It is a 3D printed frame into which you can slot two (or three) iPads.  The red circle on the bottom is a target for the robot to align on.

The outside of the box is the regulation 200mm, but the hole in the top is rather smaller (because of the thickness of the iPads), but I reckon it’s worth it!

It’s a proud Dad moment: my eldest son (who is also the team driver) created a Scratch animation of the fish swimming about.  We then captured video of it running on a PC, did some Python reformatting of the video to make it full screen in portrait mode, then used to convert it into a gif.  We can open the gif in photos app, then the animation cycles forever.  Just the job for doing dozens of takes while trying to get 15 out of 15 shots!

Here’s the gif for your entertainment.

Well fed fish

Testing the new Catapult

I built the new catapult (that I talked about in my last post) and tested it.

Immediately I could see many of the improvements that were expected of the new design:

  • It is easy to adjust.
  • It fires straight.
  • The turntable moves as expected (+/- 30 degrees).
  • The new design is much easier to install on the robot.

However, I found that it was still too inconsistent.  Specifically, the energy stored in the system would gradually decrease as the catapult was used for many shots.  Initially I imagined that the rubber band was stretching and becoming weaker.  But then I realised that the band was slipping along the catapult arm.

So here is the new design for the arm.  It now incorporates a hole for the band to pass through so that it can’t slip along the arm.

Catapult arm (version lost count).

I also found that there was insufficient travel in the trajectory adjuster.  I went for the very high-tech approach of gluing on a piece of Lego to fix that:

Catapult with Lego “tweak”.

This new (dare I say final) version is now yielding much better results.  I’m optimistic it will achieve close to 15 out of 15 shots!