Doug Leppard (DLeppard@CCCI.Org
Benjamin Leppard (Benjamin@Leppard.Com)
This is the eight in a series of articles outlining the steps I have taken to build my robot. These articles are focused on a robot that may compete in the Fire Fighting contest, be able to roam around the house, but mostly be a fun learning tool. The 68HC912B32 is the processor, so these articles will be on interfacing to the B32 various mechanical devices and sensors using SBasic as the programming language.
Note, I renamed my robot from Onesimus to HC12. Onesimus is from the Bible, someone that was useless and became useful. I thought this would be symbolic of my robot. But people had a hard time pronouncing Onesimus and when I got my voice board going the robot had a hard time pronouncing its name. So its new name is HC12, named after its MCU. Plus HC12 is a robot sounding name.
"Setting the Stage for Building a Robot," we set goals for the robot and did research. From the goals and research we will make fundamental decisions on what our robot will be like.
"Choosing the CPU, Language and Basic Shape," using our goals we choose what microprocessor, language and what the fundamental shape of the robot.
"Motorolas S-Record" looking at the S-Record format that Motorola uses to load data and programs.
"Booting up the 68HC912B32 for the first time" described in detail how to boot the B32 up and run a program.
"State of the Union" gives an overview of what state the robot was in August 1999.
"Multiplexing Five Sonar Modules" goes into how to and the reasons of putting five Polaroid sonar transducers and wiring them together.
"Drivers for Sonar & Mapping" shows the software to drive the sonar units, and how it can map a room when tied to a PC.
"Using B32's Interrupts IRQ and XIRQ" using the B32 interrupts to count the robots wheel encoders.
Early on I knew there must be a way to communicate to the robot while it was in operation. The number one reason for telemetry is for testing and debugging. As the robot is doing its thing and it is in error, you need to have data what it is happening in its program. I can't imagine trying to debug the robot's program without having some idea what is happening with its program. Secondly, you may want to allow the robot to communicate to the world. For instance, in one of my previous articles, (Drivers for Sonar & Mapping), the HC12 transmitted back to the PC its sonar readings. The PC then drew a map of the room. Also, I can give commands to the robot via the PC and modem
As a side benefit, it made the downloading of the robot's program much easier. Before the radio modem, each time I wanted to load a new program I had to hook up a serial cable to the MCU, which by design was located in the second layer of the robot and hard to get to. But, using the radio modem I was able to load the data without having to hookup the serial cable to the robot. In fact the only connection I need to make to the robot is the programming voltage needed to program flash memory.
By far the most important use of the radio modem is for testing. When I was making the Fire Fighting program, I would put debug statements in the program. I would make a run and collect on the PC the debug data. It was invaluable in knowing what went wrong and what corrections to make. Programming in Sbasic, all I needed for debug statements was simple print statements.
Early on in my robot plans I knew I needed to have telemetry on the robot. I knew it would be absolutely necessary for testing and just for being a cool thing to have. But, it was months before the robot got off the bench, so it was never important because the serial cable was always connected. But once the robot got off the bench I saw I had to have something. A Nuts and Volts article talked of the Ming transmitters and receivers. I bought two pair to transmit and receive both directions. I soon realized that I needed the transmitters working on different frequencies if the data was going to be passed both ways.
So I hooked up one pair of Ming TX99 and RE99 to transmit data back to the PC. It worked pretty good at 1200 baud (1.2kb). But that was slow in getting across the data wanted. Also the data would often drop out. I found I could run at 4800 baud and get the data at closer the speed I wanted, but that was still slow for the amount of data I wanted to transmit and the drop out rate was even greater at the higher speed.
The Ming transmitters and receivers are fine for small applications at slower speeds and short distances. See www.rentron.com for Ming and other remote control devices.
But I wanted rock solid data transmitted at higher speeds. So I stated looking for other solutions.
Last summer on the SRS list server, Karl Lunt mentioned he got a pair of radio modems from Innomedia. The specifications sounded good, and if it was good enough for Karl it was good enough for me. I happened to be in San Jose at the time and picked up a pair from Frys for about $150 (on sale at Frys, and as far as know they no longer have them).
The modems were designed to remotely connect a printer or two computers. My unit had one serial and one parallel port. It came with Windows software to run the base station. It operates with 900mhz spread spectrum transmitters receivers.
I was so excited to bring them home to HC12 and hook them up. The first thing I discovered was that the modems worked with Windows software and I couldn't use it with the software, I wanted to use, some of which was DOS based. I contacted the manufacturer Innomedia and ended up talking with Adam the tech. He was extremely helpful and said he had heard many people have used these modems for robotics.
Note this was taken from Innomedia's web page on this modem. See www.innomedia.com/wireless/products/infowave_specs.html for complete details. I have an older version of this modem but they are basically the same. Below also talks about the 2.4 Ghz version, which I am not sure are available here in the USA.
InfoWave is a direct-sequence spread-spectrum data modem. It can be customized to operate in 902-928 MHz or 2.4-2.4835 GHz at data rates of 85, 96, or 250 kbps. An 85 kbps version of InfoWave has been certified by FCC and Industry Canada for unlicensed operations in the ISM frequency (902-928 MHz) band.
902-928 MHz or 2.4-2.4835 GHz ISM Bands
Digital direct-sequence spread-spectrum technology
Serial port (RS-232) for easy host interface
Point-to-point or point-to-multipoint applications
Simple command set for fast system integration
Air data rate at 85, 96, or 250 Kbps
Auto-scan to select clearest channel
Auto-channel change in the presence of interference
Programmable PN code
HDLC-like data link protocol for error control and flow control
Adjustable packet size for optimum throughput
|Model||IW9208-85 / -96 / -250||IW24208-96 / -250|
|Frequency Band||902 ~ 928 MHz||2.4 ~ 2.5 GHz|
|Output Power||100 mW||100 mW|
|Data Rate||85 / 96 / 250 Kbps||96 / 250 kbps|
|Number of Channels||10 / 9/ 4||29/ 12|
|Sensitivity@ BER=1*10-5||-98 /-98 / -93 dBm||-98 / -93 dBm|
|Distance (open space)||1000 / 1000 / 800 feet||1000 / 800 feet|
|Host Interface Type||RS-232 Async. Serial|
|Host Interface Flow Control||RTS/CTS Hardware|
|Host Interface Data Rate||Up to 115.2 kbps|
|Host Interface Auto Baud||Yes ( 9600 ~ 115200 )|
|Host Interface Command Set||WM Command Set|
|Power Supply||DC 4.7 V ~ 5.5 V|
|Power Consumption||Transmit||250 mA|
|Size||120mm x 83mm x 15mm|
|Operating Temperature Range||-10°C ~ +60°C|
|Storage Temperature Range||-40°C ~ +80°C|
I tested the modem's distance by writing a program that sent data to the PC that I could watch for errors on the screen. While the robot sat on the floor of my two story house, I walked until the modem gave up. I was over 200 feet away, it had to transmit through several walls of the house, with the bottom floor of the house being made up of concrete blocks.
Never once did the modem send bad data, it would slow then get through and send chunks of data. When I moved out of range it lost its connection and stopped. So what I have seen is that the modem does not send bad data even when on the fringe of connection, it has a buffer built in and will catch up if possible when it has a better connection.
I did not test the open air abilities of the modem.
It's dimensions without the case are 3 7/8 inches wide, 4 3/4 inches long (with antenna sticking out 5 1/2) and 5/8 inches deep.
I have step by step instructions on how to set up the modem to be used with your PC and robot. They are all contained in the document "Infowave setup instructions.pdf". Go to Egroups.com and the group SeattleRobotics and look in the Files section under InfoWave Modem to see if there are any updates of these files. The helpful files are:
|Infowave setup instructions.pdf||Contains my step by step instructions in setting up the modem to work with your robot.|
|CommandSet-C0.pdf||Gives details for the WM command set. For version VCO, which is my modem.|
|CommandSet-C5.pdf||Gives details for the WM command set. For version VC5.|
|InfoWave.PDF||Gives details for the WM command set. For version VG0.|
|InfoWaveRS232.PDF||Shows how to set up Infowave 9208, 9210 as RS232 replacement|
|IW9208UserManual.pdf||User manual for modem 9208, which is the one I recommend.|
|IW9209&10UserManual.pdf||User manual for modem 9209 and 9210, which I have no experience with. Both are designed to work as a serial cable replacement. I imagine they have less flexibility and certainly you can not have more than one robot talking to base.|
|Pn_table.txt||Pin table. See Infowave WM commands to control the modems.doc for explanation.|
There are three types of modems described above. I use the 9208 version (or at least an older versions of that). Adam Huffman of Innomedia has been very helpful in working out how these modems work. Below is his description of each of the modems:
"The model 9208 is a multi point connection. You can have one master (home) unit and up to 254 remote (clients) units. The master can only connect to one remote unit at a time. There are no simultaneous connections between the master and multiple units. You can have up to 3 masters in close proximity. This model requires a command set to establish connections and disconnect. Then you have to provide you own software or commands to execute or retrieve data to the remote units.
The model 9209 is a PC to PC connection. This unit does not require software. It makes a connection to the other unit when powered on. This becomes an RS232 cable replacement and connects two PC's or PC like devices (DCE to DCE). You can install networking software and create a network between the two computers or you can make a direct connection using laplink or HyperTerminal. This is a point to point connection and does not allow multiple units. (Author's note, it may not allow you to change the baud rate on the fly which was important to me. My boot loader is stuck at the baud rate of 9600 but my programs run at 38400 so once my program is run the robot sets its baud rate at 38.4kb and the modem adjusts. The 9209 may or may not do this, so check it out before buying.)
The model 9210 is a PC to peripheral connection. This unit is also a point to point connection and does not support multiple links. This is a connection between a PC and a modem device (DCE to DTE). This becomes an RS232 cable replacement. This too makes a connection when powered on and does not require software. (Author's note, your robot can be wired up as a peripheral device or as a PC connection, so it may not matter which one you buy, but again look into it.)"
I will not go into detail here on hooking the robots to the modem software wise, for the document, Infowave setup instructions.pdf, handles that. But some following points will be helpful:
|This is the modem connected to my notebook computer. The modem is
powered off the notebook using the keyboard connector that has a 5 volt supply on it.
It makes the whole operation portable.
|You can see the modem mounted on the robot. I have taken off the
plastic case to save room.
There are four switches to the left of the modem. Switch 1 controls the MCU to tell if it is to program the flash or to run a program. Switch 2 controls if the MCU and associated electronics runs off the onboard power supply or the external supply. Switch 3 controls the the power going to the modem, whether it is supplied by the onboard battery or external voltage. Switch 4 keeps signals from getting to the modem until it is ready for them.
Hooking the modem to the PC was a piece of cake. Just plug in the cable and make sure your program had the right com port. I just changed notebook computer which I do most of my robotics on. It has no serial port and I have a Xercom USB to serial converter and that works great.
Hooking to the robot is slightly more complicated. The document "Infowave setup instructions.pdf" goes into that with some detail. Biggest thing is you get a short course in RS232 (serial) line definitions. My recommendation is to wire your modem to your robot in the DCE mode. Only difference between DTE and DCE is the transmit and receive lines are switched. See the detail in the modem documentation for how it should be wired.
|As you can see in this picture to the left, I just got a male serial
connector to connect to the modem and ran wires to the appropriate places on the
robot. Note, I did have the RXD line go through a switch so I could keep
signals going to the modem until it went through its boot process to solve its problem of
getting data before it was ready. Again this is because of a flaw in the modem
because if it gets signals before it is ready it hangs.
See the table in "Infowave setup instructions.pdf" for wire connections.
For power I just got the appropriate size power connector from Radio Shack.
Most of the time I have the antenna laying down so that it will not block the rear sonar. I have modem mounted on the board so I can see the lights and it seems better protected that way.
I use the Sbasic print and outch commands to output data to the modem that goes to the PC. The same way I did when the I had a cable hooked up. I use the inkey() command to get data from the modem. It is great because I can send commands to the robot via my remote PC which made it more fun and testing was so much easier. When testing a routine like PID where you had to adjust variables, I would run the routine have it stop, from my PC type in changes in the variables and have it run the routine again. All without reprogramming the robot and only changing the variables found in RAM.
Steps in setting up the program to use the modem:
'--------------- following code run in initialization routines ----------
'Set up the port speed
poke sc0bdh, 13 'sets port speed, 13 for 38400 26
for 19200 baud, 52 for 9600, 417 for 1200
pokeb sc0cr2,$0c ' Enable transceiver
'above is in my Rinit.lib file that runs first as part of the robot boot up
'-------------- this is code found in Rmodem.lib and is called by main
'routine for setting up modem
connect_modem: 'connect modem with ws1 command and wait until OK (sent by modem itself)
'note this must be in the text mode, if not run the
'wmen command to reprogram into text mode. See WM command document for details.
temp_lib6=0 'temporary variable to say what phase we are in
'note modem_status uses temp_lib6
if usr(modem_status)=1 'wait until modem ready, does this by checking DTR/DSR
wait_lib=intcnt 'check if it is still on 100ms later since once it is
'turned on it has a pulse on for a short time
do loop until usr(compare_intcnt,wait_lib)>100 'this is a delay subroutine that waits 100ms
if usr(modem_status)=1 'wait until modem ready
loop until temp_lib6=1
gosub modem_command 'phase is 0 give it the WMS1 command to connect to other modem
ch=inkey() 'now we will look for the OK
wait_lib=intcnt 'as long as there is input, keep looking
ch = ch AND $ff
if ch='O' 'O of the OK found move to find K
if ch='K' 'K of the OK is found then ready, else any other letter reset to phase 1 to look for O
if usr(compare_intcnt,wait_lib)>800 'try again if taking too long
loop until temp_lib6=3 'phase 3 must have found OK
modem_status: 'usr(modem_status) returns 1 if ready 0 if not ready
if peekb(portdlc) and %01000000>0
outch 'w' 'wms1 connects to base of radio modem
outch lf 'not needed, only makes it look cleaner when testing
'--------------- end of Rmodem.lib --------------------------
Using the software in a program:
gosub initialize 'run the initialization portion
gosub connect_modem 'run the connection routine
print "hello world" 'all ready to communicate,this is sent via the modem to the PC
Problem with this modem is that this technology is no longer needed for the public sector. Serial ports are falling to USB. Therefore Innomedia USA has stopped offering the modem and has no USA supplier. In contacting Innomedia I have found that they are offering the modems through their Taiwan office.
I had hoped by the time of the publishing of this article I could have worked out a deal. Steve from Acroname has been working with Innomedia to see if they can carry the modems. But he was not able to work out the deal with them before the time the article needed to go to print. Steve was doubting that there was enough margin for a business to carry the modems without buying a huge number of the modems.
I will post to the SRS list what we eventually find out on the buy. Also look to the Egroups.com file area under the file BuyModem.txt for current information.