Progress

So, once again, it's been about a week since I posted, and plenty has happened for me to comment on!  I've spent a fair amount of time mentally arguing with myself about various things, but I've actually done some work, too.

Hardware

As usual, this is the bit that I'm most interested in writing about.  All of my bits have arrived, which is very nice, and allowed me to build more of the board.  Now, there are only two parts remaining - the RS-232 dual transceiver, and the USB serial port.  The float charger is still missing a resistor, because I need to figure out a good value to use!  I've mounted the board on the robot now (so I'll need to unmount it again to finish it off), and it works fine - the test program works the same as it did on the breadboard.  The AVR isn't using the crystal yet, but that should only be a matter of changing the fuse bits.

I've wired up and tested the DC-DC converter - it's not solidly mounted yet, but it sitting in a conveniently neat arrangement with the battery and hard disk.  The onboard computer runs absolutely fine from it, and I tweaked the output voltage to get it just about bang on 12V.

Unfortunately, I think that's about all I can say about the hardware, for now.  I'll get some pictures up with my next post.

Software

Fortunately, the software I've been writing isn't too boring, because I've been learning.  I used SDL_net to write network communications wrappers.  So far, I've tested the TCP connection, and it seems to work really well.  I did have a problem for several days of data apparently going missing.  It turns out that the problem was c-string related - the data was there, but it was hidden behind a null character.  I've since rewritten the wrapper to deal with this issue - now the high-level bit works with strings as buffers, and treats null characters as part of the data stream.

I've just about figured out how the robot and control PC will communicate, and how the onboard computer will communicate with the AVR.  Control signals will be sent on a TCP socket between the control PC and the robot.  On the robot, this will change some internal state flags.  The onboard computer will check the state of the AVR system, and will send commands to the AVR to put it in the same state as requested.

I was originally planning a multi-user server, but at the moment I'm going to focus on a single-user one.  If I write it properly, it shouldn't be too hard to change it later, though some consideration would need to be given to who gets to control the robot's state.

On the advice of my supervisor, unless bandwidth is an issue, all of the communications will be in text format.  This makes debugging really simple - I've found that telnet serves pretty well as a TCP console (though it isn't actually a raw TCP console), and I have a serial terminal program too.  When (if) I get round to doing a video feed from the robot (which I really want to do), I'll probably resort to feeding binary data, as images require a lot of bandwidth anyway.  This will be on a separate socket though - I plan to use a different port for each UDP data stream to keep them separate, so my applications won't need to decipher which packet goes where.  The only place where that will be necessary is on the serial link.

I did consider using SLIP (serial link internet protocol) between the onboard computer and AVR, but dismissed it quite quickly due to the expected complexity in writing a TCP/UDP stack for it.  It would be pretty cool, though, and would allow the AVR to talk to just about anything that could run SLIP.  For now, I think simple serial comms is the way to go.

To build the server's software, because it's 32 bit (unlike my laptop), I needed to build it on the server.  To avoid installing an IDE on it, I searched for a tool to convert my project into a makefile.  I came across two tools - cbp2mak, used to produce the Code::Blocks nightly builds, which wouldn't build on my laptop, and cbp2make, from sourceforge.net, which built with no problems and worked brilliantly on the server.

I've got a meeting in a short while, and I think I've said enough for now, so I'm going to leave it there.