View Single Post
  #28   Spotlight this post!  
Unread 24-12-2006, 17:14
Mark McLeod's Avatar
Mark McLeod Mark McLeod is offline
Just Itinerant
AKA: Hey dad...Father...MARK
FRC #0358 (Robotic Eagles)
Team Role: Engineer
 
Join Date: Mar 2003
Rookie Year: 2002
Location: Hauppauge, Long Island, NY
Posts: 8,906
Mark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond repute
Re: Printf has just entirely failed to do anything

We're pretty much limited to updating the pwm outputs at the slow loop speed whether regular driver mode or autonomous. While there is the potential to update a few special pwm outputs at a faster rate, the devices attached to the pwm outputs, such as Victors, aren't designed to receive the updates very much faster than the current slow loop speed.

The Master processor enforces the playing field control overrides and filters our OI inputs as well as our pwm outputs, a la
OI -> Master Proc. -> User Proc. -> Master Proc -> PWM outputs
When it has us disabled the Master "neutalizes" our pwm outputs, when it has us in autonomous mode the Master "neutralizes" the OI inputs it passes to us.

I conjecture that calling getdata() extra times will just return a copy of the last packet the Master prepared and I don't believe the Master does anything with extraneous putdata's until after NEW_SPI_DATA is reset to 1. You'd have to test that theory to be sure. In any case the response of the downstream systems such as the Victors, motors, and drivetrain will lag and swallow the milliseconds we might save.

To work properly PID feedback control depends on regular feedback not just speed and to make correct decisions needs previous decisions to be acted upon. It'll quickly lose track of things if the outside world is ignoring 99% of it's requests for motor changes and only acting on a random 1%.

Typically, use the fast loop of Process_Data_From_Local_IO to sample sensors, especially polled sensors, and collect data for use in making decisions later in the slow loop.
Your decision logic based on OI inputs or resulting in pwm outputs don't need to be made any faster than we can tell the Master processor via getdata/putdata.

The default code slow loop in main() is just used to kickoff the separate autonomous slow loop. The way the autonomous slow loop is coded doesn't allow anything else, including the main.c loop, to run again until the Master signals the end of autonomous mode. We eliminate the separate autonomous loop and only allow the main loop.

Quote:
Originally Posted by Kevin Sevcik
...Well I just think the most likely culprit is all of these serial writes stacking up and possibly overflowing queues and generally making a mess of things.
That's a valid theory and can easily be tested, but that would also mean printfs would not work anywhere in the fast loop for the same reasons. We still complain when we see people printf-ing from interrupts, but they get printouts.
__________________
"Rationality is our distinguishing characteristic - it's what sets us apart from the beasts." - Aristotle

Last edited by Mark McLeod : 24-12-2006 at 17:17.