Don’t let it scare you away! I’ll be happy to offer whatever help I can 
It’s been said that the software part of robots is the longest and hardest road. It can be very challenging, but with persistence and patience, the rewards can be wonderful.
Keep trying; Tomas Edison didn’t invent the light bulb on the first try.
I second that.
Besides, if I can slowly manage to get the programs that I need working right (and my only previous knowledge is a smattering of the MSDOS QBasic), then you definitely can.
Here’s my method to programming:
When in doubt, I press F1.
When frustrated with that, ask questions.
It’s best to find a buddy who programs in your language, or a similar one and pester them with IM’s all the time.
(MWGemini and sometimes Andy are my buddies.)
I guess now I’m not even sure where to start.
I’m asking myself a lot of questions like, “do I need to define a communications protocol first?” And, “In a forms-based world, where the heck would you put code to handle autonomous behaviour?”
I probably need to set a reasonable first goal, such as perhaps being able to drive the thing around using a joystick connected to the offboard PC.
Yet another brick wall.
Now I have a basic Windows app that runs on my desktop. It reads the joystick and runs the motors accordingly via the SSC-32 when connected via the serial port.
However - I may have miscalculated. My plan was to install this same app on the onboard PC on the bot and, with the joystick connected to the desktop, run it via Remote Desktop or VNC and control it that way.
The problem is that the app can’t see a joystick connected to the desktop when it is run on the bot.
Whoops.
Any ideas for getting around this?
I think I have my own answer now.
My plan is to split the funtionality of my joystick test app into two pieces.
One will be a client and live on the remote PC. It will read the joystick input and just puke that via a socket to the server app running on the bot PC, which will take that info and send the appropriate commands via the serial port to the ABB and SSC-32.
As it gets more sophisticated, the client can also display sensor info and such that the server app can send to it.
Nice piece of vapor-ware, no?
that’s precisely the direction I’m headed with my rebuild. I’ve got a gumstix on board with a wifi connection. At least at first, all the high level control code is going to be PC/shore side with the gumstix slaved to it.
That’s very nearly what the code I posted before is doing, only what’s on the other side of the network is simpler than a full blown PC.
Success!
Basically I cheated. I took a sample “chat” program from a c# sockets tutorial and morphed that into my client-server app.
I can now control the motors on the 'bot via joystick from a remote computer.
The client runs on the remote computer. It reads the joystick, creates pulse values for both motors, and sends that info to the server running on the bot PC. The server passes it to the microcontroller via a serial port.
that’s not cheating
Depending on what mix of performance and ease of use you want, take a look at .net remoting. The performance will be lower than using the sockets directly as you are, but it allows you to do method invocation across the network. The performance will easily be acceptable for things like joystick control.