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

[3dude_2231]

if I have no other option,
is it 'OK' or 'healthy' to make a large loop of NOPs
inside the autonomous loop?

[jgannon]

Can you explain what goal you're trying to achieve by doing that? That way, we can help you figure out if you've chosen the best method.

[3dude_2231]

hmm... as once said,
it's fun to solve hardware problems in programming,
I'm trying to precisely control a problematic motor, (taming the lion =] )
it has very little grip, and I'm afraid that by counting-the-cycles of a full autonomous loop,
I wouldn't be able to get it to the right position.

I was thinking about getting it to work, and by the next autonomous loop(s)
get it to stay in that position X operations (using NOPs).

now,
A. will that hurt the PWM operations? (but I guess not, as it supposed to be TIMER2(?) operated)

B. can it be bad in other ways?

Thanks,
Ran.

//just making emergency plans

[whitetiger0990]

It's probably a bad idea. There are parts of the code which need to be run, and they don't like it if you hold onto the execution for too long.

It'd probably give you a Code Error on the OI. (same thing happens if you accidentally have an infinite loop)

[bear24rw]

If your trying to make a delay with nops, then you have to make sure you have the get_data and put_data functions in there.. actually you dont really even need nops..

void delay(int time)
{
  for (int i=0; i<time; i++)
  {
    GetData(); // dont remember the parameters
    PutData(); // dont remember the parameters
  }
}

That is completely untested but it should delay...

[whitetiger0990]

bear24rw:
If you do that, wouldn't you have the same precision as just counting the loop already given to you?

[bear24rw]

precision of delay? yeah, but you could set up a timer and use that to do accurate delays

[Qbranch]

I do not grasp how putting a delay in an Autonomous program will cause a motor to stop 'skipping'.

Is this an airplane servo?

Or by some stroke of... well... oddness... do you have a stepper motor your trying to run for an offseason project?

I'm lost...

-q

[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.