Having read through the code, I have encountered some problems. Me and my programming fellows tried and put the differend available scripts. (CMD_DRIVE) for example. However, we were getting many problems when compiling this with MPLAB.
Any example of using the scripting commands and where to place or modify them would be great. Also some insight in the “Commands.h” file. We want to know why there are 4 CMD_DRIVE calls and other multiple calls.
Thank you
-EdmundScripting is still in the developmental stage, search Kevin Watson’s (the scripting developers) posts.
The commands.h file is just a single variable. It is an array of a custon data type called commands. The commands data type has four values: an int called command which stores the command type, a long called param1 which stores the first argument for the function, and two more ints called param2 and param3 to hold more arguments if needed.
The robot.c file goes through this structure line by line and executes. For example the default code
{CMD_GYRO_BIAS, 0, 0, 0},
{CMD_WAIT_FOR_BUMP, 100, 0, 0},
{CMD_WAIT, 1000, 0, 0},
{CMD_DRIVE, 1500, 0, 0},
{CMD_WAIT, 4000, 0, 0},
{CMD_TURN, (-1500), 50, 0},
{CMD_WAIT, 3000, 0, 0},
{CMD_DRIVE, 2400, 0, 0},
{CMD_WAIT, 4000, 0, 0},
{CMD_TURN, (PI_MRAD / 2), 50, 0},
{CMD_WAIT, 4000, 0, 0},
{CMD_DRIVE, 2400, 0, 0},
{CMD_WAIT, 4000, 0, 0},
{CMD_TURN, (-1500), 50, 0},
{CMD_WAIT, 1000, 0, 0},
{CMD_DRIVE, 0, 0, 0},
{CMD_KEEP_HEADING, 240000, 100, 0},
{CMD_JUMP, 1, 0, 0},
{NULL, 0, 0, 0}
would execute something like this:
The reason the numbers are so big in the parameters are, if you haven’t guessed, every thing is in thousanths. This eliminates the need for decimal math and makes the program run faster. Most of it is really straight forward, requireing only one argument. It is good practice to fill the unused paramaters with a 0, even though it doesn’t matter what you put in it.
The reason tolerances are needed is that the robot will rarely ever get back to where it thought it was, so if there was no tolerance, the robot would continue to twitch, thinking it was always off by a fraction of a radian.
Anyways, I hope I have cleared thing up a bit. If there is anything else you need, don’t hesitate to ask.
-Tony K
Anthony, your grammer indicates that you are up past your bedtime, it is late, go to bed, and sail the silver seas of dreams.
Wow! Everything is cleared up. Thanks.
One more thing. After modifying the functions and numbers in the structures, how do you add this WHOLE struct into the autonomous mode? What exactly do you type in there?
We tried some different calls but they seemed to not work: “commands” “commands command_list]” “command_list]”
(Remove the quotes of course)
Please and thank you in advance.
-Edmund
I have a question regarding tolerance.
What exactly is it? Is that how far the robot can deviate from the turn it’s making, meaning a lower value is more precise but a higher value requires less small movements to get “back on track”?
Without looking at how they have implemented it in the code, I would expect that you are right.
The autonomous mode call is already there “robot_control();”
Exactly. A lower tolerance lets you be more precise, but it is going to take longer to get it correct. A higher tolerance is going to be a little less precise, but will execute the command faster. Your choice depends on what you really need. To you have a short time to get to a general area, or a little more time to get to a more specific area. Just as in most everything else, its all about trade offs.
And Edmund: You don’t call the variable, you call the function robot_control(), as CJO said. This funcation interprets the script variable you put in commands.h and executes them on the robot.
-Tony K
The difficulty with this whole systme is that the current version of the camera control system relies on being where the robot_control() function is located. So, heres hoping the camera gets better.
As I’ve read, couldn’t you make the camera function in robot.h then put the function in commands.h , and call robot_control(); in autonomous mode?
Would this work?
Yes, you could make it run in robot.c. The problem is that you would need to add the camera drivers to the kickoff code, which might cause some problems. You would then have to write your own new functions in robot.c before you coudl call them in commands.h. Granted, it wouldnt be to hard, but it would still take some time and effort.
-Tony K
P.S. I will post a list of all of the robot commands and parameters some time soon.
Viewing this system, I am frightened. This looks almost exactly like the system one of our programmers developed and tried to implement, but it was very unwieldy. If the use of this system requires the amount of sensor input I’m reading, are younger teams going to be able to implement it?
The biggest problem with the comera is the serial drivers, however, never fear, Mr. Watson is hard at work, so, I am hoping that this is a porblem which can be overcome.
Mr. Watson, you have some of the biggest critics and biggest admirers from our team. 
Thanks in advance for your hard work and good luck to all teams with these new concepts. I know our team is definitely looking into much broader fields…
Is this really a “scripting” thing? I’m kinda disappointed…I was expecting raw text and prettiness, as implied by “scripting language”. Not that it’s a bad thing, I just think it’s more of a “shorthand” way to call functions than it is scripting.
Let’s put it this way: If the guy who comes up with the autons isn’t on the programming team, he can still write the autonomous code. (with a little coaching)