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...'
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:
Armour, and not made of just paper
Guaranteed room for all components!
Exact wheel diameter tolerances
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.
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)
GrAVITAS returns - a bit worse for wear (having been stored in carbonite for so long). Work has finally got manageable enough for me to return to work on the solar flare detector. Actually, I lie - there were a couple of brilliant team members who persisted with their task, even when I went quiet on the subject, who galvanised me into action.
So, the progress:
1. Much software doings, it is only the scheduling and reporting that needs to be done. Having said that I have discovered (from other similar projects on the web) that NOAA publish the information from GOES-15's solar instruments, which would be brilliant to compare with the data we capture - and could be used entirely automatically.
2.I finally got around to the hardware, and have now planned out the analogue signal chain. Luckily due to the audio card digitising the signal, it does not have to be too complicated. A couple of buffers, amplifiers, a notch filter and a bandpass filter and everything is awesome! Needless to say, I expect the receiver to work terribly in this first iteration, but maybe by the fifth.... I think that while the design below does not include them I may end up adding a load of potentiometers in the place of some of the resistors to allow me to bodge optimise the circuit parameters!
My planned matrix board layout for the analogue signal chain. All go for soldering up on Thursday.
Hopefully I can post soon about even more progress, but I expect that my targets may slip - we have another Blake Project presentation opportunity this weekend which may eat a lot of time.
Actually it has been complete for a week, but I have been too busy enjoying the sky to post about it.
Turns out that I am not yet genius enough to design something to work first time just yet: during construction there were some improvisations I had to make with the original design that I will go through below.
Now that the focuser is working the difference in viewing quality is enormous. Being able to get the focus exactly (okay, not quite exactly) right without shaking the entire scope, as my friction fit focuser did, means that I can get sharp images without the telescope moving itself away from a target.
This will hopefully mean that I can finally start using the telescope to the limit of my optics. This is a welcome change from the limiting factor being something that I have done (or not done!).
The focuser
The focuser still needs a bit of touching up, at the moment the axle bar is a threaded rod which can lead to interesting interactions with the securing bolt and tends to shred the eyepiece holder. It is also 1mm too thin - I am probably going to take a quick trip to the hardware store soon to find a replacement and solve these issues.
Additionally, I managed to find a PVC plumbing fitting that fitted my required dimensions, but now is acting as a brilliant reflector of stray light into the eyepiece - I am going to have to paint it black at some point.
Finally my method of attaching the focuser to the scope can be seen above, it is not very pretty, but works well enough, for now. At some point in the future I may get around to improving the mounting mechanism.
Shot straight through the eyepiece slot. One of the things that did work were the four bearings which, due to a combination of brilliant datasheets from RS and the precision of the laser cutter, are precisely where they need to be.
The revised fastening mechanism. It seems to work quite well.
One of the things that changed dramatically was the fastening mechanism. I turned out that I had not left enough room for the spring in my design. Looking around the web at other homemade focusers revealed that a surprising number simply used a bolt pressing on the axle to secure it. This also solves the longer term problem of the spring wearing out as the spring is now provided by the structure, it also saves me a wing nut for use in future projects.
I have epoxied a nut on the axle side of the back plate to hold the bolt, with a cannibalised section of the original pusher plate used to provide extra counter-torque on the nut. One of the problems that has arisen from the threaded rod being used as an axle is that it likes to move left to right (up-down in the photo above) when it is turned while under pressure from the bolt. This is usually fine, but can be a surprising pain.
Mirror holder - modified!
The final modification was probably the scariest, and is likely going to require more work in the future. Because the new focuser is about 3cm taller that my old loo-roll eyepiece holder, I needed to shorten the tube of the telescope by about this amount to move the focal point of the mirror. By pure chance, when I had originally put the tube together I had made the main spars out of two shorter sections of wood bolted together. This meant that shortening the tube was a simple matter of swapping out the shorter of the two pieces with an even shorter piece (as seen in the photo above). I was a bit sad to say goodbye to some of the last remaining original and reliable components of the telescope. Unfortunately, because he tube shortening only occurred at one end, and the current setup does not allow me to slide the mount attachment point around, this has thrown the balance of the telescope off. Even with the proper mount, the front of the telescope really wants to drop. While I could revert to the old method of hanging a bag of rice from the mirror cell, I think that the longer term solution is going to be rebuilding the telescope tube assembly as this will also allow me to incorporate some of the lessons I have learn't (like having a movable pivot point).
First post for the year is a surprise blast from the past: progress on the telescopes focuser - please try to hide that rolling of eyes.
So, almost a year after throwing the first bits of the telescope together I finally got into the mood to do some serious design work on the last major element of the telescope left - the eyepiece focuser.
Up until this point my eyepieces have been held in with friction and toilet rolls which is not to stable and does not allow for fine movements of the eyepiece. With the gradual upgrade in the other system components the focuser has finally become the weakest link.
A quick google search can show all sorts of brilliant designs - most of which have been made by someone else who is trying to sell them to you. Luckily there are also scattered articles of people making their own - generally with the a high level of ingenuity that most amateur telescope makers seem to possess by default.
In particular the ingenious Crayford focuser design, while used in high end commercial models, has been constructed in all sorts of ways including from assorted wood and plumbing scraps. That sounds like something I can do - especially when I have my trusty sidekick: Mr Laser-Cutter (its a double barrelled name).
I have just finished my CAD model ready for a workshop session sometime soon, which incidentally means I have pictures:
the focuser - note that my CAD skills are limited - I have not managed to put all my parts in an assembly to make the design look completely pretty.
The top view - hopefully the holes for the two bearing holders are visible on the left hand side of the image - the pressure will be applied with a spring pushing a pusher plate against the axle (which will happen on the right hand side of the image.
The pusher plate, I have tried to reduce its contact area with the rest of the focuser while maintaining its ability to stay straight by giving it the bowing in sides.
The Blake Project is to be presented on Friday, all or nothing, do or die - this is the final push!!!
UPDATE:
It worked, it actually worked! We had a few final system integration issues which meant that the Radar was the only thing that was properly presentable, however this seemed to work for our audience who I don't think would have enjoyed the autonomous car as much.
In a flash of madness I had laser cut some props to use on the day which meant we ended up pretending we had Darth Vader stopping cars travelling too fast (we had a silhouette of him and it kind of made sense) - segueing into a discussion of the radar if we found someone who was interested.
We now have another set of dates to have the project ready for presentation on, hopefully with a bit more success.
Work has been steadily progressing on the perspex track over the past month or so, but the past week has seen some major progress (not least because all lectures were suspended for a reading week). Because it was never going to be any other way, the first full completion of the track occurred this evening, just before the term resumes again.
Shiny completed perspex track! (just imagine that the electrical tape holding the different sections together is not there)
Why is this a 'first' completion?
There is some trouble with the spacing between the rails at a couple of points. Unfortunately fixing this will probably require replacing the perspex of one of the straight sections.
As seen in the photos the only satisfactory way to keep the track sections together at the moment is to use electrical tape - which is counterproductive in terms of making the race track look awesome. Ideally I would be able to glue all the sections together into one really large track piece. This might make the track difficult to handle and store so I will need to consult with the rest of the project team...
Some of the pylons need to be moved around as they have been attached randomly at the moment with no thought for where the ones with extra attachment points should be so that the speed traps can use them.
These issues have to be addressed soonish, we have been asked to complete the project for 6th December by our supervisors, and many of the other project elements are now waiting on the track to be finished before they can start proper testing.
Therefore there is almost certainly going to be a 'victory' post in the near future!
Until then ...
Atmosphere shot, same as when only the first two sections were complete, but now with the whole track!!
Hmm, I was going for more atmosphere - being able to see the top track from below - but all I can see is the mess of loose wires!
All right all right, I am the first to admit that in the grand scheme of things my programming ability is only slightly higher than that of a large twig.
However, my programs, in particular the growing gargantuan that is the Blake Project wireless network base station and autonomous car coordinator, do get to do some cool stuff.
The coolest of these is using my computer's full capacity. There is a certain joy in writing a program that takes so long to run that you can have a cup of tea while it executes ... if you ignore the fact that it is only relatively recently that this has stopped being a common occurrence, and that most of the delay is due to your inefficiency anyway. The Blake Project base station is a prime example of this pride's initial warm glow swiftly followed by agonising pain of n-degree noob programming burns.
In order to service both a GUI and several external serial links the base station implements multi-threading, executing multiple scripts 'at once' (not really it just fills in all the empty space that usually fills up a single thread of execution). While it means I get to use fancy terms like 'concurrent processing' when describing system behaviour, all this filling of idle operations also means that the CPU utilisation can get fairly high as well.
Unfortunately it got slightly too high as seen below, and the program started to lag.
Multithreading in python is only able to use a single processor core. We can see it maxing out the leftmost core until I swiftly kill it.
The primary reason for this was that one of the older threads had been allowed to request access to shared resources a quickly as it liked. This is BAD news, because it can ask as often as it wants (or can - if we have to insist that computers are inanimate), not getting the resource shortens the time the thread does other stuff for before asking again because what it was going to to do relies on the resource being given to it. Think annoying 'are we there yet' questions which are incessant until the answer is 'yes'.
The spoilt child analogy naturally develops when the thread's response to actually getting the resource is to look at it, see that nothing has changed since last time it looked (the data it was looking for only came through every now and then), and thus immediatly close the resource and release it for others to use.
Only to immediately ask for it back.
The solution is to teach everyone some manners, introducing delays into the loops of which the loops are a part, and re-enabling 'blocking' of the requests (pausing the program until it is successful, which reduces the number of requests enormously - there were good reasons for me disabling this I promise). This is going to have knock on effects later on which may or may not be irrecoverable, luckily that is for future me to work out.
Threads with manners, now using the CPU cores in a much more respectable manner. I don't actually know which one it is running on!
In fact, there is a large chance that that is what my next post shall be about, we'll have to see!
