I hate soldering. Im horrible at it.

Quick question... just why do we need the MAX232 chip? I've never had any problems and I don't use one. I don't even know what it does. One of the various revisions or modifications of the RS232 specs allow for 5V instead of 12 as the signal, and a stamp runs at 5. I haven't checked, but I suspect the port on the stamp outputs at 5V. I'm assuming that the MAX232 is an RS232 voltage converter thingy, but I have no clue what it does...

The RS232 spec says that a 0 can be anywhere between 3 and 25 volts and a 1 is anywhere from -3 to -25 volts. Now, the stamp has an inverted mode, so that a 0 would be negative voltages and a 1 would be positive voltages. However, you still have to generate a negative voltage, unless the stamp breaks spec and reads 0v as something (consitantly).

Are you saying that you've hooked a 0-5v signal to the stamp's programming port and it worked?

I have connected my comp's serial port to the stamp and had 2-way communication. I didn't use the programming port, however. I connected it to one of the normal I/O pins. I'm assuming the programming port is just another I/O pin...

Nope. The programming port has a built in RS232 level converter (it says so in the manual). The normal I/O pins don't.

And the only way for a custom circuit board to communicate with the RC directly is through the programming port, so any custom circuit board will need to be able to send and receive true rs232 levels.

That still seems counter-intuitive. As I said before, I've had TTL voltages interface properly with RS232 voltages when the true RS232 was on my PC. Why wouldn't it work in reverse, having the true RS232 on the stamp and the TTL on the custom circuit? I'm going to try this tonight or tomorrow, we'll see :)

grrr... not everyone is rejoicing
 

Well, I hate to burst your bubble, Ryan, but my team was extremely *disgusted* and *outraged* at your rules change.

For teams like ours that really _cared_ about building an advanced control system, we didn't wait until week 3 to get started! We've been working since before kickoff. And sure, we expected we might get some nasty surprises in the rules when they were finally released, but we understood that going in. Fortunately, or so it seemed, the controls & electronics rules were pretty much the same as they've been for years. So we worked day and night, designing building a system for bidirectional Robot Controller <--> microcontroller communication and control, fast and flexible enough to be able to run a fast-paced robot. This was *the* task for us at the beginning. Everything else depends on getting your basic infrastructure in place. On the morning of Tue, 1/21, I finally got the last piece of our puzzle in place: pulse-synchronized, 100% error free, 80 bytes per second communication from our microcontroller into the RC via the digital inputs. (see http://www.chiefdelphi.com/forums/sh...threadid=16741 for some interesting challenges that aspect presents.)

(I won't explain to you the other side of the coin, unless our controls team leader gives me permission, because it was such a brilliant triumph we might still want to keep it secret until competition, even though we're not using it anymore. Suffice to say, we had designed and implemented 100% legal (no programming, tether, or modem port) circuitry to get data from the Stamp to our microcontroller at nearly 2000 bytes per second (that's even faster than the RC and OI can communicate), error free.)

And then, two and a half weeks into the competition, right after we complete our prototype system and send off an order to DigiKey for our parts, the rules change. The rules COMPLETELY change. Suddenly, the game's not about creating elaborate virtual-instrumentation interfaces. All our work is TOTALLY obselete. Now, any old team that didn't even care enough to get started yet on building an advanced control system can jump right in and be up and running in a day. A month of backbreaking work is thrown in the trash, along with our team morale and motivation.

Well, I hope you're happy. Maybe we're the only team that felt punched on the stomach by this rules change, but that would kind of surprise me. There are a lot of dedicated, inventive teams out there, I'd be pretty amazed if we were the only ones in this pickle.

Thankfully, after a week of disillusionment and grunt work rebuilding our infrastructure, we're finally back on our feet. We're still in the game, only now we've got our own bragging rights, having successfully implemented *both* ways of communicating. Now, we're running at 19.2kbps through the programming port. And we've again mustered the energy to push foreward, to build the very best control system we can imagine.

We'll see you at competition.

--Micah Brodsky
Controls team
Team SWAT 824

Re: grrr... not everyone is rejoicing
 

Uh, you're acting like it's Ryan Meador's fault that the rules were changed, or even that he was the one who changed them. Last I checked (about 10 seconds ago), Ryan was at least on the same level as you, when it comes to the whole competition. Just another team member on just another team.

Another thing: You act as though your team has been severly direly affected, as though some huge obstacle had reared its ugly head on your team's doorstep, and all you had was a broomhandle and a bucket of Miracle Grow to fight it off. It doesn't seem to me like your team had any trouble, if only a few days after the rule change you had a completely operational system. Oh yeah, and I'm here dicking around with a Basic Stamp which I haven't even been able to hook up to the programming port to test out, because I've been kinda busy trying to teach new team members, and, dare I say it, designing, building a robot for the past couple weeks. Yeah, thanks for being a pompous jerk, and for complaining about HAVING ENOUGH RESOURCES TO GET THE JOB DONE, AND QUICKLY, I MIGHT ADD. You've really made me feel better. Seriously. But not really.

A note about your comment confidentiality, and keeping a totally "obselete" [sic] technology a secret just because you think it's such an accomplishment in control system design. I'm not for confidentiality at all (with certain exceptions). I think that whatever can help you or your team can help someone else and their team. And, as opposed to some people, I would do all I could possibly do to share everything I know about anything with anyone, even if it involved giving away information that would give me (my team) an advantage over another team. Your attitude regarding this whole concept is disgusting.

Oh my, so you can't use your perfect little system (not saying it isn't great, but at this point, I can't tell, because you're apparently not going to release any information about it for your own feeling of superiority)? It's not as though something like this doesn't happen in reality. Say you work for a company who manufacturs staplers. You make staplers for a living. It's what you do, it's what you've been doing. All of a sudden, another company comes up with a way to put staples into paper which is a whole hell of a lot more efficient and effective than just punching it through and crimping the otherside, or whatever. Wait a second, you're technology is obsolete. Ooops. Looks like you've got to redesign your next line of staplers....

I hate you burst most peoples' bubbles, but as I said before, your attitude is just appaling. I didn't mind much.

Well, it *may* or *maynot* be Ryan's fault that the rules have changed. But how would *YOU* feel, if you've worked on a project for 5 friggin' weeks, only to have a rule change render your work obsolete, *and* hear someone "gloat about it"?

This is a *COMPETITION*, people. It is designed to bring out the best in each and every one of us, by pitting people randomly against others. This isn't "let's sit around the campfire, hold hands and sing happy songs". Sure, we all help each other out... to an extent. But I am not seeing a lot of complete CAD drawings and strategy discussions on this year's robot, am I? (Notice how Chief Delphi had kept quiet about *their* robot design?)

Speaking for myself: I routinely help other newbies out on the board. *AFTER* this year's season is over, I am sure we have no problem releasing our drive train and controls systems design. Hell, if your robot broke down on the field, I'd be more than happy to help you fix it. But I am not about to give away our secrets until I see you on the field. What's to stop another team from copying the design and gaining an advantage? Don't even give me that "Oh, gracious professionalism will stop us from blindly copying". You are playing a game to win here. Look at how many measuring tape clones surfaced after Woodie Flowers announced it to be legal last year. Do you honestly think they are built by teams who strictly followed the "no working on the robot after you shipped it" rule? So until you are willing to give out all YOUR secrets, don't start calling people nasty names for not wanting to give out theirs.

Consider this scenario. You are a crappy student not doing well. Instead of asking around for help, you lobbied the professor to make the finals a really easy, open book exam. Then, you come accross a student who had studied his rear end off, and basically laughed in his face. You think the hard-working student is a pompious jerk then?

-=- Terence

Mentor and Engineering Team Leader
Team 824, SWAT Robotics

Let's all take a deep breath and RELAX. There's no need to argue about this. So, your perfect plan doesn't work. It happens. Just try to make the best of it. We all have problems like that from time to time.

I can't imagine I'll make this any better by opening my big mouth, but I'm going to do it anyways.

Team 824, I'm sorry for your tragedy. I'd feel just as awful if my work suddenly had little importance. I don't think I'd be quite so vocal about it, however. You noticed that it was 3 weeks in, eh? Well, I posted the question in the first week, I believe. They shuffled it around 4 times before answering it. I even got an email from the FIRST moderator asking me to re-post it because it had been lost. Also, from discussions here on the delphi forums (and one or more replies to my FIRST forum post), I know I wasn't the only person pushing for this rules change. During the two weeks or so that I was waiting for a reply (I was expecting a "no"), I was working on alternative method of communication probably similar to the one your team came up with. Knowing that an answer from FIRST was in the works, I held back on implementing my design (much to the dismay of my coaches). Luckily, my instinct had been right even though I'd been expecting a "no" answer.

The only reason I knew to even suggest this option was some work I did for the government over the summer... I suspect it isn't common knowledge that a Stamp has that capability. I'd been told by IFI itself that serial communication with the RC was impossible!

Now, if you can pull off 19.2kbps through the programming port, you've definately still got some tricks up your sleeve, since the top baud of a stamp is 9600bps.

That bit you wrote about "any old team that didn't even care enough to get started yet on building an advanced control system can jump right in and be up and running in a day" bothers me very much. While you were tackling the problem one way, others of us were dreaming up alternate solutions. That's what engineering is all about.

Re: grrr... not everyone is rejoicing
 

After all the research my team has done into the control system I am highly skeptical of this claim. The way the robot controller samples the digital inputs and the way it passes those values to the BASIC Stamp make it effectively impossible to do this. For instance, it can take up to 33 milliseconds from when the BASIC Stamp instructs an output to change to when that output actually changes. This means that the output sometimes doesn't change until the Stamp is already in it's next loop (and has already issued another Serin command). I certainly hope you release some information to back up this claim at some point. I will freely admit that a large part of my skepticism is due to the nature and tone of your post. Hardly "gracious professionalism".
Hmm, a "brilliant triumph"? Come on, our team already had this method of communication up and running last year (as did other teams, I imagine). You might have improved upon it (can't say for sure until some evidence is presented) but it's not like this is a totally new approach or anything.
Yeah, let me guess: multiple PWM outputs being decoded by the microcontroller. That would be a nice accomplishment, but please keep in mind that there are a lot of really intelligent people involved with this project. It comes off as really offensive when statements are made that imply that an idea is totally new and hasn't been thought of before. Just because it hasn't been discussed on these boards doesn't mean it hasn't been thought of or implemented by other teams.
Yup, and I'll agree that our team wasn't thrilled with this rule change either. But this has been the way FIRST has operated for years. Last year's "mice" robots were a prime example. It didn't really seem fair to the teams that evaluated the idea and decided it was illegal. But, this is the nature of engineering. Requirements change all the time
I'm not aware that it ever was.
I wouldn't say that. First of all, think about how much you learned in the process. Isn't that the ultimate goal with this project? Secondly, no one is claiming that you can't still use your method. Serial communication has it's own set of problems, and if you've already mastered the digital input method perhaps that's still the better way to go.
Well, as I mentioned earlier, you're not the only team disappointed by this rule. However I haven't seen any other teams on here making such a stink about it. The rest of us just took it as another method of communication to evaluate and moved on. Like I said, this kind of thing happens all the time in the engineering profession.
I'm glad you figured both methods out. That really is a great accomplishment, and something to be proud of. Our team has both methods of communication up and running as well and we look forward to checking out your circuit at competition. See you there.

serial connection
 

I have a question for the teams that are using the programming port to send data back and forth from another processor. You're probably using the external chip to offload some high bandwidth sampling or something like that. If you use the serial connection, then won't your sampling circuit still have to sit there waiting for the RC to acknowledge and transfer the data?

We're planning on using a second stamp 2sx and sending the data to the RC using the analog inputs. I can't see a way to use SERIN/SEROUT without creating a bottleneck, but any insight would be appreciated.

On another note, has anyone tried using one of the DAC chips to send data into the RC? We'd be taking an analog value, passing it through an ADC into the stamp, working on it, then converting it back to analog using a DAC on the other end.

Re: serial connection
 

Well, we're using a microcontroller capable of interrupts so that makes it pretty easy. Since the Stamp doesn't have interrupts, you may be in a bit of a bind. However, the SERIN command does let you specify a timeout value, so you could use that. Unfortunately the timeout is in milliseconds so I don't think you can have a timeout of less than 1ms, which means you can't sample faster than 1000Hz....
We actually had this capability on our custom circuit last year but didn't use it. It should work OK with a few caveats: sampling analog values is obviously slower than reading digital values, so you have to take that into account. Also keep in mind that it probably won't be perfectly accurate (the lowest order bit or 2 might get screwed up, especially with two ADC and two DAC conversions like you're talking).