Average Ticker

AverageBot Devblog 4 – Code, Upgrades and Issues

AverageBot with Average-Claw attachmentAverageBot with the new 'Average-Claw' attachment fitted

This is the fourth devblog update for my Pi Wars robot entry ‘AverageBot’. If you would like to see progress from day one, go back and check out the PiWars tag for a list of the previous posts.

It’s been around ten days since my last update. I would have posted sooner but I’ve had to spend time fixing some issues with the robot. It’s been a bit of a mixed bag this week, some good progress, but some almighty fails at the same time.

Let me leave it there and get straight into the update, in no particular order…

Custom Terminal Block Cover

After upgrading to the laser cut chassis last week, I stood back and admired AverageBot in his dapper new outfit. But something wasn’t quite right…

After viewing from different angles, I decided the terminal block’s cheap plastic cover had to go. It was ruining the ‘feng shui’ of the robot’s new chassis – a bit like wearing trainers with a tuxedo.

As I was getting a new version of my chassis cut anyway, I quickly measured and drew a replacement cover to be made of the same material, with a bit of engraving/rastering and some simple holes to fit it to the block.

Here it is, looking cooler than Dr Dre in the freezer:

terminal block cover

Simple but effective – the new terminal block cover

‘Average-Claw’ Attachment

My favourite part of the week was designing a new attachment for the skittles challenge.

The challenge involves moving/pushing/firing a ball around 75mm towards a bunch of skittles and seeing how many you can knock over.

As I don’t really have time on my side, I decided to make a bare-minimum attachment that would simply involve my robot cradling the ball and pushing it as fast as possible towards the skittles. Any kind of mechanism to fire the ball is out for the time being, but I may have a look at using servos with this attachment at some point.

Once again I jumped on Inkscape, used my chassis as an initial template, and then used the ‘path>difference‘ tool to start cutting out the shape of my ‘claw’ attachment. The idea here is to use the existing chassis bolt/hole positions and mount this together with the chassis – an easy way to add/remove the attachment.

Here’s the result, including the new lasers I bought:

Average-Claw attachment

Fear the claw! The simple shape gives me a minimum entry to the skittles challenge.

Average-Claw chassis fixing

The claw uses the existing chassis mounting holes with slightly longer screws.

Lasers

Yes I ended up buying even more lasers this week. The problem with the original ones I bought was their lack of any mounting options. I’d have to fabricate a mount or 3D print one, and that’s just…effort.

I found these PCB mounted versions and ordered a couple. They have three pins which suggests potential GPIO control which is a bonus. It’s worth mentioning that these things aren’t the best quality – the wires are very thin and leaves me with little confidence that they’ll last more than a week. I guess you can’t complain when they’re this cheap.

Once I’ve wired them up and figured them out, I’m going to use a glue gun to add some supporting blobs around the unit to add some stability.

Keyes laser modules

These cheap lasers will need a bit of support to stay in one piece

SR-04 Code & Testing

I finally got busy on the code side of things this week, meaning I could give AverageBot a good run to iron out any bugs with basic control and movement. This produced some highs and lows…

I finally received my order of female-female jumper wires, allowing me to wire up my SR-04 ultrasonic sensor and give the test code a run. The PiRoCon controller I’m using comes with a handy folder of test scripts to try out most functions that the board supports, which is a bit of a life saver for a coding dunce like me.

It was an uneventful test – the code ran, the values in the terminal went up and down with the distance and everything was as expected. Easy.

PiRoCon SR-04 header

The dedicated SR-04 header on the PiRoCon makes it very easy to fit

I wish I could say the same for the basic movement and motor control…

Motor Control Testing

This part had be pulling my hair out!

Up until now, I am 95% sure the robot drove in a reasonably straight line – even when it had a manually drilled chassis. However during testing this week, out of nowhere AverageBot started steering to the left. I don’t mean a few millimetres, I’m talking about a full arc to the side:

Assuming it was an issue with the idler sprocket brackets (just some metal meccano L-brackets), I ordered some larger fixings hoping it was a simple fix (due to the bracket’s holes being 4mm and me only using a 3mm screws to mount them).

When that didn’t resolve it, I tried the following actions to fix/identify the issue:

  • Swapped motors over
  • Swapped the idler brackets over
  • Switched controller wiring
  • Checked code
  • Rebuilt the robot
  • Removed ‘Average’Claw’ attachment

Nothing worked. I was losing my love for AverageBot, PiWars and pretty much anything near me at the time!

After accepting that ‘something’ (still a mystery) was wrong and mostly unfixable, I started to consider workarounds rather than moving my thoughts to a complete re-design.

I remembered that Gareth from 4Tronix had showed me how to code a more gradual turn after my last problem with spinning on the spot. Gradual turns set different motor speeds for each track in the same direction to move forward whilst turning slightly, rather than one track forward and one track backwards to spin on the spot.

I read through the code examples and decided to make use of this PWM control to slow down one motor to balance the left-bias I was experiencing. After trying some different settings, AverageBot was no longer crashing into the ditch like a wasted Z-lister.

The code is as simple as this:

# Forward
if keyp == 'w' or ord(keyp) == 16:
    initio.turnForward(leftSpeed, rightSpeed)
    print 'Forward', leftSpeed, rightSpeed

And relies on this PWM code that has already been written by 4Tronix for the motor controller:

def turnForward(leftSpeed, rightSpeed):
    p.ChangeDutyCycle(leftSpeed)
    q.ChangeDutyCycle(0)
    a.ChangeDutyCycle(rightSpeed)
    b.ChangeDutyCycle(0)
    p.ChangeFrequency(leftSpeed + 5)
    a.ChangeFrequency(rightSpeed + 5)

Is it a frig? Bit of a bodge? Possibly, but with the amount of time and effort I spent trying to fix the root cause of the problem, I think it’s fair to settle for this solution and move on with the build.

Track Tension Fail

Something else that didn’t quite go to plan was tightening the tracks.

After having the tracks slip off a few times, I decided the issue was a lack of tension in the tracks – despite the distance between the sprockets being 85mm as recommended by Pololu.

I got another lower chassis plate cut during my lunch break, which added a measly 4mm to the distance between the tracks. I got home, rebuilt the robot with this new chassis and turned it on for testing…

…nope. Fail. The motors screamed for mercy as they struggled to produce enough torque to move the tighter tracks.

Oh well, I learnt something at least. New chassis in the bin, old chassis fitted back.

Chassis Hole Fail

Whilst we’re on a bad news theme, I may as well mention another problem with the chassis. I designed a slightly larger hole in the lower chassis plate for wires to pass through from the SR-04, line sensors and other parts.

I clearly didn’t consider how many wires would be going through this hole. I’ll be cutting a new chassis next week to rectify this. Remember kids – measure three times, cut once!

AverageBot wire holes

Another trial and error fail – I’ll need to cut a new lower chassis with larger wire holes.

Motor Upgrade (Maybe)

Remember in previous devblogs I mentioned AverageBot’s poor turning ability? Well as part of my assumption that the £5 low-power motors didn’t have the man power to slide the tracks on the spot, I ordered some high-power versions to resolve this and as a general upgrade.

High-power motors

My new high-power motors. A little risky, but could the reward be worth it?

Now – here’s the thing – the HP motors are a little bit feisty for the PiRoCon motor controller I’m using. Technically, if the motors fully stalled, Averagebot might turn into a puff of smoke. This is because the controller is rated at 1.2A peak current, yet when these HP motors stall, they’ll beg for a mighty 1.6A.

For now I’ve kept the original motors in place, but I’m a man that likes to live on the wild side…precisely 400mA of ‘wild’. There’s something like 6x as much torque in these things so I’m very tempted.

Watch this space…or just watch out for a cloud of smoke in the Southend area…

Next Week

I’m going to continue to refine and code the PWM motor control to keep the robot running straight. I also need to start looking at other challenges – in particular the ‘Pi Noon‘ challenge that requires a wire held in front of the robot. I have no idea how to implement that yet, so a bit more thinking required.

Another big task is to figure out a controller, either a PS3 or Wii remote I think. WiFi is still an option, but I’m concerned about clashes on the day. Maybe I should bring my own router?

The dreaded line sensors can wait for a few weeks but I’ll get to it. There’s also the lasers to figure out – how to code and what kind of resistor to use. The lasers I will leave until last as they’re just a ‘nice to have’ for now.

Lastly – a big shout out to Gareth from 4Tronix for all the help and advice this week. This is exactly why I bought the PiRoCon. I like to support stores that offer excellent after sales support and great code documentation.

Until next time…

2 Comments on "AverageBot Devblog 4 – Code, Upgrades and Issues"

  1. “i is still an option, but I’m concerned about clashes on the day. Maybe I should bring my own router?”

    No. the high WIFI usage at that sort of convention will add awful Lag, you won’t be able to get any sort of effective control.

    Stick to bluetooth.

    • Thanks Doug. I’m with you – they usually have WiFi problems at Raspberry Jams and similar events, and with 400+ people in attendance, I can only imagine this year’s Pi Wars will be just as bad.

      2.4 Ghz is another option I’m exploring.

Leave a comment

Your email address will not be published.


*


This website uses cookies. Please visit our privacy policy page for more information. Privacy policy

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close