more control options

Technical Technical Discussion
1

When will FIRST let the EEs have as much fun as the MEs?

You can design most anything you want mechanically, but for years the control system was straight out of the box, nothing to do.

It began with a stock control box, and the flexibility was in how you made and arranged the toggle switches in your switch box.

Then they gave us programming, which used pbasic, which was good and bad. in some ways, more bad than others (bloody unsigned interger math).

There was that one time when you could create a custom interface as long as it was made of kit parts so you could get away from joysticks.

Then we could use any pots we wanted in any quantity, and there was much rejoicing.

Then we could hook up a laptop or pda to view certain outputs, and again, there was much rejoicing.

This year, we get $100 for a custom circuit board to connect to the sensor port, and once more, much rejoicing. yay.

However, this is still not enough.

We need more variable space.
We need interrupts.
We don’t exactly need, but would greatly appreciate the use of a different programming language.
We need to have all the variables sent back through the dashboard, or at least have the ones that are sent back, selectable by the programmer.
We need to be able to use the laptop to do some control of the robot. That is, to hook up the laptop to the control system.
We need to be able to use a custom circuit board on the input side.
We need to have the custom circuit board on the robot be less restrictive. Let us do more than take sensor inputs and have sensor outputs.

We are allowed to have a wireless video-camera on the robot. However, this video feed is not allowed to be sent back to the drivers as this would supposedly create an unfair advantage. However, if FIRST would allow the use of such a video-camera to all the teams, then it would no longer be unfair, as all teams would have this option available to them. The only problem to work out is transmitter frequencies. To allow each team a camera but not interfere with robot operations.

FIRST has come a long way in letting the EEs have as much fun as the MEs, but I feel they have much further to go.

2

I have thought about this issue at considerable length. Personally, I would love to see more control options available. Unfortunately, doing this would widen the gap between veteran teams and rookie teams. Just think of all the cool things an experienced EE could put on the robot. A veteran team could program a robot to run circles around the rookies. Besides, you need to keep the controlling simple. FIRST is meant for young people. You shouldn’t need a degree in EE to wire or program the robot. So far in my team’s four years, we have had students wire and program the robot totally. Never has an adult helped with the electrical aspect of our robot. We have to partially thank simplicity in the control system for this.

Don’t get me wrong, I would love to see improvements. The only problem is you jeopardize fairness in the process.

3

We are Thinking of using a DDR(Dance Dance Revoloution) pad to control our robot. That would be very cool.

4

I would love to see the control side become more complex :smiley: Including the robot controller not having a default program. The MEs will control stuff with the default program and crown themseleves an electronics expert when you are out for a day. Time to get them in line.

5

*Originally posted by Curtis Williams *
**IIncluding the robot controller not having a default program. **

As long as we have a standard control system, there will need to be some form of default program, as with a standard control system comes a standard way to read input and output…

6

Actually, doing away with the default code is bad. the only reason i now know pbasic is because i sat down and read the entire default code from start to finish. after that, i learned how the robot is controlled with pbasic. it’s a useful tool for rookie teams. of course, 2 years from now i won’t be saying this. :smiley:

7

I’ve often thought that it would be a good idea to require the robot to act autonomously for the first ten seconds before allowing the operator interfaces to be turned on. That would make for some interesting fun in this year’s game, and it would definately increase the balance between the EE/CS and the ME/Construction sides of the coin. This would be even more interesting with the use of the reflective sensors on this year’s field pieces.

8

i agree that we should be able to add our own camera to the robot and veiw it on the dashboard but if so then maybe FIRST will include it in the kitof parts! Now that would be a score!

and don’t the teams that do get permission to get a camera aboard have it projected on a big screen for the audience anyway?:confused:

9

hmm, i would think that would be in violation of the rules, because if the crowd can see it, so can you, right? nonetheless, it would still be cool. :smiley:

10

It would be very cool if FIRST were to allow more flexibility on the conrol system. I work on our electronics team, and the sad thing is that the mechanics of the robot are much more complex than the electronic controls. Not only would it allow fellow students like my self to learn more but it would also even out the mechanics and electronics.

As for the rookies. If everything were to be made compleatly fair for everyone involved the competitons would not be much fun. Any veteran team has and will have an advantage over rookies.

11

This is not a response to any one posting, just a comment on the issue. I even saw postings on another thread that wanted to outlaw using Engineers all together.

There are a lot of teams that don’t have access to an Electrical Engineer, although we are not one of them and I too, a Controls Engineer, would like a little more lee way on the electronics. Over the seven years I’ve been participating, I have seen many teams that could not even deal with making a minor chage to the default program. Although we have access to CNC, EDM, Wire Burners and laser welders, I was really pleased to see them open up the rules on buying pulleys and gears. It is less expensive to buy them than to make them and it affords the team without those resources to compete on a somewhat level field. What if they decided you could not use any pre-manufactured systems or parts,in other words you would have to make your own wheels, gears, pulleys, no extrusions, just plain raw stock, etc…

I think another programming language would make it easier for teams to program as well as allow teams to invest some time in something they could use in the work place. I think FIRST has done an outstanding job in adjusting the rules to level the playing field

12

From a student programmer’s perspective, even I would like to see some more flexibility.

One year and 8 weeks ago, my programming experience was limited solely to my TI-83 graphing calculator. (Two words: IF-THEN-ELSE). However, after my rookie year of FIRST, under the supervision of our EE supersenior Ed Lentz, I had somehow become the cheif student programmer on the team. I must admit that last year was a lot more fun programming wise, (auto-balance program that would have worked, but for one that one bug of Ed’s.) It is a fact that I programmed the vast majority of our team’s code this year.

In fact, now I even consider myself to be a programmer, and not merely on FIRST. In the off-season, I took it up to learn C, VB, and just a little bit of Perl. Now that I feel like I know what I’m doing, I would like to see something that I could sink my teeth into a little more, even without an EE on the team. The PCB was fun, but I don’t think it serves much good, just measuring amperage of our drive motors. Anyways, this is already a long post, even though I could ramble on and on.

13

I’ve headed in the opposite direction…

I started out with simple things, learning how to use a computer, etc. Then I picked up HTML and Javascript. Then I made my way over to C/C++ and then JAVA. Now I dove into the PBASIC programming. This stuff is very easy. You’re working close to the machine level, but still the language is nicely built. However, the STAMP microprocessor is limiting in the capabilities it provides. PBASIC is merely a tool given to write code to work with the STAMP microprocessor.

Currently, I’m now taking assembly classes. This is quite fun… Making my way down the chain instead of up… It’s actually quite intreguing enough that I’ve decided to become and Electrical Engineer. Probabaly double major in Electrical and Computer Engineering…

14

Many times these past few years, I have heard the discussion raised regarding moving the robot programming language away from PBASIC, perhaps to something more “real world,” to use wording from an above post. However, I got to thinking about the pros and cons of PBASIC vs. other languages, and started to think that for what we’re doing, we may not have it that bad off. In a nutshell, what we need a processor that allows direct I/O either on a pin or other level to the other processors on the RC. Based on my experience, any higher level languages try to abstract themselves from the hardware as much as possible, which may actually make our lives harder, rather than easier. So PBASIC, even with it’s limitations, may be the best for what we’re doing…any comments on this?

15

In responce to Nate’s post, this is something that I have always thought but have kept my mouth shut about. I know some basic PBASIC along with C++ and have always wondered how well C++ would work with controlling direct hardware. It wouldn’t be as easy as just naming vars at the beginning of the program. It would take much more work.

~Tom Fairchild~

edit: I (Tom Fairchild) really did this post, but was accidently logged in as my buddy Stephen. Sorry Steve!!

16

Srawls and Nate demonstrated the point perfectly. PBASIC is a fairly simple programming language that seems high level, but it really isn’t. I found it very simple to use (vs x86 assembly) and also somewhat robust once you start to understand what you are doing (…that means after reading the 300 page manual a few times).

Since FIRST is trying to make it easy to build a robot, these stamp controllers are pretty much as far as you would go.

17

C and C++ are used to control hardware directly all the time. It’s the operating system that abstracts the hardware, but in a situation like this an OS most likely wouldn’t be used. Many processors use memory mapped I/O which allows access to input/output pins in much the same way that PBASIC does. By writing a value to a certain location in memory, you’re actually setting the output pins to that value. Thus, in C or C++, you can access the input/output pins directly through the use of a pointer. This is done all the time in embedded systems. Realistically, for what we’re doing here, microcontroller assembly wouldn’t be much more difficult to learn than PBASIC. Also, x86 assembly isn’t a very good comparison. If you look at the instruction set for something like an HC12 or similar, I think you’d find that it’s a lot more simple than x86.

If such a microcontroller were to be used, FIRST could easily provide a library that initialized the processor, handled serial inputs/outputs, etc. All that would be left to the teams would be the traditional bit twiddling for input/output, and any calculations in between. However, you’d also be able to use interrupts and other features of the chip, not to mention the fact that it would run thousands of times faster than the BASIC stamp.

Personally, I’d like to see FIRST have some form of modular control system, which different user processors could be plugged into. Thus, new teams or teams without the knowledge required could just plug in the BASIC stamp module. But, for teams that wanted more power and don’t mind assembly or C, there could be control modules with more powerful processors that would plug in.

18

Dave:

I agree 100%, for anyone that has programmed with more powerful languages, using PBasic is like going back to teletype from the internet. It is a painful memory to use basic when you know it would be so much nicer with something else. I’m guessing they picked the stamp chip because they knew it well enough to create the original robot controller and I’m guessing they are already discussing something better. I think a developement package similar to visio style logic diagrams would be a nice option for teams that don’t want to work with text. Either way, adding external circuitry to make up for a controller that is too slow to take in a tachometer pickup is frustrating.

Just for the record, I think the Innovation FIRST people have done an excellent job, We just want more.

Tim Gates