vex forum programming project :)

VEX V5 General Discussion General Forum
#1

i was thinking on how to make autonomous’ “easier” to program without the tedious run, adjust variables, re-download, re-setup, cycle

i was thinking of making a program that “copies” (records all input data) the drive movements
so that way, all you have to do is to drive the robot for 20 sec autonomous (1 min for challenge) and it will get ALL the data for you :slight_smile:

now i know this is HARD to do, but maybe we can brainstorm ideas on how to do it and work on it as a “group project”. and if we ever get it done, then everyone can benefit from it! this would be most useful for rookie teams or teams with little programming background.
what do you guys think?

IDEAS:
have a way to record the motor direction and speed
have a “print screen” every time a input value changes (ALL the sensors (pot, encoders, ultra, line) and motors)
have another program that extracts the print screen data and make it manageable (delete repeats, ect)
have another-other program do compile all that data into a file that can be read by the micro-controller (no need to drag and drop/type all that code back in)

i know this seems far fetched, but with a forum of bright engineers and s a handful of professional coders, im sure we can pull this off!

#2

It’s a novel concept but hard to do unless you already have encoder based driver control (i.e. your joysticks output a ground speed rather than a maximum PWM count). Otherwise the only commands you’d be sending it would be to “drive at 255 for x00 milliseconds” which isn’t that useful

#3

Well the first part is easy, but then the rest requires external modules which would probably need to be custom built. I think what you could do is use the UART port and print the values to a computer through serial, then process the output through a computer and then generate code using .NET or something like that.

Now comes the part which is probably never going to happen because of IFI. I have yet to hear of someone being able to create or find a compiler that can compile code for the cortex. So we would probably still need to copy and paste the code into robotc and compile it.

As for the tedious adjusting of variables, why not just create a program that can adjust itself?

#4

I spent far too much of 2010 working on just this. We used the joystick buttons directly as opposed to gathering values from sensors and I created a bash script that did all the processing. It worked fairly well in that we were able to make a robot copy the movements input from the controller perfectly. (Perfectly enough that we could have easily won most 20 second autonomouses at competitions with it - although we can win those already anyway…). Unfortunately, we only used the digital buttons which made driving less efficient than we would have liked and required plenty of driver practice. Finally, as Chris is me notes, it wasn’t that useful. Indeed, not much more useful than using ‘waits’ for programming as the battery level is just as critical with either method.

On the other hand, I learnt tons of stuff in the process.

#5

Yes, with vincents program, having to drive with the buttons on the joystick made it very hard and inefficient to drive - personally I think it is better to use sensors and do it the traditional way… I spent a couple of days trying to get a good run for the 20sec autonomous which could have been done quicker with sensors, and would have been more accurate… But I’m not trying to say it’s a bad idea, just that it has flaws which need to be worked through before it can be effective :slight_smile:

#6

There is an external program (Simulink) that can write an EasyC program, and load it into EasyC for you. But cut and paste works too.

Closed loop (with sensors and encoders) is more reliable than timed driving for autonomous.
If you have one button that triggers a print of all current encoder values to the terminal window (by leaving the programming cable plugged in), you can print the robot mechanism state at each step. That saves removing all the repeated variables. For a simple model of a clamp bot, there are 4 sensors: leftwheel, rightwheel, arm position potentiometer, clamp open/closed.
Put these list of encoder values in an array, and write an interpreter program to read the and execute the array step by step. If the values need to be tweaked, they are all located in order in one compact spot.

This method has the potential let auton operate smoother than driver control, since the interpreter code can include PID, speed ramp up/down, and can more easily control arm and wheels at the same time.

#7

Haha! That is so funny, just a week or so ago this idea came back up on our team, me and one of the other team members wanted to get together and work on it. Maybe we can make some progress with it here!

~Jordan

#8

I was working on just this a few months ago! As everybody has pointed out, it wouldn’t be too useful to simply map motor values, because that’s just as accurate as using wait statements with motor values (not accurate at all). But I got around the problem by integrating encoders, ultrasonics, and potentiometers with the joystick values. It’s great when you need to have an autonomous quickly, like the time in between matches, but not terribly useful otherwise. It’s more efficient to code directly, but this is definitely easier. I’ll try to find the code, but I’m pretty sure that I lost it in a computer reformat.

#9

Join the club :stuck_out_tongue:

#10

Back in December, I had an idea of how to completely make my autonomous modular, so it was literally just calling functions in a timeline.

It worked by having 2 functions (you could use more), 1 for the drive train and a 2nd for everything else.

To complete this you need to first figure out all the basic building blocks that you might use for autonomous (ie. Follow line for [distance], raise arm to [height]). Once you have all of the blocks built, you build a timeline in the main task that consists solely of function calls, timers and the changing of a global variable (to let the other tasks know the current location within the main task)

You could even break the functions down into fist and second level functions. First level functions would contain a single action like go forward:

(I am aware that more then one motor is needed in most circumstances, but this is for the sake of example and I don’t really have time to write a bunch of code just for a forum post)



void straightForward1(){

If(SensorValue(dgtl1)>1000){
motor[port1] = motor[port1] - 10;
} else {
motor[port1] = motor[port1] + 10;
}

SensorValue(dgtl1) = 0;
}

Second level functions contain a while loop (or similar) and loop back to a first level function. The following example goes forward until a bumper sensor is pressed:


void forwardToBumper(){

while(SensorValue(dgtl10)=0){
straightForward1()
}
}

The idea is that the second level function manages the action “until” something happens. you could also include parameters that modified how far the robot traveled. The two level structure allows me to create multiple functions for controlling the first level actions and in theory reducing the amount of code needed and allows for easy creation of new paths, because it is all based on basic building blocks that can be assembled like LEGO.

If I didn’t do a great job explaining this, or you want more information just let me know in this thread or PM me. Unfortunately, I don’t have a complete example of this to the fact that I switched to a different robot (completely different) 2 weeks ago, but I am now working on a completed version of this for this new robot and will both the code when it is finished.

#11

Yep, using modular code definitely helps. It prevents redundancy in your code, as well as making it easy to read, write, and modify.

#12

but does it take up more memory space?
this week was the first time i hit the micro-controller limit (i used the modular functions too)
the main thing that ate the memory was the autonomous and the skills autonomous
i think creating functions will use up MORE memory then straight forward commands

last year i used straight forward motor commands throughout the whole autonomous code (super long) and i had four of those copied and pasted (different starting positions)
the redundant and time consuming and confusing way of doing it did NOT max out the memory

that was just a question that was bugging me
at least the functions can be stupid easy to understand, that you can get ANY team member to “refine” the autonomous by changing the variables

#13

You hit the micro-controller limit o.0? Might I ask what you were doing? And I don’t think that using functions should take up too much more memory than straight coding.

#14

I unfortunately never got the chance to test out the entire thing on the cortex, as i moved to a different project. I am currently developing the same Idea on a different project.

As for the memory, it shouldn’t run out of memory, because adding extra autonomous paths only adds a small timeline. I also used 2 levels of functions to help conserve memory. Also it would be possible to optimize this by omitting certain functions, but that will come later. In addition, the lowest level functions contain the most (and most complex) code, so memory is really a big concern right now.

#15

oh, i forgot to mention that this was with the old pic micro controller (with the vexnet upgrade)
not the cortex
im not THAT wasteful with memory :stuck_out_tongue:

#16

That makes a lot more sense now

#17

Using structures uses less memory for some reason, I dont know how it works but im able to load my entire framework onto the PIC, and before I switched to structures I was unable to load it on because I kept running out of memory. So if you get severe warnings during the compile, consider using structures instead.

#18

Are you talking about structs:


struct{
 int motorSpeed;
 int driveRatio;
}drivePoint;

or programming with functions?

#19

We have made our autonomous programming completely modular using tasks and functions. It definitely speeds up autonomous programming once you finish perfecting your functions. We made ours have ramp-up/ramp-down, auto-straightening, and of course the ability to change the speed and sensor you are traveling by.

Being able to use tasks to run multiple parts of your robot at the same time is essential to having the fastest running autonomous as possible, and beat the other teams to scoring/beat them to the goal and block. (Or hanging, if that ever happens/has happened in the 20-second autonomous mode.)

Also we have too reached the VEX PIC V0.5 Microcontroller memory limit, which was a big reason we switch to the Cortex. Now we have over double the amount of code from last year, and have still not reached the max limit. (As we still have a far way to go to do that, and I assume will never reach that point.) Using functions and tasks to make your autonomous modular would save you space, not take up more, as you will only have one or two lines for every time you want the robot to do something, as opposed to having to copy and paste the same most likely >100 lines of code over and over again.

~Jordan

#20

Tasks (in robotC) make parallel programming easier.
Functions/subroutines in either language should make the compiled code shorter.

My understanding is that RobotC mastercode is running an interpreter on the CPU, which is then interpreting your program. This means the same program will run on either PIC or Cortex, but the interpreter (provided by RobotC) had to be rewritten for each CPU.
Occasionally in my day job, I do assembly level code writing and optimization, so I was interested to see that RobotC lets you view the assembly listing. You can use this to see how different types of C constructs get translated to their ASM. For example, when I checked, If/then/else vs trinary ( test ? true : false) they compiled to about the same length.

So if you are using RobotC and running out of memory, you can try programming in different ways and then look at the assembly listing view to see which way takes more space.