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…
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!
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.
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:
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.
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.
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:
— Average Maker (@Average_Maker) October 16, 2015
Some interesting and almost heated discussions were generated by some pictures of my fitted lasers that I shared this week:
— Average Maker (@Average_Maker) October 17, 2015
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:
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!
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:
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:
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:
— Average Maker (@Average_Maker) October 19, 2015
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.
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.
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.
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…