The group project is complete! With all 67 pages of report submitted and flashy hardware demonstrated nothing else is left to be done.
So first up, some obligatory photos:
The Solver, in all its death-star-ness
The drama shot of the cube, the centre cube frame is used for holding colour calibration strips for the cameras and is held in place entirely using fishing wire
A resurrected version of our interim submission. We used it for demos during the presentation: wiring the servo into a lab signal generator which allowed us to demonstrate the cube actuation in a controlled (and not covered-in-wires)manner.
And an obligatory solving video:
Solving video!
In the end our gamble with the servos paid itself back, giving us a very high reliability, but rather long solve time. This contrasted well with other groups who had really quick solve times, but ended up with more frequent cube jammings.
My own major contribution to the final product was the design of a computer to cube communication system. One of the requirements put on us (to make things harder) was that we had to route all control signals through an audio cable which could not have any programmable devices after it to control motors. The design and implementation of this system has been one of the most enjoyable things I have done at uni so far - not least because I have reached a level of experience that means I can design basic circuits that work! Inputs to the audio cable were generated using a standard PC soundcard, which let me play with Python at one end, while demodulation was done with some pretty neat circuits at the other.
Signal flow diagram showing the modulation and demodulation of the information signal
In order to increase the information carrying capacity of the communication system I decided to multiplex multiple signals on the audio cable in the frequency domain, which required a whole bunch of band-pass filters to de-multiplex again. To adequately understand how to send signals to the filters so that they would work properly (by sending them signals in their pass bands) I needed to do a frequency response test on them. To increase awesomeness, and make use of our shiny new lab equipment, I was able to do this entirely automatically, commanding and drawing data from an Oscilloscope and signal generator using MATLAB and an Ethernet cable!
Automatically produced graph of all the filters' frequency responses!
Finally (the funny bit at the end...) I got carried away with Inkscape during the closing stages of the project as we were preparing for presentations which meant that our group ended up with a 'logo'. Needless to say my courage was not up to putting it in the final report!
We were Group A. Yes, the image did start life as the Manhattan project seal.
No pictures, no videos :( - just a hope for some in the near future!
The solver worked really well, and looked insanely cool. With the report due in soon the group has now turned its efforts to Arch Enemy no. 38: Documentation.
Like fools we decided now would be a brilliant time to trial-by-fire learn our way around LaTeX. A couple of thousand lines of code later, and 65 pages, and I think it worked.
Rubik's cube update, final hand in is next week. Given that we then pretty much go straight into exams this deadline is final - which is strangely comforting.
The good thing is that it looks like we (my group) might actually hit the deadline! After integration tests at the end of last term showed some fairly serious errors we have spent the past week of work time tidying things up (to make sure we can see any loose wires, rather than misdiagnosing a bug), rigorously re-testing system components (so we know how they go wrong more precisely) and hastily adding an entire extra communication channel (my fault on that one :( ). This culminated in a complete detect and solve that only had one slight over-rotation of a cube face during one of the moves!
While there will certainly be a video posted in a short while, in the meantime some photos!
A graph of output voltage for various input signal amplitudes, each line is a set of amplitudes for a different communication frequency. As you can see only one set of communication gets through. This graph is kind of redundant, technically the frequency response data (collected months ago) should be able to prove there is no cross-channel interference, however it made group members happy!
A neatened pile of wires. What? you say this is messy ... my reply would be "this is after we have tidied it!"
Having talked of tidyness, 'the horror... the horror...'
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...
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 PlaiceII 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.
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!
After many days of hard work from the team I am in we have finally completed the chassis for the solver, which will hold the cube, actuators and any electronics required. The idea when designing this chassis was to make the actuator mounts (these are the large empty boxes) as flexible as possible - meaning that we can build and test other subsystems (like cameras) before the motors and gearboxes are ready.
A quick note, this is my EEE degree's third year group project. Seeing that we are third years the project supervisor has decided to make things slightly harder - all communication to the chassis mounted electronics (and motors) has to be done via an audio cable, and we are not allowed programmable devices to decode the information from the cable. The team's solution to this involves a PC soundcard, lots of bandpass filters and a couple of basic ADCs to implement a simple analogue shift keying communication scheme with multiple sub channels separated in the frequency domain. The lack of programmable logic has left us having to control the actuating servos with one-hot logic, which slows down our solving speed considerably.
The cube sphere!
Three years of Engineering education put to good use in finding a way to hold the cube in place for camera testing. (Hot glue was also used)
Working through some software problems today ended in some rather funny solutions this morning (why do programming breakthroughs always seem to happen when everyone else is asleep??).
It just so happens that both the Rubik's Cube Solver and the Solar Flare Detector are going to require me to become a pro at manipulating PC soundcards, both for sending and receiving signals.
Sending signals is fine:
Find a nice stable interface library,
Bash together some sample values,
Send them off to generic 'write' function,
Play sweet sweet music,
Become single most hated person in the lab for constantly playing annoyingly pitched sine tones...
Receiving signals is proving slightly trickier, or rather analysing the received signals in the frequency domain is proving rather mind bending. To illustrate, some nice graphs:
An arbitrary signal received through my PC's microphone (in the time domain). Ignore both axis for the moment.
The reported amplitude spectrum of the above signal. The fact that is is clearly just a copy of the original signal put through an 'magnitude' function rang many alarm bells. Another bell ringer was the fact that is not symmetrical around the Nyquist frequency (~22 kHz), a necessary outcome of an FFT. We can read the bottom axis as frequency directly.
An example of what I was expecting to see, a nicely prepared amplitude spectra of two superimposed sinusoids with a large DC offset. We can use the bottom axis as frequency again. Note that it ends at about 22 kHz, the magics of digital sampling mean that anything above this frequency is simply a reflection of the spectra below that point - it is easier to not show it.
What appeared to be happening was that the Fast Fourier Transform (FFT) function I was using seemed to like synthesised, simple, waveforms - but not horrible real life ones.
At this point it is probably a good idea to give some indication of the software I am using, as it turned out my interpretation of it was the cause of most of my errors. In general when programming on a PC or large computer I like to use Python 3, and for this particular task I deployed the potent Numpy/Matlibplot library combo. Initially I was using PyAudio to interact with sound related hardware, but I quickly realised that the sounds it was producing were awfully messy and did not correspond to the carefully crafted sine waves I was trying to generate. After digging around and seeing some other people complaining on various forums I switched to the SoundDevice library which promised to be more stable. It was, and I quickly progressed from producing signals to trying to receive them.
That was when I started producing graphs like those above. I dug around, maybe my received data needed to be in another format ... maybe I needed to change the sampling frequencies ... e.c.t. (That last 'solution' turned out to be an incredibly bad idea, I can only guess that the software and hardware supporting the soundcard and Python interface is optimised for specific sampling rates, because who would want to change that? :) )
Several hours of digital sampling theory, frequent code double checking and desperate internet searches ended when I realised that I had misunderstood some documentation and got my rows and columns mixed up when feeding data to the FFT function.
As quickly as I realised my problem all anger at my poor computer subsided, I had been asking it to compute the frequency content of thousands of individual samples (which gives the amplitude of said samples at DC/0 Hz) and then plot the results. Instead of plotting a bunch of data points at x = 0, Python had plotted each individual result like a column graph which (unsurprisingly) produced a copy of the original signal with all negative results flipped to be positive. The reason the synthesised waveform had not had this problem was because it was stored differently and so did not have its rows and columns confused.
Once I started using the data correctly my issues quickly resolved and I began producing graphs like the one below, cheering and waking up all my flatmates...
A nicer frequency amplitude spectrum of the signal incorrectly processed above. It has had its spectra cut off around 22 kHz in the same manner as the spectra of the synthesised signal. I am fairly sure that everyone in my terrace of houses knows I was able to produce this graph.
Sorry that this has been a bit of a dry post, I have to take the opportunity to write when something happens that is both applicable, and has shiny images!
