AverageBot Devblog 5 – Upgrades, Servos & Remote Control

AverageBot Devblog 5It's been a busy week - check out the new line follower attachment!

Another week, another Pi Wars robot project update. If you’re wondering what I’m talking about, check out my Pi Wars section to read the first four development blog posts.

I’ve once again been very busy playing with all different areas of the robot, so busy that I almost forgot to write this update (it’s been 10 days since my last one). This is a bit of a monster blog post but there’s lots to share this week.

I’ve been playing with laser cutters, wiring and coding servos, upgrading motors, making new attachments, finishing the proximity code, working on controls and lots more!

So, let me show you the latest changes to AverageBot…

Motor Upgrade

I mentioned in my last update that I had purchased some sexy new motors for AverageBot as a potential fix for some of the turning issues I was experiencing. My only reservation was that the motors were rated higher than my PiRoCon motor controller, which could cause it to cut out or maybe worse.

After looking at the specs and doing the maths, it was clear that fitting these would come with a risk. If I stalled the motors for too long, AverageBot could become AverageScrap. I thought long and hard…

…then thought sod it!

It's time to get these hot motors installed. Step 1 – soldering!

A photo posted by Average Man (@averagemanvspi) on

I fitted the motors and it now goes like stink! Problem solved, albeit with the new risk I have created. The new motors are a bit too lively on carpet and tend to tear off the tracks. Luckily all of the Pi Wars challenges are on hardboard.

To show the improvement, I shot a quick video of the robot pre and post upgrade:

Motor wire protection

As I was fitting the new motors, I noticed that the motor wires were a little tatty on the underside of the robot. With the line sensors now moved to an attachment (more on that below), the only possible snag on the underside was these thin and fragile wires.

That could cause problems with the obstacle course challenge, especially as no one knows what it will include. So, as apart of my trip to MakersCafe to get my new line follower attachment made, I designed a simple wire guard panel which utilised the existing screws.

Wire guard plate

A simple change that makes the underside of my robot completely snag-free

New Attachment – “The Linesman”

I made a new attachment this week, following my skittles attachment from last week. This time it attaches my line following sensors.

I originally had these sensors mounted on the underside of my robot near the middle, but after some tips around keeping line followers nearer the front of the robot, and my own concerns around ground clearance for the obstacle course, I came up with this:

Line sensor attachment

Attaching the line sensors up front should work much better

I still haven’t coded these line followers, but I’ll get to it.

Speed Setting Code

You may remember from last week that my robot had a bit of an issue driving straight. After learning that encoders were difficult to use with these particular tracks, I opted for the easy route and simply adjusted the left/right PWM speeds to get AverageBot running straight.

That worked fine for a single speed, but what if I want to go faster or slower?

I assumed I could adjust the speed using the same proportions, but I quickly found that slower/faster speeds had a different imbalance. Stupid tracks!

I figured that a way around this would be to set up different speed settings, and test each speed to get the proportions right. I altered the example script to allow single-digit changes to the left/right PWM speeds, instead of the usual 5-point jump, which would let me test for the right settings at each speed range.

An example of this is below. It says “When I press ‘Y’, increase the ‘leftSpeedfwd’ speed by 1 point and to a maximum of 100, then print that information in the terminal”:

elif keyp == 'y' or ord(keyp) == 22:
    leftSpeedfwd = min(100, leftSpeedfwd+1)
    print 'leftSpeedfwd+', leftSpeedfwd

Once I was happy that I had high, medium, low and ‘crawl’ speeds tested, I added the speed settings to the script. Here’s an example of the forward speeds I’m using. Notice how the crawl and low speeds give even power to both tracks, but as soon as we hit medium or high I have to start adjusting:

ForwardCrawlL = 10
ForwardCrawlR = 10
ForwardLowL = 20
ForwardLowR = 20
ForwardMediumL = 57
ForwardMediumR = 60
ForwardHighL = 90
ForwardHighR = 100

This quick and dirty method may need adjusting on the day of the competition to account for the different surfaces.

Proximity Alert Challenge Testing

With the track’s left-bias sorted out (kind of), I started work on my proximity alert challenge code. This is the challenge that tests your robot’s ability to approach a wall and stop before hitting it – and get as close as possible at the same time.

Whilst I’ve seen some of the more experienced robot builders using advanced methods like Sharp sensors, I’m new to this game so decided to stick with the “bread n’ butter” of distance sensing – the SR-04 ultrasonic sensor.

SR-04 sensor

As a robot beginner, I’m sticking with the trusty SR-04

I found this quite easy to get up and running using the supplied example code from 4Tronix that came with my motor controller. The hard part is refining the speeds and distances to avoid slamming into the wall, but at the same time getting as close as possible. With a 30cm penalty for hitting the wall, it’s very much risk vs reward.

As the sensor isn’t very accurate when it gets close to objects, I decided that I would attach my ‘Average-Claw’ attachment during this challenge to increase the distance between the sensor and the front of the robot. This worked well.

SR-04 distance measuring

Notice my new RasPiO ruler doing the measuring…fancy!

Here’s a video I shared of some of my first attempts. Whilst the tiny gap you see here appears impressive, on the second try it hit the wall with all the grace of a rusty JCB! I’ll be refining this over the next week:

Lasers Controversy!

Some interesting and almost heated discussions were generated by some pictures of my fitted lasers that I shared this week:

The general consensus of this long discussion was that it would not be wise to use lasers unless they were very well protected from spectators eyes. My lasers will point forwards about 2″ off the ground – and only during certain challenges WITH remote control – so I did question the probability of someone’s eyes being in the line of sight.

However, following these conversations and my general lack of cash to pay for any potential legal claims as a result of my tiny lasers burning holes through children’s heads – my lasers are staying off for now!

Servos for Skittles

Last week I showed you my ‘Average-Claw’ attachment for the skittles challenge. I figured it was a good start and at least gave me ‘something’ to use to push the ball towards the skittles. Unfortunately after seeing some solenoids and similar snazzy solutions from the other entrants, my competitive side got the better of me.

Similar to the distance sensors, I figured it wouldn’t be wise to try anything too advanced so early in my robotics career. I turned my attention for servos due to the fact that the PiRoCon motor controller had example code and easy pinouts ready for servos, and I already had a servo salvaged from my Dawn Robotics camera robot:

9g servo

My salvaged 9g servo

However, I ran into issues with the code examples that came with my controller. It uses something called Servoblaster and a file called ‘servod’ and has all sorts of magic and sparkle that lets you control your servos with precision, but I struggled to get it to work.

Gareth from 4Tronix spent a good deal of time helping me get it working, but then I came across a really helpful YouTube video that showed me a simpler (and probably less elegant) way of getting my servo to turn. All I really needed was a 180 degree spin to flick the ball, so any kind of smooth and accurate control wasn’t required.

I copied the example in the video and wired up my servo the same way, simply using GPIO pins from the PiRoCon board. Everything worked as expected – result!

Servo testing

Servo testing a few nights ago

Now all I need to do is design and build some kind of attachment that can utilise a servo with some kind of paddle attachment to try and push the ball. This might not work well at all, but one thing is for sure – it’s going to be a big ass bucket of fun building it! So far we’re at the “scribble on paper” stage:

Servo mechanism ideas

I’ve got lots of ideas for the servo mechanism…(ignore the terrible handwriting)

Remote Control

A big concern for a while has been remote control. To date I have simply used WiFi and SSH, but as I have mentioned before, using WiFi at Pi Wars is a bit of a no go due to all the clashing robots and signals.

I considered using bluetooth with a PS3 or Xbox controller. I also considered bringing my own router and chancing the WiFi…but then I stumbled across a third option on Twitter.

Fellow competitor David Pride (@Davejavupride) mentioned he was simply using a 2.4Ghz remote with a USB receiver to control his robot. Bazinga! I already had an iPazzport 2.4Ghz remote (which I wrote about previously) so this seemed like the perfect solution:

2.4Ghz remote

I’ll be using this 2.4Ghz controller at Pi Wars

David helped me get this up and running, which includes using PyGame to enable the use of the remote with a Python script.

I initially tried this without PyGame, but for some reason it just doesn’t pick it up as a remote without it. I also tried to use the PyGame code without any screen reference, but Twitter pal David Honess (@dave_spice) quickly informed me that it’s required to pick up keyboard presses.

Here’s a quick video tweet that I shared after getting it working:

Wire Holder

Something else I need to sort out is the wire holder for the Pi Noon challenge. Currently I’m thinking of making a simple ‘sandwich’ plate out of two pieces of acrylic – similar to the way my wire guard works.

More on this soon.

Code Curiosity?

It’s worth mentioning that I’m not sharing my full code in these blogs because, well, it’s not finished yet!

Once my code has been submitted on 14th November (a compulsory code challenge deadline) I’ll share each of my challenge scripts in the update for that week. If in the meantime you want to see what I have so far, just let me know.

Next Week

That’s all for this week, so what’s next?

I imagine I’ll spend a lot of time working on my servo skittles attachment, mostly because that’ll be the most fun! I think it would be satisfying to refine and complete my proximity alert code as well, as it’s nearly complete.

I’ll probably get my wire holding plates cut this week whilst I’m getting the servo parts made, and there’s also a bit of work ongoing with 3D printed idler brackets that I may pick up again. I’ve been designing my own brackets to resolve the left-bias a bit more, as the current brackets are a bit prone to bending.

TinkerCAD brackets

I’ve been using TinkerCAD to design some 3D printed idler brackets

Code is the next big thing, getting as much ready and wrapped up as possible before the November deadline. Oh and those pesky line followers – I need to print a track and get going with them before it’s too late!

Until next time…

6 Comments on "AverageBot Devblog 5 – Upgrades, Servos & Remote Control"

  1. Holy moly. Epic post, dude. 🙂

  2. We used wifi to control Metabot last year and it worked fine. The key was to make Metabot itself be a wireless access point (i.e. not a client) which our control PC connected in to. That way we had our own private wifi network wherever we needed it.

    Anyone trying to use the event’s wifi access points for control was out of luck (at least one competitor had to sit out all the manual events as a result).

    There are a bunch of tutorials around the interwebs with details of how to do this, but the details of how to do it depend very much on what chipset is in the wifi dongle you have.

    Difficulty of setting up a WAP varies from easy (install hostapd and netmasq, write config files) to complete nightmare (find source for drivers, patch it and recompile, then do the package install and config).

    • Interesting to hear Lance, thanks.

      I did have a simpler WiFi solution in simply bringing my mobile hotspot with me, but lately I’ve found it to be a little bit fiddly. If the 2.4ghz option doesn’t work out, I’ll start looking at that again.

  3. Allan Gardner | 24/10/2015 at 11:54 | Reply

    Once all done would you consider compiling a list of components, suppliers and helpful sites?

    • Hi Allan

      Once the build is complete, I plan to do a full spec of parts, suppliers, costs, weight etc. I’m a tad nervous to see how much I’ve spent overall, it’s too easy to build up the costs with lots of small pieces and orders over a long period!


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.