I think JStamp would be the most logical choice for FIRST hardware evolution and even JCX in FIRST Lego League. Check them out and tell me what you think.
Adam Krajewski
I took a look at the Jstamp and it looks interesting. There are a couple of problems, though, the biggest being price. The chip istelff costs $109, almost twice as much as the stampIIsx. They also say that you must have the development kit to be able to program or debug the Jstamp. This costs $300 (but it includes the Jstamp).
Another, more minor problem, is that while the Jstamp has 22 IO pins (if I counted correctly), but only 5 of them sink/source 25 ma, with the rest sinking/sourceing 8 ma. The stamp II has 16 IO pins, but they all sink/source 30 ma. I don’t know if the controller needs all the pins to sink/source that much current, but it would be more circuitry (more cost) if so.
A better solution seems to be the J-stamp from parallax (confusing isn’t it? ;)). You can read a liitle about it at j-stamp.net
It appears that it is pin compatible with the Stamp II, which means that Innovation FIRST could drop it in to the existing design. They would still have to write a new default program, but it would be much easier then a completely new design.
While J-stamp may well be a better stamp than our current stamps, their programming language change will have all us programmers back to square one: a pseudo rookie year, if you will. My personal motto is “If it ain’t broke, you’re not tryin.”, but our current stamps work, um, modestly well. Since everyone HAS NOT gone beyond the limits of the current stamp, now is not the time to change, but that time will come. When Mr. Joe Johnson determines that his stamp can’t do the job, he’ll let everybody know that it has been out-programmed, and we need to move on to J-stamp. But, that day has not reached us yet. (Has it, Joe?)
Java? …why? Granted, I would perfer Java over PBASIC, but why not Lisp, SmallTalk, or C? Java was created to develop cross-platform applications with ease, and to introduce the concept of “applets,” right? Why must Java be put to use in systems that do not benefit from this? Platform-Independance is hardly an issue with what we deal with. But, hmm… if it were, couldn’t one create a VM for his or her language of choice? (Just (my '(Bit Bit)))
*Originally posted by Jon Lawton *
**Java? …why? Granted, I would perfer Java over PBASIC, but why not Lisp, SmallTalk, or C? Java was created to develop cross-platform applications with ease, and to introduce the concept of “applets,” right? Why must Java be put to use in systems that do not benefit from this? Platform-Independance is hardly an issue with what we deal with. But, hmm… if it were, couldn’t one create a VM for his or her language of choice? (Just (my '(Bit Bit))) **
Why Java? Java is great in the embedded market. Check out J2ME (at http://java.sun.com/). The platform independence is useful because of the myriad different platforms being used in the embedded market today. Java also happens to be fairly easy to learn (it’s used in the basic CS courses here at RIT) and the AP test will be switching to Java next year; so there happens to be a fairly large group of people knowledgable about Java.
Now as to why not LISP (either Common LISP or Scheme) or Smalltalk: neither are used in wide scale development. This means that the market for such devices is very small. As for why to not pick C, C is a fairly difficult language to learn and it’s also not Object Oriented. You could use C++ but C++ is an extremely large and complex language. It also happens to be missing some of the standard functionality that is included in Java. It also doesn’t have a feature subset that’s targetted to embedded devices (a la J2ME).
Personally, I’d love to see us switch to the J-Stamp. It seems to be orders of magnitude better than the Basic Stamp 2x that is currenlty used. While there may be some workarounds to common problems with the Basic Stamps, there are more significant architecture problems (limits to RAM, limits to speed, no signed math, no floating point math, etc.) that cannot be overcome. If we were to be able to move past that, the programming part of this competition would be much more extensive and enhance the ability of programmer and the ilk to enjoy the FIRST competition.
Matt
*Originally posted by Matt Leese *
**Personally, I’d love to see us switch to the J-Stamp. It seems to be orders of magnitude better than the Basic Stamp 2x that is currenlty used. While there may be some workarounds to common problems with the Basic Stamps, there are more significant architecture problems (limits to RAM, limits to speed, no signed math, no floating point math, etc.) that cannot be overcome. If we were to be able to move past that, the programming part of this competition would be much more extensive and enhance the ability of programmer and the ilk to enjoy the FIRST competition.Matt **
I agree. Even though I have several years invested in the BASIC Stamp, and I don’t know Java, I would really like to move to the J-Stamp because:
- It would provide an opportunity to learn Java
- Structured programming has it all over PBASIC
- We should be able to safely divide negative numbers with the J-Stamp
I don’t think we would quite be back to square one as Dan asserted. I imagine the structure of the new default program would still be readily recognizable to veteran FIRST programmers. But…, even if it does turn out to be like starting over for us verterans, it just might be a GOOD thing to even the playing field a little bit between veterans and rookies.
I never said I believed that this change should be immediate. I believe it would be a logical “next step” to be taken in the future. JStamp is a new product, J-Stamp has not even been released.
I was drawn to JStamp over J-Stamp mainly by the large amount of both SRAM and EPROM. Perhaps overkill, but nice all the same.
I don’t read “Stamp 24-pin footprint” as complete pin compatibility. If it is as simple as popping the Basic Stamp chip out of the control system and putting the J-Stamp in, then it’s the logical choice. However, I doubt such is the case.
Also, I’m not sure what a “subset” of the Java language means, either.
All in all, it’s hard to make conclusions without full technical specs…
As for going beyond the limits of PBASIC, recent discussions have shown FIRST teams are technically capable enough to stretch the limit of the software/hardware. Not to mention, why not change? Try something new…
Java is a beautiful language. I know several hardcore C programers that have been converted to Java. Most disliked it at first, but it tends to grow on you. I disliked it very much. I think it a very elegant language now that I have more experience, as well as being as easy to implement as ‘visual’ languages, while still writing actual code. It’s not perfect by any means, but is vast improvement over PBASIC.
Give it chance… I think you’ll like it.
And what’s wrong with starting over? Algorithms never really change (bubble sort in C is the same as bubble sort in Java) and there’s a another level to the competition. I see nothing wrong with starting over.
Adam Krajewski
I will have to give the Java language credit for being infinitely more flexible than pBasic for the novice user, as I consider myself to be. With Java, a very easy language, I could take on my steering system accident-proofing project without much outside-team help, but pBasic is something I’ve had to ask for help with on occasions more numerous than I can count on my whole team’s fingers and toes! Java is a simpler language by far, but I don’t think that now is the time for a change, even though it probably would make the game more competitive.
*Originally posted by Dan_550 *
**Since everyone HAS NOT gone beyond the limits of the current stamp, now is not the time to change, but that time will come. When Mr. Joe Johnson determines that his stamp can’t do the job, he’ll let everybody know that it has been out-programmed, and we need to move on to J-stamp. But, that day has not reached us yet. (Has it, Joe?) **
We actually out-programmed our micro last year. If anyone has seen our robot you know that it was a very complex machine and really couldn’t be controlled by human alone (much help from automatic control was needed). We had 6 feedback loops running at all times to control it.
We actually had an automatic balancing feature that had to be cut from the code because we ran out of code space and variable space. Just to get enough space to do all of the feedback we had to play some tricks with direct memory access and memory location swapping or else we would have been out of variable space well before putting in the 6 feedback loops.
It’s too bad we had to cut the auto-balance - it would have saved us about 4 seconds per match. We ended up putting sensor feeback to a driver display so the driver had to do what the auto-balance routine was going to do.
So, as far as I’m concerned, bring on a more powerful micro (please).
*Originally posted by Chris Hibner *
**We actually out-programmed our micro last year. If anyone has seen our robot you know that it was a very complex machine and really couldn’t be controlled by human alone (much help from automatic control was needed). We had 6 feedback loops running at all times to control it.
We actually had an automatic balancing feature that had to be cut from the code because we ran out of code space and variable space. Just to get enough space to do all of the feedback we had to play some tricks with direct memory access and memory location swapping or else we would have been out of variable space well before putting in the 6 feedback loops.
It’s too bad we had to cut the auto-balance - it would have saved us about 4 seconds per match. We ended up putting sensor feeback to a driver display so the driver had to do what the auto-balance routine was going to do.
So, as far as I’m concerned, bring on a more powerful micro (please). **
I’m rather interested in what you did with your pbasic. Not too many people on our team know anything about the programming, so we don’t get much innovation done in that department. The only major think I could think of to do in the code last year was auto-balance. You cut it out to make room for somthing more important? I’m curious to look at your code and robot! Perhaps you could post or point us to some documentation? 
You can get pictures and a QuickTime movie (thanks to SOAP) of our robot from my personal web space at school:
http://www-personal.engin.umich.edu/~chibner/first/2001
Removing auto-balance from our code wasn’t a big issue since our balancing method was pretty fool-proof. The only reason for doing it automatically is because it would have been faster. The reliability was the same either way. To balance, we did the following (if you watch the movie, you can see all of the step pretty clearly):
-
push the goals onto the bridge so that they are out of balance toward the far side of the bridge. When the bridge went to rotate over to the other side (since we pushed it out of balance), the bridge would hit our bridge sensor / bridge stop, keeping the bridge from going all the way to the other side.
-
Pull the near goal back toward our robot to balance the bridge.
-
Our bridge sensor sends a signal back to the player station (it turns on an LED) when the bridge is not balanced. As soon as the light goes out, we stop pulling the near goal toward us.
-
Release the goal and back into the end-zone.
To automate the process, you remove the LED and hit a button that starts moving the near goal back until the sensor says the bridge is balanced at which point the routine lets go of the goal. It would have made the process faster, but it wasn’t at all necessary since the sensor provides good feedback to the drivers.
So, what did we do with all of our code space, you ask? If you look at the pictures and the video, you can see that our arms had a lot of joints (necessary to pack into the starting position and to reach far enough to tip the bridge out of balance when pusing the goals onto the bridge). There is no way a human could control that many joints without automatic, feedback control.
To control our arms, we made a small model of one side of our robot’s arms (only one side is needed since the robot is symmetric) that sits in the player station. The driver would move the model arm into the position that she wanted it to go, and the control algorithms would then make the actual robot follow the model robot (we won the leadership in control award a nationals in 2000 for doing the same thing with out 2000 robot).
Since we had 3 joints per arm, our robot requires 6 control loops to run at all times. This is what took up most of the memory and code space. Then once you add in the drive train, the bridge sensor, and all of our pneumatics, we didn’t have enough room to add the auto-balance.
In terms of the actual code, I didn’t do the programming, so I don’t really know what our programmer (Dave Purola is his name) did. I asked him once and he described it to me and it was fairly complicated so I didn’t fully pick up on it.
Dave works in test engineering here and they use PBASIC to do some simply control with their testers, so he’s extremely familiar with it and has years of daily experience to learn all of the tricks. I could try to track him down and get a full explaination on what he did, but Dave is one of those guys who doesn’t do anything unless absolutely necessary, so I wouldn’t hold your breath waiting for a white paper or anything.
I would suggest that you go the programming seminars at the kickoffs and learn as many tricks there as possible. Unless you do something really crazy, you probably won’t need to do anything like we did.
The big reason that I always want a better micro to allow more control is because our team is based in an electronics place. What we do is control things. That plays to our strength. The only mechanical engineering we do in our building is putting boxes around the electronics (there aren’t too many moving parts in a box and bracket 
). Getting a little more flexibility in the controls helps us to get over our mechanical shortcomings.
-Chris