Robot Wars, Level Up!

On to the next crazy project!

I suppose I should begin this post with an update on Gigaton Handshake: Optional Ultimatum (Giga to its friends). The last post saw the completion of the CAD design and I can happily report that is has now been built, wired, tester, rewired and is looking forward to its final tests/fixes a full two months before the next competition here at the uni. Does this mean that we are going to sit on our hands for a full two months waiting for action? Of course not, and unfortunately that means we shall start with a digression.

Gigaton Handshake

Evil cat time, high backed chair slowly rotating... flash of lighting!

"MWAHAHAHA"

"Sit on our hands! Sit ... on ... our ... handssssss??"

Long story short my fellow roboteers and I have decided to try and design/build/program our own robot control system/board. Hopefully this will end up being lighter and more compact than the current menagerie of various commercial boards we use. The plan is to use them to put together a three bot cluster (three robots in the same entry), as well as allow us to build many, many more normal bots.

As a project this has been rather interesting so far, it took us ages to come up with the correct design requirements but once we had them the rest of the design has gone quite well. We broke down our requirements as follows: 

The board was determined to have to be able to:

• Be powered from a lithium polymer cell with an input voltage range of 3.5V to 14V to allow 1-3 cell li-po batteries to be used.
• Control 2 DC brushed motors directly with 2V/Vbatt continuous current draw
• Supply control signals and power to two servos with 200mA/5V current draw.
• Receive and process human commands into servo/motor outputs.
• Human must be remote from board (commands must be transmitted wirelessly)
• Wireless communication must be able to penetrate 5mm polycarbonate
• The board must have an interface to allow its firmware to be updated
• There were a bunch of size requirements too to ensure that we were actually getting an improvement with the new board.

The next step was to determine the system architecture and hardware that could realise these aims. Initially the plan was to use a discrete micro-controller, RF transceiver, motor controller, and power regulator however after much discussion we managed to address the functionality of the first two with an ESP32 board.

The selection of the ESP32 was quite an interesting process as initially we had lined up to use two chips, an ATMega328p micro-controller and Si4463 sub-GHz RF tranciever. Our reasoning was that the AtMega chip met all of our requirements and could be programmed with the Arduino bootloader, allowing us to use the Arduino IDE and libraries which makes the embedded code much easier to develop. Additionally the Si4463 was similar to the CC110Ls used during the Blake Project, and at sub 1-GHz we were going to run into RF weirdness during PCB design, but not too much.

My group member had got to a late stage in the PCB design before we swapped over to the ESP deivce, partially due to both our dawning horror at what the AtMega and Si4463 would require to get working. My group member was having serious concerns about the challenge in routing all of the signals between the two devices and to the transceiver's antenna while keeping to board to a reasonable size. I was having second thoughts having done some preliminary work designing a wireless protocol as an improvement on my naive effort during the Blake project (one specific improvement being not crashing whenever a single packet was lost). The work I had put together in preparation had already filled many sheets of paper with flow charts but I was still unsure of its effectiveness, or even its ability to be implemented. Finally both of us had realised that we were going to have issues with the Si4463 as we would need to create another device from scratch to allow a human to generate the RF transmissions.

The ESP32 device we chose had several major features that fixed most of these issues. Firstly it combined the transceiver and micro-controller and implemented all of the RF circuitry, making the PCB design much easier. It also has the ability to communicate via Bluetooth (classic and low energy). This means that we get a full communications stack given to us with all interactions happening at the application layer, much less of a headache than the PHY level interface the Si4463 was offering! Using Bluetooth also means that we can use the transceivers in our phones to communicate rather than having to build new hardware ... once we learn how to build Android applications ...

Gathering mist and darkness, spooky castle fades into the background, maniacal laughter slowly dying away...

Back to Gigaton Handshake which went together fairly well, the uni's student workshop had some brilliant metal cutting tools for the front armour plate which meant I was able to cut a couple of spares, just in case. The 3D print went well, the new uni printers work like a dream. Initial construction was surprisingly painless (amazing how good things can get when you actually plan them) and only required one revision after initial testing.
The issue was, in true what-can-go-wrong style, electrical. When I had wired up the robot initially it had both the drive motors and radio receiver powered from a couple of power regulators on the brushless motor controller board. This worked really well until the motors tried to draw a lot of current, for example trying to turn really fast from a standstill. This drew all of the available current (about 3A) from the power regulators and starved the receiver, which promptly crashed. Luckily this was a problem with a quick fix and the motors are now powered directly from the battery, which has a larger possible current output of ~20A, before exploding.

The brushless motor works with relatively little fuss, the blade needed to be roughly balanced before I was happy using 100% throttle, this was done with a piece of string and a file.

Giga, a view of the other side a bit emptier as it usually holds the battery
(which is currently staying in its lipo safe)

 This robot is now roughly finished, with only a couple of improvements. The first is to add the now distinctive drinks can blade to the front to increase scoopiness. The second will be to take a file to a couple of the edges to try and get the maximum dimensions down a bit. The third, possibly more important step will be to hot glue all of the components down to the chassis, with about 50g space weight I am hoping that I can use enough glue to almost act as impact softeners shielding the electronics from sharp blows when the robot is thrown about. The final step will be to upgrade the wheels.
Given I have lots of spare mass to play around with the wheels are going to be triple layered with alternating MDF and Perspex pieces. The idea is that putting MDF on the ends of the wheel will allow it to absorb spinner hits while the central perspex layer will provide a bit of rigidity. The final innovation is to add teeth to the outside of the wheel, these are not to grip the arena floor themselves, but to grip a layer of rubbery plastic that will be added later which should increase the wheel grip dramatically. Like all good 2D components these will be cut on the laser cutter at Uni.

Cad rendering of the wheel design, blue will be MDF, red will be perspex.

Robot, now with armour

Following on from the explosive adventures of The Rock and A Hard Plaice I have designed a sturdier successor, with an active weapon.

In an unprecedented move I have planned everything out, to ensure that all components fit. The easiest/coolest way to do this was in Inventor - which means that even though the design is at an early stage, I have pictures! (I also used the design process to experiment with parametric/variable driven CAD)

Always have to have as many colours as possible - (`\'-'/` - how else are you going to tell components apart?)

Major improvements include:

1. Armour, and not made of just paper
2. Guaranteed room for all components!
3. Exact wheel diameter tolerances
4. The aforementioned weapon, hopefully this will not end with the robot tearing itself apart!

The weapon is planned to be a vertical bar spinner, acting in a similar fashion to a flipper. Through previous robot iterations (the venerable Big Wheels series and the more recent The Rock and A Hard Plaice) my fellow teammates and I have become adept at being able to have a very low front scoop, generally well below most of our competitors. Therefore hopefully what will happen is that this robot will ram its opponent, forcing the opponent up the front ramp and into the spinning blade. As the opposing robot will already have been scooped from the floor of the arena when it is hit by the bar it should recoil further (and fly further), while the forces through this robot will be more vertical, preventing it from also recoiling too far.

The name is still undecided for the moment, ideas include Gigaton Handshake, Coincidental Survivors or Bizarrely, Trifle.

Easter Roundup

As is the way of academic term time - things have been fairly busy recently! As a result I have missed writing posts about several different project events, so here they are, amalgamated into a mega post:

Blake Project:

Yes, we finally handed it in, presented at an outreach event and semi-satisfied our supervisors. We managed to automate one of the cars, dictating it's behaviour with a learning state machine. This solution required us to quietly ignore that the 'learning' involved the car loosing control and falling from the track!

The final system did not include the brilliant perspex track, unfortunately I was not able to get the rails to be smooth enough to maintain reliable electrical contact with the cars as they travelled!

GrAVITAS:

I reckon that I will need to rename this project "The Han Solo Memorial" given how often it has gone into hibernation. Since the last post I discovered major potential instabilities in the planned circuit design, which scrapped the planned layout. Then University projects happened and we find ourselves a couple of months in the future.

Luckily I have now extensively tested new signal chain components (as a lucky byproduct of aforementioned University projects) which should mean that the hardware is put together very soon (fingers crossed)...

Robots: The Rock and A Hard Plaice, I and II

A bit more action here, mostly due to the fact that the Rock and a Hard Plaice suffered almost 50% fatalities per entry into a competition.

They were a blast to drive, not least because with two drivers the clusterbot became quite a sociable thing. Sadly weight saving measures left both bots rather vulnerable to more destructive opponents the first iteration of The Rock I fell victim to a vertical saw blade that discovered the only thing guarding The Rock's flammable lipo battery was a sheet of decorative paper!

Hmmm - I didn't intentionally add a fire weapon...

Of course, a video: https://www.youtube.com/watch?v=aL26JNXmnOE

(Destruction at 2 minutes 15 seconds)

Naturally once wasn't enough so I went about redesigning the cluster bot to be slightly better armoured, and actually used a 3d printer (splutter, splutter) to produce the chassis! Somewhat undaunted by the fact that I was greeted at the next competition by "are you going to explode again" from some very excited organisers The Rock and a Hard Plaice II managed to not die at all.

Sturdier, right...

The next thing to do was to go a step too far, which I managed to do admirably by entering a public antweight robot wars event.

This was the result: https://youtu.be/N7zi8lK0Ia0?t=10m3s

(destruction occurs at around 10 mins 30 seconds)

I think the best bit was that I could find enough pieces to reconstruct the chassis and had to consolidate the available hardware into a single zombie-bot:

In retrospect the decision to add the 'Hard Plaice' picture to the underside was somewhat disturbing...

 Rubik's Cube Solver:

Perhaps the most enjoyable project I have ever taken part in, the Rubik's Cube Solver has also been one of the most time consuming!

In the past few months I have been able to design, build, redesign, rebuild and debug the communications hardware and software for sending information over the mandated audio cable.

For those interested m hardware consisted of a Sallen-Key filter designed with the Analogue Devices filter wizard (all praise the filter wizard) with non inverting amplifiers acting as input and output impedance buffers. The actual demodulation was done with an envelope detector circuit. Modulation was done with software driving a PC soundcard.

Amusingly today was supposed to be the have-everything-working day for the project with a presentation next term. However not a single group managed to hit the deadline, mainly due to integration issues, which meant that the unit director pushed the deadline back in an act of supreme benevolence! My group was 99.999999% of the way to hitting the deadline before we discovered some rather tricky bugs involving envelope detector fall of times (yes ... that was my section) which we were unable to both generate and integrate a solution for in time.

Given the state of things I am sure that I will be able to post a victory video shortly...

The initially planned communications tower, my demodulator fits into the second lowest box. 

Cube as it is now, with illuminating LED's and blackened actuation rods.

Satisfyingly not much has changed in the solver structure, except for the addition of a fluorescent-bulb-blocking shade. While it is not the most aesthetically pleasing structure coming together in the lab I am happy with it as the open frame and intentionally forgiving design has allowed us to test multiple system elements and interfaces well before full integration

The interior of the Demodulator box, I think the wiring leaves much to be desired!

Aaaand ..... there we go all caught up. With three weeks of holiday coming up either many more posts are about to be made, or my next post will be in a couple of months time after the next academic term!

An Update

Silence for months must be followed with an update post, it is a rule of nature.

At the beginning of the (academic) year I listed some of the projects that I am working on at the moment. Question: how are they going? Answer: ummmmmmmmmm - I'll get back to you.

Immediately.

Blake Project:

Turns out not spending eight hours a day on a project can really slow progress. The AI has been semi constructed, the algorithm has been written, and so has the car driving code. All that remains is to plug it all together (which is always the longest part anyway!).

The track, is in pieces. Not as many pieces as it was, but it is many hours from completion. Luckily we have a reading week at the moment with many hours in it, many fingers are being crossed.

Its all there! Just not together.

 Telescope:

The updates that need doing have been identified, I really need to install a focussing mechanism better than a loo roll and friction. Also, upgrading the optical tube frame to be more portable, yet sturdier, is definitely on the cards at some point.

The telescope has had some good outings recently, trying but failing to see Uranus, getting a peek at Mars and a good look at the Orion nebula. I was going to try and point it at Jupiter and Venus on Tuesday, but the only place I could see them was from the middle of a road (I live in a city and they were close to the horizon), which I did not think was appropriate. They were awesome enough with the naked eye!

Solar Flare Detector:

Designed, the project decided to change the receiver to an SDR (software defined radio) based one, plugging the antenna (after a couple of filters and amplifiers) into a microphone slot and using a computer to do all the hard work. As it should.

Of course given that the solar flare detector should be running fairly constantly we have elected to use a Raspberry Pi as our enslaved processor - which means I have to relearn linux.

Also it got a name the GRand Assembly for Versatile Ionosphere Tracking and Astronomy of the Sun or GrAVITAS, a ripe source of puns, a source of gravitas (can't help myself), and of course an oblique reference to Iain M Banks. It looks very good in email headers.

The engineer at work, all four monitors in use. More screens = more work being done right?

Rubik's Cube Solver:

Good progress, but nothing of note yet. At least nothing worthy of photographing!

Lunar Rover Mk2:

Wow - got assigned to other projects within the space society for the moment, which was rather unexpected. The sneaky plan of the committee is to shuffle members around between projects as work amounts change. Ideally this means that some point in the future there will be much posting about rovers, the ideas coming out of the rover team so far are really rather cool.

Random Shiny stuff:

It always happens.

Robot Wars.

So the university electronics society run an ant-weight (150g, 10cm cube size limit) competition twice a year, so I should have seen this coming. Because this is going to be the fifth time we have entered, my team is going to attempt to build a cluster-bot, fitting multiple independent robots within the restrictions. This is leading to all sorts of fun and games trying to reduce the mass of the individual components of the robots which is likely to be the tricky bit.

This one also has a name, The Rock and a Hard Plaice, more details to come soon.

Who needs scales when you have string, water and a measuring jug?