Catch-up: Software and PCB Production

I must apologise to any readers I may have, as well as myself, for letting the blog slip for two weeks.  I've mostly been working on software, but have been doing some PCB-related stuff too, and I didn't think there was much worthy of commenting on for now.  Anyway, here's what's been going on for the past two weeks...

PCB Production

I submitted the PCB Gerber files to our lab guy, and provided a drill file so he could use the CNC drill to save me some time later.  This was the source of much trouble, but I think everyone learned something because of it.  Anyway, most of the holes were to be drilled at 0.8mm by the CNC drill, and I would open the larger ones out manually.

Before submitting the job, I checked a print of the board on paper against my Mini-ITX template - I don't want a board that I can't mount.

I had a couple of days off, and on my return, the was informed that there were problems with the PCB - because of the inaccuracies in the printer (mostly slip and misaligned feeding of the acetates), the drill holes wouldn't line up with the etched board.  At first it appeared to be a scaling issue, but on further inspection of the acetates, it seemed that the board wasn't even a rectangle.  The printer had fed the acetate on a diagonal, and slippage had allowed it to align straight when it reached some mechanical limit.  This made a very slightly warped board, but enough so that the drill holes wouldn't be in the right places.  Due to the small pads used by KiCad (which I was warned about anyway, because of the lack of copper to solder to), the drill holes could be far enough off the pad to make it into a C shape, and make joints both mechanically and electrically unsound.

Enlarging the pads proved to be a longer task than expected - I created new packages (copying the old ones) for just about everything.  I also changed to elongated pads for some things, like the L298, to provide more copper to solder to.  After all of this, my final decision (to prevent the possibility of wasting board and adding to the spent budget) was to spend as long as necessary drilling the holes by hand.  I've since done this, and it took me a couple of hours at most.

Anyone working with a prototyping system rather than professional PCB houses should keep in mind that there may be process issues, as I discovered.  The extra time taken wasn't inordinate, though the delay was significant.  I did use the time wisely, though, as will be seen shortly.

The PCB is currently sitting with all (14) of the vias soldered (no THP!) the power and float charger sections complete, and most of the AVR section done.  I've ordered some more bits, including the DC-DC converter needed to run the Mini-ITX computer board off the lead-acid battery, which has also been supplied.

Software

I've taken advantage of the free time in which I can't really progress with the hardware to write some control software for the robot.  Right now, it doesn't actually do a whole lot, but the front end is pretty much in place now.

The software is written in C++ using SDL and OpenGL.  I've programmed using a RAII style, which is quite a new thing for me - I've been aware of it but hadn't used it properly until now.  Basically, you wrap an init...uninit section in a simple class, then make an instance of that class in the section of code instead of using the functions themselves.  It adds to the safety of the code, because (for example) a function using an init...uninit might return before the end of the function is reached.  By using a RAII style wrapper, the destructor will call uninit before the function terminates.  It's slightly odd to use at first, especially for some things, but it seems to make good sense.

Here's a screenshot for me to talk about:

WheelieCommand Software - basic GUI

As can be seen, the interface is pretty simplistic.  I intend to add a webcam feed instead of the blue background - that's why the graphics are done in wire-frame.  The 2D elements are designed so that they can easily be made slightly transparent.  From the top, you can see several features:

• A bearing indicator, which has a variable field-of-view, so hopefully it will be simple to match it fairly accurately to the webcam (ignoring nonlinearities) - this shows 'N', 'S', 'E', and 'W' at the cardinal directions, and numbers from -180 to 180 degrees;
• Motor indicators - these will probably show angular velocity of each motor.  Left is red, right is green, like all the wiring and tape on the robot.
• A central crosshair, and smaller mouse crosshair;
• Floor sensor indicators;
• A map (a little styled on Zelda 64), showing the robot in the centre on the appropriate bearing, and target markers in place - the elongation is so that their bearing can be set if desired;
• A 3D view in the background - the octagonal chassis is outside the current field of view, but is implemented, the target markers are visible, and the camera can be repositioned on the robot, allowing for correct camera setup.

The software is currently wired to allow the user to drive around the space using the mouse.  When I get round to it, it'll use SDL_net to connect to a server on the robot, and then will operate through the actual robot.  It will also need to exchange data with the robot to get the current markers, along with some other information like floor colours and wall data - I plan to record the floor at 1cm intervals and draw this on the map.  The robot will 'discover' three lines at once, and it might be useful to build up an image of the floor.  The same array can be used for recording wall positions, at there's no way the floor colour can be recorded in a wall.

My plan is to use the robot's computer to do a lot of the work, acting as a server.  The client, on the control PC, will then be able to control it, and if the system is disconnected, the robot may continue working - it might be sensible if it stopped where it is, but it would be very annoying if you'd set in a course and the link got dropped, and it wasn't still there afterwards.

I think that's just about all I've got, for now, and I will endeavour to do better at updating this.  Hopefully there'll be plenty more hardware stuff - I like talking about that, and I hate writing about writing software.