Hey all! Alright I have a question about measuring the values in the code. When you put the program into the bot and your using a motor to rotate you put in the number that will rotate the motor the right amount right? Well suppose that U put on a pully to the motor (in this case the globe) and figure out the exact number to make the globe rotate 1/4 of a rotation or 90*. Well if you divide the number you get by 90 (the degree achieved) then you SHOULD get the numerical value that sould represent how many program loops are needed to achive this distance, correct? Please tell us if we are right, thanx.
Sounds right to me. FYI, in one second the pbasic code will loop about 40 times, depending on the amount of code and probably the temperature (cold=faster).
We did something similar in our robot this year, but we rely on hard stops so the motor will stall for a little while (no more than 1/2 sec) before the program tells it to stop. This way if it gets hung up for a second or the loop executes are slightly different speeds, we should still get the needed rotation from the motor.
that is one way to do it but if you want to go with the fun way you could get yourself a potentiometer and attach it to the shaft of the motor. starting at lets say 127 you would turn 90 degrees and use debug to find out the value of the pot at that angle. you then find a speed that you can tell it to turn until you get to that angle. the correct speed would be whatever the highest speed you can make the motor turn without it passing the point. globe motors arent that fast and stop pretty quickly.
if you want to get a bit more advanced you can have the speed go on a curve according to the pot value. (ie when the motor is furthest away from the value you want the faster it spins and the closer it is the slower it spins)
if you want to try this and need some help with it feel free to ask me. my team is using this same scenario for our crab drive and it works really really well.
Our team had a very similar problem last year, when we were trying to write our autobalancing code. We tried about a billion different meathods, my favorites being: a pedulum on a pot, and stopping the motors when the pot was 127; magnetic switches on one wheel as well as the frame next to it, and counting the number of trips of that switch (we found that this did not have good enough resolution, since we had to be within a few inches), but finally, we simply decided on this: We use a gyrochip to measure when it starts tilting, after this moment, we run the motors backward for a certain amount of loops. This gave us a resolution of 1/40 of a second, more than enough. This is nice because you can debug it really nice:
RUNTIME con (# of loops)
counter var byte
counter = 0
This way, we could calibrate in a second to any bridge at the comp during the practice round by adjusting RUNTIME at the top of our code. This gives you the resolution you need. You could put it in your mainloop as well, if you want to.
*Originally posted by Mike o. *
**Hey all! Alright I have a question about measuring the values in the code. When you put the program into the bot and your using a motor to rotate you put in the number that will rotate the motor the right amount right? **
Maybe a little clarification is needed here. When your program outputs a number to the PWM, it applies a voltage to the motor that make the motor turn at a speed for the given load on the motor. If your load on the motor changes so dose the speed. If I understand your question, you want to rotate the motor a certain distance. To do this you would have to have something that could provide a time reference to your program and the motor load would have to remain constant. I’m sure you are starting to see the problems in this method on controlling distance.
Now a better way. As was referred by the other members, feedback control. Try using limit switches or a potentiometer input to limit the travel of the motor. Limit switches can be used if the travel distance is fixed. Potentiometer feedback can be used if the distance will be variable.
Potentiometers and limit switches would solve this problem.
We chose to use hard stops with timeouts. This is a more robust solution (less parts to break… limit switches are very cheap & weak, especially in a hardcore compeition like this year) and could be implemented quickly. It’s pretty much foolproof… you don’t have to worry about overextending your motor because a limit switch fails.
It works great, and anyone going to the New Haven, CT regional can stop by and visit team 562 for a demo!