The PCBs arrived in the post today, turns out the slow boat from China has probably been upgraded to a Hydrofoil. With the PCBs here the final construction of all the ODOTS units (I have parts for) is now under way, with a quick order to Mouser (sorry RS, they had nicer enclosures) to grab the final bits and pieces. The boards that have now been put together (Two in a couple of hours) both work well.
The PCBs have come out really rather well, and current testing indicates that I only made one massive mistake, so all is looking good. (Not least because the error is just a missed connection, easily fixed with a sneaky extra wire!). I am amazed how clean the manufacture of them is, and attaching components has been easy enough that I have vowed to never again use Protoboard on anything that I need more than one of, never again.
So nice, so clean, so ... green.
The improvement over the strip board in visual quality is incredible, as is the reduction in board foot print (1.5 cm less length!). Additionally because there are no wires to solder in (apart from the one to fix the missed connection), and a very limited number of mounting points (all of which are labelled), putting the board together is straightforward. While the stripboard took a day to put together and was tricky to debug (as well as having lots of error prone wires), the PCB goes together in an hour and is neat enough that debugging is less daunting.
PCB > Stripboard. Smaller, neater, certainly more professional.
In the image above the PCB has had its RFID unit added, and the wires have been made to loop over the not-yet-present battery. The two boards put together today have really brought the end of this stage of the project into view. Of course, I managed to plug one of the board into an Arduino board (acting as a serial bridge) backwards and now the Arduino board (my only suitable one) has stopped talking - but that is a problem for another day!
Increasingly precise perfection approximations...
Led's mounted on the reverse side so that they will stick through the enclosure.
Haha! I followed through on my PCB threat - and now have a bunch of them waiting to be made somewhere in China. Fantastically using them actually brings the cost of the project down as with the introductory discount they came to less than £1 per item (including shipping). Given that this is less than the soldered mess on the strip-board it is a bit of a no-brainer to use the PCBs.
Given I had already put together the schematic to design the strip-board layout it was relatively straightforward to design the PCB. The massive advantage of PCBs is how close different signals can be routed. This and complete routing flexibility on both sides of the (two layer) board mean that the layout uses 25% less area with a large area with only flat components (for the battery to fit onto). Additionally the LEDs and pinouts are all now in far better locations which is a real help.
KiCad Rendering, gets even better when you actually provide full 3d models for your components!
The Worms - this step was so straightforward, I don't know why I have not done it before.
The things this design still misses is attachment points (not a problem if you just use hot glue...) and an on board Serial to USB converter. Given how straightforward the design and order process has been I may opt to move to surface mount components rather swiftly. This will reduce the required PCB area drastically (everything will be smaller), leaving space for drill holes and extra hardware, and the cost reduction (everything should be cheaper) will mean I have budget room for extra hardware. I may even have to start considering integrating in the RFID stuff and actually thinking about power consumption.
NOOOOOOOOOOOO - too polished, too complete, I NEED THE HOT GLUE AND 0-OHM SOLDER BLOB RESISTORS. Darn you engineering maturity, you can't get me that easily!!
This is actually quite a nice step for me. Previously I have always relied on Monsieur Miroshnikov to throw the PCBs together and order them (generally while I dove deep, deep into a pile of code), it is going to be a bit of a change to only have myself to blame when the power rails short out!
Next up in the immediate future is to sort out the enclosures for the proof of concept hardware. The new PCB design should permit easier packing into a box (see my comment about batteries). Everything will probably end up being be glued to the lid of a standard enclosure (with flanges for attaching to controls) just because that keep everything accessible. Of course the best bit will be drilling holes into the weatherproof box to let the LEDs peek out!
Making a semi-final product today allowed me to finally start taking semi-final power consumption measurements. These were done by inserting a small resistance into the positive power supply connection and then measuring the voltage over it (my multi-meter was not sensitive enough for direct current measurements).
These were terrifying, unmodified the board pulled almost 60mA in its idle state, giving it just over a day of life on a single 18650 lithium ion cell. This is clearly far less than I had hoped and indicates that power consumption is now something I should be worried about. Off we go on a hacky adventure!
First off was removing the 5V regulator which (given it had been shorted out anyway) was just wasting power. That saved a full 5mA of consumption.
The next step was to stutter the RF field from the reader, adding periods where it is turned off, for instance when the microcontroller is doing non-RFID things. Additionally the addition of a sleep period to the polling cycle (with the RF field off) massively reduces the RF field duty cycle and in tests did not really change the user experience (and I was looking for it). That saves another 10mA and being more aggressive on the sleep saved a further 10mA. This pushes the time on single cell up to 3 days.
Clearly I have been optimistic that the cells will actually be able to discharge their full rated capacity, so maybe 1.5 days is more like it. This still allows the proof of concept to be programmed the day before any field trials and left on over night without having any danger of it running out of power!
The interesting thing about this development is that it indicates the next big development required of the ODOTS on its path to becoming ready for certification (certification being expensive and something I only really want to do once in the future)(And something that will be necessary to bring the ODOTS, or derived system, to the mass market). Frankly the current hardware architecture is not optimised for power consumption in any way at all, the use of Arduino in particular is a bit of a liability as it does not provide fine control over AtMega peripheral activation. This may be why I eventually shift over to a different architecture in the future. While I have made an effort to tame the ravenous beast that is the RF field the MRFC522 (or one of its alternatives) will provide methods for reducing its appetite further. I have commented in the past about the ability for the ST Micro chips to passively detect tags, this would be ideal as it would massively reduce the power consumption with potentially little (randomised) impact on competitor visit recording times.
I suppose my dreams of networking the ODOTS units with LoRa and implementing a 6WLoPAN network are going to be a long way off indeed!
The first stripboard prototype has now been put together and it was worth doing. It works, but has taught me a lot about how the proof of concept design is likely to go together.
Prototype, mk 2: "Ever closer to approximate perfection"
The strip board module, with the AtMega chip, clock, leds, buzzer, voltage regulators and many many pinouts.
First observation from putting it together was that it took most of a day, and was incredibly fiddly. The build time may come down with repetition and the fiddlyness could be remedied with an extra bit of clever design, but for something I want to be straightforward to put together, it is not acceptable. Therefore I may have to make a diversion to PCB land, which will delay the full completion of the proof of concept system (as as adding cost) but will make the design much easier to build.
A good test for new hardware is to use it. Typically this test is used when you have not put in good testing points, test procedures, or you are bored and want excitement. Also typically new hardware will fail this test and you have to spend twice as long fixing it. Test procedures for the strip board layout included (in order, and initially with no power or DIP chips):
Testing for Power-Ground shorts (good for not blowing up components when you plug it in).
Test for signal-ground shorts (same).
Test for Micro-controller to endpoint signal wire/trace continuity.
Test to see if the voltage rails had the right voltage (with battery plugged in).
Then the following functionality tests were performed (once the DIP chips had been socketed, and the micro-controller programmed):
[PRIOR to all other tests, the AtMega chip was used in the breadboard setup to read cards and demonstrate basic functionality, proving it worked)]
Test to see if the clock worked (and the buzzer), performed by waiting a minute to see if the 'I-updated-from-the-RTC' blip activated.
Test to see if the serial interface (through the now empty UNO board) still worked.
Test to see if the RFID reader worked.
Absurdly the tests were all passed until the last one. The brilliance of not doing the 'plug and go' test was that I knew the RFID reader/wiring to the RFID reader was at fault. Plugging the RFID reader back into the breadboard setup showed it was still working, which meant the problem was in the wiring. Quick testing indicated one of the pins was shorted to ground, which it was due to some splashed solder. Fixing this meant the device worked normally, but such a fault indicates that even when you know the design well, test thoroughly and have plenty of soldering experience with these sorts of components it is still tricky to get a working board. If others are to be able to replicate the design it has to have a fair chance of working first time with no debugging, something this approach is evidently unlikely to achieve.
I lie when I say all tests were passed, the 5V regulator was actually counterproductive with the 5V supply - I had expected it to operate without any voltage drop but it appeared to just not work! Therefore it was just shorted out, and will be in any future designs that use the magic Poundland power supplies.
The placement of components is also an issue. Due to the nature of the Strip board, placement of components (when optimising for reduced soldering) is not exactly free, and as a result (as you may have spotted in the photo of the board), the board is not set out particularly well. The LEDS are recessed, which is not ideal if they are to be visible. The Header pins are spread out all over the board, not ideal for happy wiring in the final enclosure. (Though to be fair I have not thought much about how the final enclosure will look yet). Moving these bits around requires more flexibility in routing than the strip board can give me, which does not bode well for it!
To sum up, stripboard: meh, PCB: possibly worth the extra expense...
Next step will be to think about the enclosure, then go off and order the enclosures, RFID units and PCBs. Then take a trip to documentation land while I wait for them to arrive!
The last couple of weeks have been spent positioning the project for its final sprint (before the long, long cool down of debugging and documentation correction). This means that this afternoon I sent off a hefty order to the component people to request most of the bits I will need to put together the Proof of Concept!
The first thing to finish off was the interface software, the bit running on a big computer which will allow people to configure how the ODOTS operates, download competitor card data and so on. This is now all done and partially debugged (more on it in another post).
The second thing was to transpose the hardware design to a strip-board using an atmega328p. This is the bit that gets my inner Electronic Engineer very happy, bugs can be solved with extra wires and spotted with your nose, design turns into connect-the-dots and the seemingly random (but essential) components all work their way out of the woodwork. Another advantage is that I now know how much the proof of concept will cost to make. While component costs come to £20.51 (such precision, so exciting), which is more than my original goal, I am not to worried, I have not made an enormous effort to hunt out cheap components so it is likely in another revision many pounds could come off that total.
The design has been put together in KiCad (k-eye-cad or key-cad depending on which side of the flame-war you sit) a free PCB design tool that can also do strip board designs quite well - just by putting all the back-copper traces horizontal! In the layout below Red is being used for the provided strips, while Green is being used to represent all the wires that will need to be soldered on the top side.
The layout so far - now waiting to see which connections I missed.
In the Rubik's Cube project I used protoboard, a variation on strip board where each pin hole is not connected, whereas in strip board they are connected ... in strips.
Strip board (or Veroboard)
Proto-board (or Matrix Board)
This reduces the amount of soldering required, and number of funny bits of wire on both sides of the board. Both do the same job of acting as a permanent bread board with solder.
I am fairly happy with the design as it is, it is fairly compact (if unable to tessellate nicely in the standard strip board sizes) and appears to have a minimum of random wires running large distances around other components.
The next part of the project is where some of the final hardware products will come together which means things like the power consumption, physical size and usability will move from predictions to measured quantities (or qualities).
--------------------------------------------------------------------------------------------------------------------------
For those following on from my previous post, he documentation has progressed as expected, currently sitting at 40 pages of informational goodness - LaTeX really helps with long documents (no massive document redraw when you move a figure/table/sentence around!). Most of the software has now got full documentation with all of the interfaces specified. The only big things left to do are explain the hardware design (including the beautiful layout above) and some user guides. Hmmm - writing those down made me think that actually those could end up being quite large pieces of work.
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.
So to make your incredibly cool schematic more manageable, splitting portions of the system into blocks is vital! Below I have a quick tutorial for how to make a hierarchical sheet (took me a couple of google searches to figure out at first).
1. Go to... Click create Hierarchical Sheet and draw a rectangle of appropriate size. The size of the rectangle can be changed by right clicking on the sheet symbol and selecting "Resize Sheet".
2. Right click on the newly created block and click Enter Sheet.
3. Now you can create a lovely schematic for one of your system's sub blocks.
Now you may ask, "Andrey, how do we link this schematic to the top schematic?".
Well, it's quite easy. Simply click "Create a Hierarchical Label", write the name of your I/O pin and connect it to the circuit. Right clicking and pressing "Leave Sheet" will get you back into the top-level schematic. There you can import the labels for the sub module's ports and move them to an appropriate location on the block's symbol.
With this approach, systems of arbitrary complexity can be designed with ease. It's quite easy to split the daunting task of a huge system into manageable blocks.
Oh and another trick. If you made a circuit on the top-level (or any other sheet) that you want to copy into a hierarchical sheet, the steps are outlined below:
1. Select the circuit of interest, right click and press copy selection.
2. In the target hierarchical sheet click paste and the original circuit will appear.
3. Original circuit can now be removed from the top-level schematic.
Hopefully this brief tutorial will help those of you starting to create designs with lot's of ICs, buses and passives.
Your local digital designer/systems engineer ;) (Not qualified yet...)
-------------------------------------------------- EDIT: Turns out the sheet symbol can be re-sized, duh! Also I was told the power connections carry through the hierarchy and hence, hierarchical labels for "GND" and "VDD" for example, are unnecessary.
