Hi, would this code work as an autonomous code ?
it is just i have been having problems, i think i have done it completely wrong
if it is wrong, can someone give me some pointers
… NOTE … The Times are all rubbish … need to actually time the stuff
Here Is The Code !
task autonomous()
{
wait1Msec(100);
motor[drivel] = -127;
motor[driver] = 127;
wait1Msec(500); //how long it takes to turn on foam tiles
motor[drivel] = 127;
motor[driver] = 127;
wait1Msec(150); //how long forward until lined up
motor[drivel] = 127;
motor[driver] = 127;
wait1Msec(150); // how long until it gets 2 stack of sacks
motor[in1] = -127;
motor[in2] = -127;
wait1Msec(200); //how long for sacks to intake … average … guess ?
motor[arm1] = 127;
motor[arm2] = 127;
motor[arm3] = 127;
motor[arm4] = 127;
wait1Msec(200); //how long to lift arm to right level
motor[drivel] = 127;
motor[driver] = 127;
wait1Msec(200); // how long until it gets to the troth
motor[in1] = 127;
motor[in2] = 127;
wait1Msec(200); // how long to get rid off sacks
motor[drivel] = -127;
motor[driver] = -127;
wait1Msec(200); //how long 2 get back to start tile
motor[drivel] = -127;
motor[driver] = 127;
wait1Msec(200); //how long 2 turn
motor[drivel] = -127;
motor[driver] = -127;
wait1Msec(200); //how long 2 hit start tile, so we can reposition
}
You never have the motors being set to 0, and I’m assuming that you want them to stop. If you’re just going forward, then immediately backward, you might not need it to stop first. However, for many of your actions you probably do. After the “wait1Msec()”, function call, you’ll want to set the motors power equal to 0 so that they stop. They won’t do this on their own.
Out of curiosity, are you comfortable with shaft encoders? One of the main problems with moving for an amount of time is that the amount your robot will travel in 1 second depends on how fast the wheels are spinning, which are directly related to battery levels. Thus, as your battery levels fluctuate, your distance traveled in a given amount of time will to. Sometimes it’s a big change, sometimes it’s hardly noticeable, but there it is.
Enter the encoders. They attach to the shaft of the wheel and keep track of how many times the wheel has spun. Since you know the diameter of the wheel, you can use that to calculate the circumference (and thus the amount the robot will travel in one wheel rotation). Then, you can tell the robot to go forward a very specific amount of distance via the use of wheel rotations. It’s still not perfect (it won’t account for wheel slipping, if you run into another robot or a wall) but it’s a bit more precise than time-based auton.
As the code sits now, LegoMinds is correct; you generally want to make a movement, a quick stop, then a movement. The stop doesn’t have to be long, just enough to stop the robot from coasting before making another movement.
Yes ! … i know how to use these, i wanted to order some, we have had our funding cut, so the sensors / programming hardware cable / field controller have all been cut from out september vex order (via . active robotics) … so i was planning on using them, but because of lack of funding, this probs wont happen … but i am debating buying them myself, and when i leave take them with me …
thanks
p.s. if anyone wants to sell some encoders/program harware cable/field controller … will buy them of you for a reasonable price !
It would work, but it won’t be very reliable due to variables such as battery level or friction. I would suggest you use some optical shaft encoders or the integrated motor encoders and power your motors proportionally to the distance away from the desired point, like this:
int Kp = 2; //Proportional constant, try number between 0.5 and 3 to start with
int sp = 0; //Set point for encoder, change this for desired distance, negative numbers work here too for going backwards
while(true){
int error = sensorValue(Encoder) - sp; //the difference between your current position and desired location
motor[port1] = error * Kp; //error times proportional constant, this scales the motor output by the value of the constant
}
so instead of using only waits, set the set point (sp in this case) to the desired value, don’t forget to take into account that the encoder values will only reset if you tell them to:
if(step == 1){
sp = 200;
if(sensorValue(Encoder) >= sp - 5 && sensorValue(Encoder) <= sp + 5){
sensorValue(Encoder) = 0;
(go to next step, you can use a variable for this, like step == 2; )
}
}
Edit: just saw your post, i would suggest buying a few sensors yourself, they could save you from some frustration.
Potentiometers are only good for arms or other devices which only have <250 degrees of motion. Quadrature/Optical Shaft Encoders are meant for drivetrains.
If you don’t have the funding for the encoders you can get away with time-based coding, the best thing you can do to ensure consistent auton periods is to make sure your batteries are topped off as much as possible before the match (which you should be doing anyways ) That way, the battery levels will be as close as possible at the start of each run.
We have 2 x 3000 mah batteries that we cycle and charge per match, and we also have a 2000mah battery but i think it is damaged (try not to use this one)
but if it becomes a defo thing to no new sensors … will have to fund them myself … which is a pain
If money is more of an issue than time, you can make your time-based code even more effective by incorporating the battery’s voltage into each steps timing. You can time each step of your autonomous routine at different battery voltages and then either graph them and create a function or make a table that will make each step-time vary based upon the battery’s voltage (which can be retrieved in the programming). It’s labor intensive and still doesn’t beat encoders, but if you have the time and lack the funding it’s always a possibility.
Yes, i know what you mean, i am hoping to convince our accountant to buy them, but it is probs gonna b a no … i think i am going to have to buy them myseld
Don’t use quadrature encoders if you can avoid it.
[LIST=1]
*]They use 2 ports: rather intensive on a robot with multiple points to measure
*]They’re huge: just look at the pictures. We had to remove them at one competition because the cables were sticking out over 18 inches. They’re also generally a pain to install on drive trains.
*]In ROBOTC at least, it’s slightly more complicated to use the quad encoders.
[/LIST]
Integrated motor encoders are better: all (8) link to one port (I2C), they have a slim form factor, fit neatly on the back of any motor, and they are registered together with the motor in ROBOTC.* However, they are more expensive ($+10/unit).
*You can simply specify the motor to read, instead of the sensor port. I understand easyC has made improvements in this functionality as well.
Ok, well from what i have been reading about them, they are fairly easy 2 program in robotc(program i use) and i saw a sample program, and from what i gather it is fairly easy to code, with the size, i did think about that, but our robot at the moment is 17X17X15 inches (can easily reach top goal), so size doesn’t matter, and with wiring, i have a set of extension cables that i can use … and i know that there is two ports but we have 10 free ports, and i only plan on using 2 —> 4 ports, and yes, i did look at intergrated motor encoders, but as you say more expensive … i think that if i can justify spending, they will go for the encoders … thanks for your help, but … if i can get the funds for the intergrated motor encoders, then i will … just depends on the dosh …
We have been using a timed autonomous routine since the beginning of January and have scored in autonomous every time except for once when a sack slipped out of the hopper. It takes some patience to get it right but it can be done. With that being said part of the secret to our success is a fresh battery ***every ***match.
We just purchased encoders this past week with hopes of being able to write an autonomous that will score 6 green and 1 gold bag, but we are keeping our old code as a fail safe.
We were running under the lower goal by a couple of inches so instead of spending a lot of time trying to perfect that we chose to raise our hopper and intake roller before we approached the goal which solved that problem. Our robot base continues for a fraction of a second causing about a 10 degree tilt, but it still seems deadly accurate.
So don’t let the lack of encoders discourage you, just keep your batteries charged and be persistent in your efforts.
this post is old, and since i got us a business sponsor, and with the money i bought encoders, potentiometers, programming kit, batteries, 393 motors, high strength gears, speaker etc … etc
and yes we did have a timed version and it worked but no always … i am waiting for our robot to be completed, and i will do some coding for autonomous and get it done …
probs a week tops and i will do a reveal of 5119, and 5119z
) That way, the battery levels will be as close as possible at the start of each run.
… just depends on the dosh …
… i am waiting for our robot to be completed, and i will do some coding for autonomous and get it done …