Simplifying PBasic

FIRST General Forum
#1

Here is a copy of a message I sent to Woodie Flowers and the rest of the FIRST crew regarding an idea to simplify control system programming for FIRST teams. Tell me if you think its a good idea and whether or not you think your team could benefit from it.

Thanks,
Doug

//BEGIN COPIED MESSAGE//
Professor Flowers,

    My name is Douglas McClean, I am a sophomore Systems and Control Engineering student at Case Western Reserve University. I have participated in the FIRST competition for the past two years in concert with my former high school in Norwell, Massachusetts and my employer in the same town, Mass Bay Engineering, Inc.
    A few days ago while in class I had an idea for a possible way to improve the FIRST experience for many team members (especially younger ones), speed development times for robot control systems, and raise the level of competition at FIRST events, and I would like your opinion as to whether you feel it is worthwhile.
    The PBasic language used to program the robot controller hardware is at a fairly low level compared with most languages with which high school students are likely to be familiar (C++, Java, Pascal, and various TI calculator dialectics are probably the most common, along with the usual web markup and scripting languages), and a great number of FIRST participants don't know any programming at all. I have heard complaints in my discussions with a number of teams (including my own, for which I have supervised control system design and construction) that the PBasic language is confusing, prone to difficult to debug logic errors, and difficult to explain to students. This is only compounded by the limited resources available to the robot controller processor (26 bytes of RAM, plus 6 reserved for special purposes, and an additional 63 + 1 which must be accessed by a different method and placed into one of the main 26 before gaining utility). In general, the process of developing, testing, and refining software for FIRST control systems is dicey at best, and this leads many teams to stick with the default program which comes with the kits.
    The situation is still very good, of course, the control system hardware supplied with the kit is extremely powerful and has solutions to most problems which teams with the resources and people to tackle can harness to build customized software, teach their students, and improve the end product.
    My idea is to write a graphical development environment (along the lines of a Simulink- or Vensim- type user interface) and associated compiler / assembler to streamline the entire process and make it easier to explain and tinker with. Teams working on control system design could then think about software design on a functional block level instead of on an assembly-language instruction level. (e.g. Apply a low-pass filter to the x and y channel inputs from joystick one, then send the results to a single-joystick -> tank drive converter and create a dead-zone in the output to remove low-speed drive efforts in the pits, or some similar application).
    I believe such a project could be completed by myself and one or two of my associates here within one or two hundred man hours, probably using visual basic or a combination of visual basic and C++, and obviously provided free of charge to all teams. It might be possible instead to develop this as a web-based interface allowing teams to utilize it regardless of their computing platform, although I am not sure what utility that would have since they would still need to pass the output to the final Parallax-supplied tokenizer and download it to the robot controller, and to my knowledge Parallax does not supply a Macintosh version of the software used to do that.
    I am wondering, however, if you think this would be a desirable goal or if you think this would be wasted effort? Also, I am wondering if you have any knowledge of planned changes to the FIRST supplied hardware which would render such an effort obsolete, or anything of that nature?


    I thank you for your time, and applaud your efforts in creating and continuing the FIRST competition.

Sincerely,
J. Douglas McClean
jxm156@po.cwru.edu
216/754-1995

//END COPIED MESSAGE//

#2

I think that would be a great idea.

We could have joystick classes so the varible names could be port1.y, port1.x, port1.trig, etc. and there could be functions such as port1.deadZone().

Also the if…then…goto statements get VERY confusing in PBASIC. Usually you write an if statement so that when it is true, it performs the actions below. However, in PBASIC just the opposite is true, which can be especially confusing to new programmers. The basic C++ if statements, for loops, and while loops would make programming so much easier, not to mention the functions and classes (which I’m convinced could be translated into PBASIC by the compiler somehow).

Anyway, I don’t know Visual c++ or visual basic that well so I don’t think I could be that much of a help. Just a thought, what if we could somehow produce a software package that included a scoring program for the current year’s game, a dashboard program, and the c++/PBASIC compiler thingy. That would be neat.

#3

Jay,
I had forgotten all about the dashboard port (since my team has not yet utilized it). I could write the compiler to also generate a customized dashboard program based on the code for the robot. I’ll add that to the possibilities list.

#4

I’ve sort of had this idea in the past and there was one thing that I realized made it fairly unworkable. The mainthing is that there is no documentation for the assembly language used by the Basic Stamp 2X and there is no documentation on the communication between the two systems. Also, don’t underestimate the complexity in writing a compiler. They are large and complicated pieces of code. But if you do seek to go this route, best of luck to you and please ask about any difficulties you may run into.

Matt

#5

Actually, you could use Simulink and the Real Time Workshop from the Mathworks to auto-generate your code for you if you’re a real RTW nut (you’d have to write your own translator files). However, this could be done by someone and distributed to all teams. The only problem is that every team would need a copy of MATLAB with Sumilink, RTW, and a special block library for the I/O ports on the FIRST micro. Perhaps we should hammer Mathworks to be a sponsor. They could give every team an evaluation copy of the necessary software (they do this quite often - they give you a licence for 30 days and once 30 days is up, the software disables itself. You could easily extend this to 4 months for the life of the FIRST project). I think it would be smart for the Mathworks to do this since they’ll get a lot of young people hooked on Mathworks products which should be good for future sales.

(As a side note, I’m a MATLAB/Simulink nut. I use it all day every day at work.)

-Chris

#6

The proposed systems is going to be a lot of work, more than the estimates in the initial post (IMHO).

It is a valiant effort, but I think one that is going to be full of sneaky and subtle bugs. I am afraid that you will get something that ALMOST works, but not quite well enough to trust it to actually run your robot.

The root of the problem is that PBASIC is very powerful but has some serious limitations. I am not sure that autocode generation will really help (whether it is a graphical interface or any interface) because the limitations are still there.

For my money, I think that it is better to learn the Zen of PBASIC and deal with that.

BUT… …There are a few “macros” that if someone wrote, I would be very grateful for:

  1. the ability to have a single “header” file for all modules with all variable, alias & constantant definitions. As it stands, when I use several programing slots, I have to have the same declaration in many files. This can lead to subtle errors if I fix something in one file and forget to fix it in another.
  2. an IF-THEN-ELSEIF-ELSE structure
  3. something like the “macro” function in C (or C++)
  4. way of having common subroutine definitions that would allow a singe definition of a subrountine that is shared by multiple programming slots (subroutines with names like “GetData” & “PutData” come to mind).

I am thinking about basically a VBasic program that would allow code to be edited in a single file on a standard text editor (e.g. Wordpad) and then sent through a string edit process that would include the header files, substitute the macros & other cool stuff like IF-THEN-ELSEIF-ELSE. The string editor would then break the code up into seperate files, one per programming slot. In an ideal world, the VBasic program would break up into the needed slots, but I suppose this would add more complexity than I think is worth the bother. I recommend just having some tags that let the code writer define the slots as needed. Finally, the Vbasic program would open the Parallax tokenizer/downloader/debugger and download the code, passing any errors back to the user.

The last step of dealing with errors could be tricker than you might think (e.g. Is this problem the coder’s fault or the Vbasic program’s – could lead to very confusing finger pointing, to say nothing of the error messages themselves).

Anyway, this kind of code seems to me to be of much more use than the initial proposal.

Does anyone else share my view?

Joe J.

#7

PBASIC has some quirks, but its far better to learn to use them to your advantage than to attempt a work-around.

The graphic thing with function blocks is a great idea, but its more useful for concept development than for code generation. My limited experience with code generation software is that the resulting code was bulky and “traditional”. Works though.

Joe alluded to the possibility of a buggy compiler. Bugs happen to the best of programmers. Whatever software gets distributed has to be thoroughly validated by an independant. Not just tested by a few users.

The folks at parallax are extremely clever. When you use all the features of the Stamps, you realize why the language is the way it is. Much of what the Stamp does well is forbidden to us.

You can cram a lot of function in a stamp by learning the “Zen” of PBASIC.
It would be nice to have a real IF-THEN-ELSEIF-ELSE structure though.

#8

I think it’s important to realize that one of the long term goals of FIRST with respect to the control system is to diversify the applicable programming languages that can be used. When I talked with Eric Rassmusson about it, his opinion was that they should go for some way of swapping chips or some such that would allow different programming languages to be used. Basically, you’d replace a PBasic chip with a Java chip and you’d then be programming in Java. I believe the languages he was interested in were C, Java, and PBasic although if you have any other suggestions about it, I’m sure he’d be interested. This is something that will most definately not happen this year but in the next couple years is a distinct possiblity.

Matt

#9

Interesting that this idea came up. Near the end of last year, our resident programmer wrote a simple program (in C++ i think) that had a menu for selecting programming options. You could click things like one-stick drive, or deadstick, or even a simple gyro balance program, and it would compile them into a PBasic file. If anyone is interested in seeing this, I can try to get the program from him. It’s not as complex as what was originally discussed, but it might help rookie teams with simple programming.

#10

I, too, have to agree with Joe. While PBasic is not the most intuitive programming language, it also has a basic simplicity which can be attributed to some of its power.

Engineers know that problems exist, and we have to find ways to deal with those problems. The programming language of choice is no different. In order to help our programming (this was my first year in PBasic by the way, learning in January), we found it was easier to write down on paper what we wanted the program to look for and the appropriate action (if switch1 is open and switch2 is closed, then turn relay1 to on), and then negate the line as needed. The previous example would “normally” be written as “if switch1 = 0 and switch2 = 1, then relay1 = 1”. After negating, the line in PBasic would be “if switch1 = 1 or switch2 = 0, then relay1=1”.

A flowchart is a great way to teach the students, and they can understand the concept of negating how we would normally write an instruction line of code. Simply change and’s to or’s, 1’s to 0’s, and so forth.

Again, its not the most intuitive way to program, but not impossible.

I’ve heard from other engineers and at the team forums that FIRST is about learning and motivating the students. What a better way to motivate the studetns than to teach them some programming. Icons and Simulink are great tools, but it also “dumbs” us down. If we make it easier to program, then maybe we should give each team a complete drivetrain, a few pre-built arms and special action mechanisms, and let the teams simply bolt them together?? Let’s motivate the mechanical students with motors and gears, and motivate the computer students with the programming. When some of my students fonud out that the control system in front of them (including Victors and Spikes) cost $2000, their jaws dropped. All of a sudden they wanted to know how to use the stuff.

The programming isn’t that difficult (especially when a default program is available right out of the box), so long as there is time to write the code. If the team is still assembling and making design changes in mid-February, then I feel sorry for those people who have only two days left to program.

Innovation First has developed a powerful control system for FIRST, and for the number of units they supply to FIRST (only once a year at that), I think it would be a lot to ask them for additional resources to change the programming language so that our lives our that much easier.

Just my humble thoughts.

Dave…

#11

I too would have to agree with Joe and Dave, but if you think, (like Dave has told me) you have to “think backwards.” I like the programming language, and I am eager to learn, but that manual isn’t too inviting…

Thanks for the help Dave!!!

#12

*Originally posted by Matt Leese *
**I’ve sort of had this idea in the past and there was one thing that I realized made it fairly unworkable. The mainthing is that there is no documentation for the assembly language used by the Basic Stamp 2X and there is no documentation on the communication between the two systems. Also, don’t underestimate the complexity in writing a compiler. They are large and complicated pieces of code. But if you do seek to go this route, best of luck to you and please ask about any difficulties you may run into.

Matt **

The assembly language used by the Basic Stamp is indeed documented. IIRC, it runs on a PIC Microcontroller. Microchip is the company that makes these little gems. Now, how they are used in the Basic Stamp system I am not sure of. They are, of course, made by Parallax. Again, IIRC, there is documentation on the Stamp’s architecture. So then the only missing piece is the architecture of the Robot Controller its self. I’d imagine this could be reversed with some work. Or perhaps the information could be begged out of Innovation First? Weren’t there some people maknig their own controllers at some point? Cross-compilition I agree would be an intresting task. I’ll be intrested in following this. :slight_smile:

#13

Actually, the Innovations First Robot controller in the kit uses the Parallax BS2SX stamp that is based on the Scenix (now UBICOM) SC28AC/SS communications controller. This is a 50MHz (mostly) single cycle RISC micro with EE/Flash progam memory. The Parallax BS1 and earlier BS2 families were based on the Microchip 16XXX PICs. That being said, as an embedded controls software designer, I will agree that PBASIC is very ‘clunky’. But it is simple to learn for an educational process such as we have here. It would be nice to program this device using ‘C’, as pointed out in the earlier discussions. I personally have mused many a time about ‘fixing the problems with PBASIC’. I would agree with Joe, the way I would attack it is to define a set of extensions to the syntax of PBASIC that give the constructs that you are looking for (i.e. IF THEN ELSE, those darn funky operator precedence rules, etc…). Write the PBASIC code mixing in these extensions as needed. Write a pre-processor (in the language of your choice) that reads in the file with source code and extensions and outputs a generic PBASIC syntax source file. Load the PBASIC generic source file into the toolset, compile and download. This way, those that choose to use the extensions can, and those that do not can use the old method. Probably the best ‘bang for the buck’ without getting into a significant amount of effort. My .02

Kurt Ehrhardt
Engineer and parent
Team ‘Buzz’

#14

I would really like for this tool to be developed. It would really make a lot of our lives easier.

By the way, even after 6 years of using these things in FIRST and in my day job from time to time, I STILL get caught by the operator evaluation order and by things as silly as expecting a “MIN 0” to actually DO something.

I have gotten used to it, but it is still too easy to screw up and loose a day of programming chasing a silly bug that would not have been a problem but for the Zen of Pbasic.

Are there any Visual Basic or Visual Scripting folks out there that are also Open Source Fanatics?

If so… …get coding…

Joe J.

#15

I’ll consider this my new side project…start posting requests for what you want as a part of it. Either here or a new thread, it’s up to you…

#16

*Originally posted by Joe Johnson *
**
…There are a few “macros” that if someone wrote, I would be very grateful for:

  1. the ability to have a single “header” file for all modules with all variable, alias & constantant definitions. As it stands, when I use several programing slots, I have to have the same declaration in many files. This can lead to subtle errors if I fix something in one file and forget to fix it in another.
  2. an IF-THEN-ELSEIF-ELSE structure
  3. something like the “macro” function in C (or C++)
  4. way of having common subroutine definitions that would allow a singe definition of a subrountine that is shared by multiple programming slots (subroutines with names like “GetData” & “PutData” come to mind).

<snip>

Joe J. **

I wrote a program last year (in Delphi, appropriately enough) which is quite similar to what Joe J. suggested. It preprocesses each program of a BASIC Stamp project and inserts a header file into it.

In its current form, it recognizes the standard '{$STAMP …} directive as well as two new directives: '{$INCLUDE …} and '{$StampPPDate}.

The '{$STAMP …} directive is used to determine which program files belong to the project so that it can preprocess all of them in one swell foop.

'{$INCLUDE …} causes the specified include file to be inserted into a program file.

'{$StampPPDate} causes the date and time the project was preprocessed to be inserted into the source. I added this directive so that I could print it out at startup and get warm fuzzies about the version of the program currently loaded into the robot.

Currently, the preprocessor renames the input files (appending .bak to the files names) and creates new files. I am planning on reopening the code and coming up with a safer scheme – like maybe generating a set of files with a common prefix so that all the files in a project appear together in a sorted directory listing. The prefix might be the date and time or a version string. I’m open to suggestions.

I will probably try implementing $IF, $ELSEIF, $ELSE, $ENDIF directives ($THEN is kind of superfluous isn’t it?) and I will think about a $DEFINE macro capability.

As for the “common subroutines”, Joe, are you thinking about generating code which will make a call to a subroutine in another program slot and then return when it’s finished? I tried something like that before, and decided it wasn’t worth the effort. Or were you thinking of a “common” routine which actually exists in each of the program slots, and would be called locally? That certainly seems doable. As a matter of fact, it could probably be done with the program as it currently stands: Just $INCLUDE a file which contains the desired subroutine in each of your programs.

If anyone is interested in getting a copy of what I currently have and/or whatever I come up with, just e-mail me. I offered it last year, and only had one or two takers.

Greg Ross

#17

This thread has been adjourned to the Technical Help Forum. Please go to Improving PBASIC: Request for Comments