RoboCon 1.01 (control robot from PC)
 

It took some work and some massive amounts of Coke and Mountain Dew, but I just finished RoboCon, a program that will allow you to control a robot from your PC. There are two main components to RoboCon:

1. The DLL and LIB files. These can be included in your own programs to create a custom-control application specifically for your robot. Check out the "Writing your own..." document for more information

2. ConSample. A sample application that uses RoboCon. It is very minimal, but ConSample will allow you to control a robot using your PC.

PLEASE read the README. It contains important information on how to make ConSample work.

As always, my programs are available at:
http://FIRSTprograms.tripod.com/Programs.htm
-and-
The whitepapers here

Let me know what you think!

--Rob

Holy Bajeesus.

Excellent work! I really can't get into the code until I get home later tonight, but I do have one quick question.

Is there any way to control the robot wirelessly from a stationary computer, either via the data being transmitted via the OI/RC radio link; or just connecting the OI and RC by a tether, placing both on the robot, and having an PC/RC radio link?

My apologies if you answered this in the whitepaper ZIP, but I can't open the file from the current computer. I'll be sure to look at it tonight, though.

You should be able to do it wirelessly if you have RS-232 radios lying around. The programming/debugging ones should work if you have those.

Unforunately, I don't know how to get this to work without an OI, so you will still need to tether/radio that to the RC, but as you said, you can just place it in the robot.

Don't forget to send the "RoboCon RC.bsx" program to the RC or absolutely nothing will happen.

I'm at 14 downloads and only a few responses. PLEASE post stuff. I want to know whether I should continue spending my time writing programs for you people or if it's just a waste of my time.

I am especially interested in hearing from programmers who try to write their own app using RoboCon, but I want to hear from everybody.

Thanks in advance!

--Rob

I actually tried roboemu but i still haven't had the chance to actually figure IT out!

lol been too busy working on websites.

You think I could take a look at that sourcecode? I'd spend much more time on it if it worked on my work machine :D

What source code? Source for RoboEmu is included in the RoboTools zip file. Otherwise, source code can always be found at my website:
http://FIRSTprograms.tripod.com/Programs.htm

And now we're up to 15 downloads of RoboCon...

Trust me, your RoboCon program will be very useful to a robotics project our club is doing. We'll have a website up in a few days for the project, and your RoboCon program just filled a gaping hole in our control system diagram.

(It's for an autonomous robot. We wanted some way to have a computer program control it, and we were going to settle for placing a stripped down laptop on the robot itself. This should resolve a few problems, because having a stationary computer for telemetry is much more useful.)

Excellent. Let me know if you run into any trouble and I'd be happy to help. I wrote the documentation in about 15mins, so it's not overly polished (I haven't even read it myself). For now, my first priority was just getting it out so people could start thinking about stuff.

A word of warning: make sure the time between calls to "update" is not more than 1/20th of a second. This shouldn't be a problem, but try to keep it in mind.

Protocol?
 

I didn't even know you could send data to the RC directly from a PC. That is awesome! This will allow teams to prototype multiple driver stations before they even touch a soldering iron.

Any plans to post the communication protocol between the RC and the OI? I'd prefer to use Visual Basic, out of habit- not because it's better. Specifically, I'd need the following information:

1) COM port settings (Baud Rate,Parity,Databit,Stopbit)
2) What is the format for the data sent to the RC? I'm assuming this is an X-byte array.
3) What is the format for the data received from the RC? Again, I'm guessing this is an X-byte array. I'm thinking it would look similar to the Dashboard port specification.

I would appreciate any info you can provide. I think this would make a great project for the software team to better understand how the control system functions.

Thanks,
Jason

You can't communicate directly from your PC to the robot controller.

He's still using the operator interface, IF YOU HAVEN'T READ THAT ALREADY.

You probably want to post that on FIRST Codex, cause then it'll be available for all teams to use and see, since FIRST Codex is trying to put together resources for teams for help on programming. By the way, VERY nice code! I'm impressed. Keep up the great work.

http://www.first-codex.net/

half true, half not. Your PC does communicate directly with the RC via the Programming port. The only reason why you still need the OI is that otherwise the master uP stops execution of the Stamp when it doesn't detect a signal from the OI. Strictly speaking, the OI just sits there. In fact, it doesn't even send any important data to the RC as the only things that are present in the Serin command are the sensors and switches.

If anybody knows how to fool the RC into thinking it has a signal, let me know.

I haven't tried to reverse-engineer the packets yet as the documentation specifically says NOT to plug the tether into a computer and I am terrified of frying my serial ports. If anyone has an old computer they are willing to try this on, let me know and I'll send you some code to run and ask you to return the output to me.

--Rob

I am so glad we are on the same team. ;)

I think i'll be fooling around with roboCon tomarrow or at least sometime this week. I'd be happy to run those tests for you, seeing as that these computers at school are made from a solid mass of kevlar, and could probably withstand anything. That, and i need to distract IMS with problems other than taking my privalages away one by one.
Does anyone know where to find a copy of the program running on the stamp located within the OI? That may help this effort greatly.
Lastly, what exactly is coming out of the computer? Is this a stream of data that can go over the modems? You may be able to replace the OI with a comp, and leave the sensor checks on the stamp code. Just theorizing, don't tear my logic apart to gruesomely.
Any who, send me the code you want me to test, and ill have at it. I'm assuming you just want to monitor it on the serial port, I think I can handle it ( i hope ).

First, thanks for advertising the Codex! Right now, however, we don't have a way to directly post files, except through the discussion forums. however, the size we're talking about I think is too large for the forums upload system. I'll see if I can get a "white papers"-style upload system in place...

OK, there are a few issues here. First, the Stamp is only in the RC. The OI consists of several other types of ICs. Similarly, the RC is A LOT more than just the Stamp. There are also processors for input, output and a master processor to control it all. This master processor (or mater uP) is the only thing the Stamp communicates with directly.

As for what comes out of the computer, its sorta complicated. It starts by waiting for a 255,255,1 sequence, then reads the next 11 bytes. These eleven bytes contain all eight sensors, both bytes of rc switches, and a control byte that I use internally to prevent bytes from every being 0 (Windows doesn't like sending or receiving 0 as it thinks it is the end of the message). It then waits to get back a 255,255,255 sequence indicating that the Stamp is ready to receive the new data. It then sends a 20-byte packet to the RC that contains all 16PWMs, both relay bytes, a byte for all eight LEDs, and a control byte similar to the one I discussed previously.

If you want to see this as actual code, open up the "RoboCon RC.bsx" file and take a look.

Finally, do you have an OI and an RC and the necessary cables (one F-F and one M-F)? If so, I'll try to write a little program in the next few days to record everything that gets sent back-and-forth between the two.

As another note, would people be interested in a more detailed description (possibly even a whitepaper) on the overall setup of the RC and OI?

yes. Very much so. I had to teach myself everything i know about PBASIC and all of its associated what not. I know enough to get by, and I get most of it, but a few questions bother me, such as :

If the main stamp is on the RC, then how does the OI respond to it? Are the screamers bi-directional? I hooked up the modems in backwards for kicks once, and the RC got short spurts of signal. IE. Pause .5sec, lurch, pause, lurch.

I think i can get a serial port monitor up and running on my own, but i wouldnt mind if you did it. I tend to break things in my debuging attempts. I do have the cables required, i just need to find them and the rc&oi. It'll be fun.

The important thing to keep in mind is that the Stamp is a VERY small part of the OI/RC system. Basically, it is only there to allow us to program more easily. After all, a Stamp IIsx is only about $30-$45, but the whole RC/OI setup is $1145. There are SEVERAL other microprocessors that are far more expensive than the Stamp in both the RC and the OI. These are the ones that deal with all the communications between the two pieces.

As for the Radio Modems, they ARE bi-directional. After all, the OI needs to send Joystick data to the RC and the RC needs to send dashboard/LED data to the OI.

If you feel like doing the serial port thing yourself, I'd appreciate it as I'm currently in the middle of the Linux port of RoboEmu. About the only advice I can give you is that the Radio Modems are 9600bps, so I would guess the thether probably is too.

--Rob

This will probably end up being a long post, and hopefully I can answer a lot of questions from this thread. But before I do that, I need to stress one thing: DO NOT connect a computer directly to the tether port of either the OI or the RC! The tether port carries standard serial data, but it also has +12V on one of the pins (think about it: the OI gets power from the RC when in tether mode, so this power has to come from somewhere). If you hook this up to a computer, there is a good chance you will ruin either the serial port on the PC or the RC itself or both.

OK, now that that's out of the way... Myself and some other members of team 111 experimented a lot with this last season. We successfully built a miniature operator interface out of a Motorola HC08 microprocessor that talks directly to the RC over the tether port. So it definitely can be done. However, we also have a lot of fancy equipment here at Motorola that allowed us to figure it all out before we destroyed anything. If you don't know exactly what's on each pin of the tether port, then you shouldn't be hooking the RC up to anything other than the OI.

The OI is sending several "important" pieces of data to the RC, even in this case. One of the bytes in the datastream from the OI to the RC is your team number. The RC will not function unless it is receiving this team number in the stream. There's also 2 checksum bytes, an "enabled" bit, etc.

We've obviously figured out the whole bi-directional protocol since we can control the RC with our own software. Right now I'm thinking it's not a good idea for me to share the protocol as it will almost certainly just lead to lots of dead RCs from people trying to hook up to them. I can tell you this though: the RC-->OI data stream is the exact stream you get out of the Dashboard port. So if you read the spec for that you'll get a very good idea of what's going on between the OI and the RC. The reverse direction is extremely similar.

The screamers are indeed bidirectional. I'm a little surprised that hooking them up backwards didn't work. Functionally, the radios on each side of the link are identical, except for the Tx/Rx frequencies are opposite. If you want to learn more about the radio modems, visit www.electrowave.com and look for the SCREAMER422 technical manual.

It's been about 6 months since I looked at this, but if I recall correctly, there are 3 processors in the RC: Two PICs and the Stamp. The two PICs do the majority of the work, and run considerably faster than the Stamp. However, they are a lot cheaper. At $30-45, the BS2SX is easily one of the most expensive microcontrollers on the market. The PICs in the RC are probably between $5-10. The HC08 that we used in our Mini OI was $3. With the Stamp, you are paying a hefty price premium for the "ease of use" of the PBASIC language, though I'd argue that programming a regular microcontroller in assembly isn't really that much more difficult, and would be a lot more useful to students interested in computer science/engineering (but that's another topic altogether!).

So if the microcontrollers in the RC and OI are so cheap, why does it cost $1200, you ask? Well, I can't say for sure, but just guessing I'd say that it's because it's such a low volume product that they have to charge that much to recoup their costs in designing the hardware and writing the software to run it all.


Please let me know if you guys have questions about any of this. It's great to see so many people interested in the inner workings of the control system! This is exactly the kind of stuff that electrical/computer engineering is all about, and unfortunately I don't think either of these fields get enough exposure in the FIRST world.

Given that you hooked your HC08 up to the tether port, I assume you must have a pinout. If so, would you mind sharing that? If I knew which pin the +12V was on, I could merely disconnect that wire in the serial port and wouldn't have anything to worry about.

Also, would you mind sharing the HC08 setup, as this could be a fun project while we wait for Jan 4, and at $3 it would definately be one of the cheaper ones.