in case of EMERGENCY, is a loop of NOPs an option?

[JesseK]

You can't do for loops on the current controller iirc, but I programmed very little of it in the last 2 years.

nOPs are good enough in a jam, but you design the bot, sensors and programming other way -- the way that DOESN'T use timers/nops to get to where you want. nOPs usually lack consistency in mechanical control.

[Qbranch]

Originally Posted by JesseK

You can't do for loops on the current controller iirc, but I programmed very little of it in the last 2 years.

nOPs are good enough in a jam, but you design the bot, sensors and programming other way -- the way that DOESN'T use timers/nops to get to where you want. nOPs usually lack consistency in mechanical control.

Easy partner... hardware timers are ONE OF THE best and most accurate ways of timing when code executes, or upon what interval. A must for true, high performance PID/LeadLie/StateSpace loops.

Uhm... but I'd still like to know... why do you want to make a for loop of nops?

One of the only times I've used one of these for FIRST is in my single-pin Parallax ultrasonic driver (posted here) to generate the keying pulse to trigger the ping, since it was a very short (just a few microseconds) pulse time, and would have been inefficient to set a timer and come back just to time such a short pulse. Actually, the amoount of time it takes to enter/exit an interrupt would have been longer than the duration of the pulse, so, the best option in that case was to create a for loop. It's important to note that nops are not needed in the for loop to make a spinlock/busy wait. only:

for(unsigned char delaycounts = 0; delaycounts < 10; delaycounts++);

But yeah i'm still wondering about what the long for loop has to do with making a motor not 'skip'... and how you make a motor 'skip'...

-q

[JesseK]

Easy partner... hardware timers are ONE OF THE best and most accurate ways of timing when code executes, or upon what interval. A must for true, high performance PID/LeadLie/StateSpace loops.

I'm not trying to be rude; it's just that I've seen this in control systems projects in college, at my current job, and in FIRST robots who dead-reckon their autonomous.

Your controller generally has the same voltage inputs and has a low power consumption. Therefore, on a FIRST robot it can output the required PWM signal to the Victor regardless of the battery voltage. However, if the battery isn't always at the same exact voltage the actual amount the motor turns will be different every time you run autonomous.

In the original poster's case, nOPs are good in an emergency situation, however it is very dependant upon the battery manager of the team ensuring the robot has a juiced up battery every time. You'd be surprised how many times you start a match with "charged" 10-11v battery simply because there wasn't enough time to charge it between the last match and your current one or someone mixed the batteries up. It also takes several hours to go from 12v to the max 13.2v. The point is, over the course of a day you'll probably almost never get consistent voltages. For mechatronical timing to work as suggested, the power source MUST be constant. It works in a pinch, but it's generally bad engineering to do in the long-term.

I believe the easiest-to-design sensor in this case would be a black mark on the shaft with a light sensor/line detector in conjunction with a state machine in the code in order to determine when the shaft is at the correct position. This will consistently get you to the correct spot every time. You can reference some of the photos in FIRST: Behind the design, team 111's feedback sensors for the turret. If the shaft must do more than one full rotation, you can either try to account for that in the code or use a shaft encoder instead.

[3dude_2231]

thank you guys for replying,

for you curious guys, we lost one of our sensors at the regional
(a magnetic sensor, giving us logic '1' whenever 2 magnetic plates are near).
(un)fortunately, autonomous didn't work right anyway, so it wasn't a problem =/
I was thinking, .....if we had to make a quick solution...............

now, I'm thinking more of using an unused TIMER (3 I think is unused by us)
with a prescaler, and multiply that period,
so nothing goes wrong.

we might just as well prepare extra sensors, but it could take some time to fit them.

[Qbranch]

Okay... but why use nops? You really should (and its more stable this way) write your code re-entrantly, so that it can freely loop as the system lends itself to.

Personally, even when dead-reckoning a machine, I like to write a script executer so I have a simplified language i can quickly write autonomous scripts in (case in point, the debut of RALFF on our sweet 2006 adaptive autonomous mode) and lets you have multiple programs loaded that are switch-selectable at match time with either jumpers, toggle switches, or (my favorite) a hex-wheel encoder. Its a nice system... all you have to do is sit down with your strategist/driver and work out strategies that you like for autonomous, write the scripts, and give them a 'playbook'.

Well, i'm getting off track. For you to schedule things to happen, you can do something as simple as this if you want, now this is dirty but I think gets you where you want, again, if I were you I'd go ahead and just write the script executor, but, here we go:

//variable
unsigned int time = 0;

//inside User_Autonomous_Code

time++;
if (time < 10)
{
  //do things that happen until 10 time counts (or until .254 seconds if using frc controller)
  pwm01 = pwm02 = 200; //drive forwards-ish
}
else if (time < 100)
{
   //do things that happen until 100 time counts (or 2.54seconds)
   pwm01 = 100;
   pwm02 = 200;  //spin for a while
}
//etc.

That should do what you want I think... and yes, it is very very true that an encoded tire is always better than a dead-reckoned one.

-q

[mluckham]

NOPs are often used in assembly language programming where a very (very! a microsecond or two!) short, predictable delay which is some multiple of the CPU clock instruction time is needed. I've used these when talking to peripheral devices at bus speeds ... there isn't enough time to configure or even check a timer value, just enough to execute a few NOPs. Usually interrupts are OFF as well - to avoid unexpected extra time.

I don't think that will be useful here ...

a) in a for-loop with an index that counts up to some large number, the NOP makes a poor-man's timer. But if you stay in the loop for a too long (> 26 msec) without a PutData(), there is the risk of the Code Error light coming on and your program being terminated, as whitetiger0990 said.

b) don't you need to check the autonomous bit in the loop too?

c) the IFIRobotics FAQ on Victor Speed Controllers states that the Victor updates at about 120 Hz, so the fastest it will accept updates is every 8 msec. This seems to be your limiting factor.

d) last year we had a too-small motor on our arm prototype, and yes it had zero holding power and we had to keep kicking it to resist gravity pulling the arm down. After a few seconds of this, the motor began to smoke! The moral of the story: use a different motor, with gearing high enough to provide the "holding power" that you need.

I'm guessing your desire for a quick-and-dirty solution to timers relates to the amount of code that would have to be found and commented in or out as you were making your between-match fixups. You might also want to consider using EasyC and WPILIB - MUCH easier to use timers/etc ...

mike


PS - another use of NOPs (back in the dim, dark past) was to leave extra space in the executable part of the program so as to PATCH in extra code manually through front-panel switches. I guess that's not the case here unless you are writing self-modifying code!