I’m planning on building a PC bot using a mini-itx board.
I’d like to use my ABB to manage the various sensors in this bot.
This is the question that I hope is not too dumb: Can I connect the ABB to the on-board PC using the db9 on the ABB and then write software for the PC to poll the ABB for sensor data, or is there some other, better way to do this?
Thanks!
Mike
madmaker.com
People (myself included) use bi-directional Async-Serial communication between the SSC-32 and a BotBoard all the time, so I can’t see why you’d have any trouble doing between a PC and a BotBoard. It should be exactly the same, but with the advantage of the PC’s higher baud rate.
Out of curiosity, what language are you using PC side?
Not sure yet.
I bought myself a copy of Visual Studio .Net before I left the commercial software game, so probably one of the “Visuals.”
Reason I was unsure of whether to use the DB9 or not is that, for example, when connecting the ABB to the SSC-32, I’ve always done it like Jim has documented - via pin 15, I think it was.
Thanks for the reply!
~Mike
madmaker.com
Not sure what the ABB wants, but be sure to check the serial voltage levels. The motherboard will want to use RS232 voltages that will damage a device expecting TTL. If that is the case and you do in fact have a mismatch, there are lots of RS232 to TTL converters you can purchase that will slip over a DB9 or if you don’t mind breaking out the soldering iron they’re pretty easy to rig up with a max232 chip.
Well, it has the DB9 header on it already that’s used as RS232 for actually programming the ABB.
I think as long as I can program the ABB to either listen to and respond or just plain periodically report sensor status via the programming cable connection then I can go that route. (And this is the part of the question that may be “dumb.”)
Anyone else done anything like this already?
~Mike
madmaker.com
I can’t speak to the voltage issue, but if you end up using C# I’d be interested in seeing your code!
I probably will.
Just found tutorial on serial communications which should be just the thing.
codeproject.com/csharp/Seria … cation.asp
As far as servos, I think I can just do like Lynxterm and write ASCII to control the SSC-32. Should be fairly simple to write some code to perhaps read the arrow keys on the keyboard and move the wheels forward and back. I don’t yet quite have a picture in my head of how to do the ABB portion.
I wanted to use a Cypress PSOC eval board to run my sensors and communicate serially to my Eyebot controller, I did buy a mini ABB and atom pro 28, in fact I might be able to use both hehe 
As my project progresses I’ll see how things look, thanks for the link to the tutorial, I know very little about serial communication, and very little about communication in general though I’m an EE (really disliked the one class I took in it).
Mike
In typical “it figures” fashion, it turns out that the nice, fairly straightforward method outlined above in the tutorial applies to .Net 2.0.
Of course, that’s VS 2005 which came out a few weeks after I purchased my copy of VS. Sigh. I found another way to do it that involves using the Win32 “stuff” instead, but I will probably call in some favors and purchase '05 so I can use the serialport class stuff.
I was a Web developer rather than an application dev. Now I get to teach myself how to use threads and other fun stuff.
Also did some reading of the Atom 28 user manual last night. If I interpreted it correcly, I could use hSerout and related commands and use the DB9 programming header, or use the regular, “Serout” type commands and one of the regular IO headers. I’ll probably do that just so I can keep the programming header open on the ABB. (For this I’ll need a TTL converter - forgot to mention that. ~Mike)
I have no idea where I found this originally but take a look: serialport.zip
It appears to be an early version of the code behind the System.IO.Ports SerialPort class that made it into .net2
The interface matches up pretty closely with the final release.
THANKS ANDY!!!
That’s the stuff. For now I can set this up on my “regular” computer at home since the the ITX board is still a few days away. What I might do is write a little program for the ABB to echo stuff to the LCD, and then I can compile the CSTerm app that’s in the proj in that zip file, and try out some ideas that way.
This is going to be a real shift for me. I guess I’m “old-school” in my programming experience. I see code like this as happening sort of a loop where you just keep checking for input until you get some and then do whatever you need to do based on the input, and then go back to checking. However, I think this would basically freeze up the main PC while it waited, so research tells me that I need to use threading to spin off a bit of code that listens at the port for input.
How does one thread “Hello, World?” 
Hope it helps out and isn’t too buggy (I haven’t used it and really don’t remember where it came from).
As for programming patterns that make sense around this sort of thing, if your going to have constant data exchange in an asynchronous manner, multithreading is the way to go. This class provides blocking reads that won’t return until data is available. To keep from killing the processor as you feared, the class puts the calling threads to sleep and wakes them when data becomes available and it’s ready to return.
While it’s not based around a serial port, the patterns are very similar. hex.zip. The Controller class starts and contains a worker thread which is in a tight loop around passing data back and forth between the bot, while other higher level processes are executed on different threads, sharing data with the worker thread. Read up on locking mechanisms because multiple threads accessing the same data simultaneously can cause surprising results.
Ugh, I had thought that I’d just do the “old school” method, as well, but that’s certaintly folly.
Thanks for the threading example, Andy.
Andy,
Did you write the Hex application? I like it.
It won’t actually build on my work machine, but I’m looking over the code now.
It looks like it would be pretty straightforward to adapt this to handle an ABB on one port and an SSC-32 on another. Would you mind if I used this as a starting point?
Out of curiosity, how many other folks are interested in doing something similar? (edit: meaning runtime PC-to-ABB communications/control via serial comm.)
I am going to do something like that as well…
Using the SSC-32 and some other Digiait switches that I have connected via USB.
I currently have the motherboard loaded with DSL (D@mn small Linux). working on getting the PSone LCD screen working with the onboard video card.
I also started getting the hardware for the Legs as well (buy pieces when the budget looks good).
Yes I wrote, and rewrote it, and am starting over again. If you’re interested in one of the more recent rewrites, I’ve just zipped and put up another version: vizlog.com/robot/shoreside.zip (requires .net 2)
Building and running it isn’t going to do much for you because it’s very specific to my custom controllers being on the other end of a WiPort, but if you’re interested in compiling it, here are the prerequisites:
Managed DirectX 9 from MS microsoft.com/directx
Sharp3D Matrix Math Lib from ekampf.com/wiki/index.php?title=Sharp3D_Math
Neural Net Lib franck.fleurey.free.fr/NeuralNetwork/ (Only used in the older code)
Feel free to do whatever you like with it.
malatory,
Out of curiosity, are you using USB to serial adaptors, or plain USB?
Well, it’s happening.
Spent a good part of the weekend working on my PC Bot. A bit more tinkering with the hardware installation and I’ll be able to start coding.
The build report is up on my site:
This should probably be in the Projects thread now, but it’s getting late, so that post will have to wait until tomorrow.
Very nice!
You do good work. I love the rivit idea, it really makes it look clean and professional looking. Nice job with the photos.
Well, I may be in over my head software-wise.
I’m a Web (classic ASP, unfortunately) and SQL developer, not an application developer.
It’s frustrating to have an idea of what you are trying to accomplish but have no clear idea how to get there.
I could probably write a decent spec for the code I want to produce, but writing the code itself is proving frustrating.
