Go to Post If a team wants to cheat then it does nothing but give them a bad cloud hanging over their own heads. - Jon K. [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #16   Spotlight this post!  
Unread 23-12-2006, 02:15
esquared's Avatar
esquared esquared is offline
Keeps saying 3-2-1-Rush...
AKA: Angry Eric
no team (Volunteer!)
Team Role: Mascot
 
Join Date: Jan 2006
Rookie Year: 2005
Location: Boston, MA
Posts: 192
esquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond reputeesquared has a reputation beyond repute
Re: Printf has just entirely failed to do anything

Quote:
Originally Posted by JBotAlan View Post
...
EDIT: I was under the impression that Camera_Handler() in camera.c was supposed to be calling Initialize_Camera(), and it is as far as I know. I can call it manually, but depending on the flags set in camera.c, it does get called if camera comms aren't working. Correct me if I'm wrong...
I missed that as well in camera.c so good call.

Aside from your efforts to start from the default code, I can send you a basic environment that has a working camera without too much of our robot-specific code in it just so you can verify its not the source you're building from.

Another possibility-what version of the IFI loader are you using? If you use the old version with code sizes> 32k (or whatever the max was for 2005's RC), you can get wicked crazy problems. That might explain why things stopped working as you added more functions/files.

-Eric
  #17   Spotlight this post!  
Unread 23-12-2006, 08:27
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

Good news & bad news...

I dropped your code as-is into one of our controllers and a printf I added to user_routines.c worked fine.
Master code v12
IFI_Loader v 1.1
I ran without the camera as a first test then connected the camera.

Which printf in what routine in particular were you having trouble with?

P.S. In the version you posted none of the camera code is ever called from anywhere, so there won't be any "uncalled for" printf's from any of that code.
I added a call to CAL_Update(); in Process_Data_From_Master_uP and uncommented the #include "camera_abstraction.h"
and I'm seeing the printf's from the camera code.
__________________
"Rationality is our distinguishing characteristic - it's what sets us apart from the beasts." - Aristotle

Last edited by Mark McLeod : 23-12-2006 at 09:24. Reason: Added version #'s
  #18   Spotlight this post!  
Unread 23-12-2006, 12:01
JBotAlan's Avatar
JBotAlan JBotAlan is offline
Forever chasing the 'bot around
AKA: Jacob Rau
FRC #5263
Team Role: Mentor
 
Join Date: Sep 2004
Rookie Year: 2004
Location: Riverview, MI
Posts: 723
JBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond repute
Send a message via AIM to JBotAlan Send a message via Yahoo to JBotAlan
Re: Printf has just entirely failed to do anything

I'm using IFI Loader 1.1.0. I see no printfs anywhere, at all when I put this code into my rc. I've verified it's not my terminal program, serial port, or the rc itself as I loaded old code and it showed all the printfs fine. I can't test anything until somewhere around the 4th because I can't get into the shop until then. I had added printfs directly into main() because nothing else was working, and even that wasn't working. I suppose I should update the master code because I am pretty sure nobody bothered to do so last year--I think we're running v11 still.

Thanks again
JBot

EDIT: Is that what the new master code was released for--a fix in printf? I knew there was new code out there but I don't remember ever updating. I even have the binary on my machine right now, I just need to upload it.
__________________
Aren't signatures a bit outdated?
  #19   Spotlight this post!  
Unread 23-12-2006, 13:39
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

Quote:
Originally Posted by JBotAlan View Post
EDIT: Is that what the new master code was released for--a fix in printf? I knew there was new code out there but I don't remember ever updating. I even have the binary on my machine right now, I just need to upload it.
No such luck.
The master code revisions usually are just to match changes in the field control software. v11 was released to fix a random twitch in the pwm outputs for Victors, but nothing that affects the behavior of our User code. The Master version won't affect your printf.
I dumped v11 into my test controller just to eliminate that as a potential cause, and your code still works fine.

Your code is small enough to fit and run on the older PIC-based controllers, so the IFI_Loader version isn't a likely issue. But if you get a Vex kit as a present you'll be able to test your code at home!

I'd start with a close look at the simple solutions.

When you get back to the robot after the holidays double check that you're downloading the .hex file you think you are. I notice you're putting the .hex file in a different directory than the source code (C:\old_'07_Code), so check the date on the file IFI_Loader is pointing to and verify it's new.

Double check your C18 version (2.4). I'm sure you have the current version, but verify there aren't older versions or the Vex version conflicting.

What's the history of the PC you're using? Has it been used for several years? Has MPLAB/C18/etc. been reinstalled around the time your troubles began?
__________________
"Rationality is our distinguishing characteristic - it's what sets us apart from the beasts." - Aristotle

Last edited by Mark McLeod : 23-12-2006 at 18:32.
  #20   Spotlight this post!  
Unread 23-12-2006, 15:48
JBotAlan's Avatar
JBotAlan JBotAlan is offline
Forever chasing the 'bot around
AKA: Jacob Rau
FRC #5263
Team Role: Mentor
 
Join Date: Sep 2004
Rookie Year: 2004
Location: Riverview, MI
Posts: 723
JBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond repute
Send a message via AIM to JBotAlan Send a message via Yahoo to JBotAlan
Re: Printf has just entirely failed to do anything

Quote:
Originally Posted by Mark McLeod View Post
No such luck.
The master code revisions usually are just to match changes in the field control software. v11 did fixed a random twitch in the pwm outputs for Victors, but nothing that affects the behavior of our User code. The Master version won't affect your printf.
I dumped v11 into my test controller just to eliminate that as a potential cause, and your code still works fine.
Ugh. Here we go.

Quote:
Originally Posted by Mark McLeod View Post
Your code is small enough to fit and run on the older PIC-based controllers, so the IFI_Loader version isn't a likely issue. But if you get a Vex kit as a present you'll be able to test your code at home!
Not likely, but it would be nice. I think I'm going to ask the team leader if I can bring home the old controller, OI, some power source, and all the necessary testing hardware so I can get something done.
Quote:
Originally Posted by Mark McLeod View Post
I'd start with a close look at the simple solutions.

When you get back to the robot after the holidays double check that you're downloading the .hex file you think you are. I notice you're putting the .hex file in a different directory than the source code (C:\old_'07_Code), so check the date on the file IFI_Loader is pointing to and verify it's new.
<scratches head> I looked at the project options again after you mentioned this, but I see the output directory is c:\old_'07_code, right where the source is. I verified that MPLAB is opening the right files. I have deleted the .hex file, recompiled, and yes, it shows up right where I expected it would, and I verified it was this .hex I downloaded.

Quote:
Originally Posted by Mark McLeod View Post
Double check your C18 version (2.4). I'm sure you have the current version, but verify there aren't older versions or the Vex version conflicting.
What's the history of the PC you're using? Has it been used for several years? Has MPLAB/C18/etc. been reinstalled around the time your troubles began?
I installed this from the '06 disc in the KOP which only had 2.4 on it. I only bought this PC in July or August of this year, so it doesn't have an old version conflict. Also, I have never done Vex ever, so that's not a possibility. I never reinstalled MPLAB, but I'm thinking that's my next step.

It might work right now. I have no idea. I'll have to test it when we get back.

JBot
__________________
Aren't signatures a bit outdated?
  #21   Spotlight this post!  
Unread 23-12-2006, 16:17
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

Quote:
Originally Posted by JBotAlan View Post
<scratches head> I looked at the project options again after you mentioned this, but I see the output directory is c:\old_'07_code, right where the source is.
I understand how you setup your project now. I unzipped your files to a folder on my computer that wasn't c:\old_'07_code. Removing the hardcoded paths for Output directory, Intermediates Directory, and Linker-Script Path let them default to whatever the current directory happens to be.

The MPLAB version won't matter much either. It's just an editing/organizing tool.

Don't sweat it until you're in a position to test again. It'll only drive you nuts. Right now what you've got looks good to me. I'll post the working hex file I compiled and you can use it to eliminate your PC/MPLAB/C18 as any kind of a suspect.

Here's the hex file and the camera initialization output printfs I'm seeing. (ignore the "MLM" that's my test printf from user_routines.c)
__________________
"Rationality is our distinguishing characteristic - it's what sets us apart from the beasts." - Aristotle

Last edited by Mark McLeod : 27-02-2007 at 12:57.
  #22   Spotlight this post!  
Unread 23-12-2006, 19:45
JBotAlan's Avatar
JBotAlan JBotAlan is offline
Forever chasing the 'bot around
AKA: Jacob Rau
FRC #5263
Team Role: Mentor
 
Join Date: Sep 2004
Rookie Year: 2004
Location: Riverview, MI
Posts: 723
JBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond repute
Send a message via AIM to JBotAlan Send a message via Yahoo to JBotAlan
Re: Printf has just entirely failed to do anything

Alright, thanks. Got the file, will try it when we get back.

Some of the characters in the output are interesting, but I won't worry about it right now.

Thanks

You deserve a candy bar...

Here you go:
http://www.nadf.com/images/3musketeers_c.gif

hehe...I'm going nuts already. Think of what the season is going to do...

JBot
__________________
Aren't signatures a bit outdated?
  #23   Spotlight this post!  
Unread 23-12-2006, 21:17
Kevin Sevcik's Avatar
Kevin Sevcik Kevin Sevcik is offline
(Insert witty comment here)
FRC #0057 (The Leopards)
Team Role: Mentor
 
Join Date: Jun 2001
Rookie Year: 1998
Location: Houston, Texas
Posts: 3,745
Kevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond repute
Send a message via AIM to Kevin Sevcik Send a message via Yahoo to Kevin Sevcik
Re: Printf has just entirely failed to do anything

JBotAlan,

I think your problem is both obvious and simple to fix, luckily. Rearranging the Camera_Handler function etc, had nothing to do with it. Had you left the original code intact, you still would have broken the program by moving Camera_Handler() (or CAL_Update() in your program) from user_routines.c to Process_Data_From_Local_IO(). Move Camera_Handler() back where it belongs and everything will work wonderfully again.

Here's my reasoning. Process_Data_From_Local_IO(), as you know, runs stupidly fast, as it runs every loop in the user PIC. As opposed to every 26.2ms for Process_Data_From_Master_uP(). Camera_Handler() is a very complicated little function, and does tons of fun stuff like disabling serial interrupts briefly and using the inherent timing of the slow loop to get the timing of its initialization correct. Basically, with Camera_Handler() in your Process_Data_From_Local_IO(), things are happening waaay too fast and piling up and generally causing the horrible broken execution and code error lights that you're seeing.

To put it even more briefly, in the camera_readme.txt, Kevin Watson says you should call Camera_Handler() from Process_Data_From_Master_uP(). You really ought to listen to him unless you've initmately acquainted yourself with the operation of said function.
__________________
The difficult we do today; the impossible we do tomorrow. Miracles by appointment only.

Lone Star Regional Troubleshooter
  #24   Spotlight this post!  
Unread 24-12-2006, 08:07
JBotAlan's Avatar
JBotAlan JBotAlan is offline
Forever chasing the 'bot around
AKA: Jacob Rau
FRC #5263
Team Role: Mentor
 
Join Date: Sep 2004
Rookie Year: 2004
Location: Riverview, MI
Posts: 723
JBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond repute
Send a message via AIM to JBotAlan Send a message via Yahoo to JBotAlan
Re: Printf has just entirely failed to do anything

Oh.

Maybe I should've read that readme.

I figured that it shouldn't be in the slow loop because by default that doesn't even execute during auton, where we need the camera the most. I will definitely read through that function and the camera readme and see if moving the function call back to process_data_from_up helps. That would make sense if it was disabling and re-enabling serial interrupts very quickly...

I never would've caught that.

Thanks
JBot

EDIT: Just glancing through camera.c, I don't happen to see where serial interrupts are disabled/enabled, but I haven't looked at all of the function calls either. I do notice a loop_count variable; that alone warrants moving it back into the slow loop. Like I said, I need it to execute in auton. I may well modify this function so that it can safely execute in the fast loop. I don't know; I don't have time today to deal with this but thanks for the help.
__________________
Aren't signatures a bit outdated?

Last edited by JBotAlan : 24-12-2006 at 08:12.
  #25   Spotlight this post!  
Unread 24-12-2006, 08:12
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

Kevin has a good point.
Although calling CAL_Update() from the fast loop (via Process_Data_From_Local_IO) would only prevent the camera from working properly.
It wouldn't lockup the controller or disable printfs. The camera code doesn't take very long to execute.

P.S.
Your autonomous code should also execute in a slow loop. It doesn't help to execute faster than you can deliver instructions to the pwms. If you check the IFI default code you'll see the autonomous section in user_routines_fast.c is really a slow loop by virtue of the line:
Code:
    if (statusflag.NEW_SPI_DATA)      /* 26.2ms loop area */
You just need to add your camera calls within that slow loop.
I'd advise you to pull all your autonomous code out of the user_routines_fast.c file anyway. The name of that file only confuses the issue and your freshmen programmers, since it's not true for the autonomous code.
__________________
"Rationality is our distinguishing characteristic - it's what sets us apart from the beasts." - Aristotle

Last edited by Mark McLeod : 24-12-2006 at 08:26.
  #26   Spotlight this post!  
Unread 24-12-2006, 11:27
JBotAlan's Avatar
JBotAlan JBotAlan is offline
Forever chasing the 'bot around
AKA: Jacob Rau
FRC #5263
Team Role: Mentor
 
Join Date: Sep 2004
Rookie Year: 2004
Location: Riverview, MI
Posts: 723
JBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond repute
Send a message via AIM to JBotAlan Send a message via Yahoo to JBotAlan
Re: Printf has just entirely failed to do anything

Quote:
Originally Posted by Mark McLeod View Post
Your autonomous code should also execute in a slow loop. It doesn't help to execute faster than you can deliver instructions to the pwms.
At first, I thought that auton WAS a fast loop, but I looked at main() and now see otherwise. This brings up a few questions in my mind. Why is auton a slow loop? I had heard (but not tested) that the values we get from the OI are invalid during auton and to disregard them entirely. Is it that the master processor will only let me getdata and putdata every 26.2ms? Do PWMs update faster if I getdata and putdata every loop instead of only when NEW_SPI_DATA is 1? What will getdata do if there is no new data to get? Also, suppose I have a PID loop. It needs to execute fast (or so the whitepaper says). So I put it in local IO. It changes PWM values in between 26.2ms loops. Are the victors actually getting the updated values in between loops, or are they updated every 26.2ms? And are my sensor reads actually updating in between 26.2ms loops, or are they the same every loop? Sorry about all the questions...I don't really understand the architecture of the rc.

Quote:
Originally Posted by Mark McLeod View Post
If you check the IFI default code you'll see the autonomous section in user_routines_fast.c is really a slow loop by virtue of the line:
Code:
    if (statusflag.NEW_SPI_DATA)      /* 26.2ms loop area */
You just need to add your camera calls within that slow loop.
I'd advise you to pull all your autonomous code out of the user_routines_fast.c file anyway. The name of that file only confuses the issue and your freshmen programmers, since it's not true for the autonomous code.
Wow, my basic assumption (based on the comments in the code...) was wrong.
Quote:
Originally Posted by user_routines_fast.c
* FUNCTION NAME: User_Autonomous_Code
* PURPOSE: Execute user's code during autonomous robot operation.
* You should modify this routine by adding code which you wish to run in
* autonomous mode. It will be executed every program loop, and not
* wait for or use any data from the Operator Interface.
So that comment is downright wrong? Sure looks like it by the looks of main()...I might shoot off an email to IFI just to let them know.

JBot
__________________
Aren't signatures a bit outdated?

Last edited by JBotAlan : 24-12-2006 at 11:32.
  #27   Spotlight this post!  
Unread 24-12-2006, 14:38
Kevin Sevcik's Avatar
Kevin Sevcik Kevin Sevcik is offline
(Insert witty comment here)
FRC #0057 (The Leopards)
Team Role: Mentor
 
Join Date: Jun 2001
Rookie Year: 1998
Location: Houston, Texas
Posts: 3,745
Kevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond repute
Send a message via AIM to Kevin Sevcik Send a message via Yahoo to Kevin Sevcik
Re: Printf has just entirely failed to do anything

Quote:
Originally Posted by Mark McLeod View Post
Kevin has a good point.
Although calling CAL_Update() from the fast loop (via Process_Data_From_Local_IO) would only prevent the camera from working properly.
It wouldn't lockup the controller or disable printfs. The camera code doesn't take very long to execute.

P.S.
Your autonomous code should also execute in a slow loop. It doesn't help to execute faster than you can deliver instructions to the pwms. If you check the IFI default code you'll see the autonomous section in user_routines_fast.c is really a slow loop by virtue of the line:
Code:
    if (statusflag.NEW_SPI_DATA)      /* 26.2ms loop area */
You just need to add your camera calls within that slow loop.
I'd advise you to pull all your autonomous code out of the user_routines_fast.c file anyway. The name of that file only confuses the issue and your freshmen programmers, since it's not true for the autonomous code.
Mark,

You're right about the camera code executing quickly, but I think that might be where the problem lies. The initialization process fires off atleast a few packets to the camera. If Debug is on, it will also fire several long strings to the terminal. If all of this is in the fast loop... 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.
__________________
The difficult we do today; the impossible we do tomorrow. Miracles by appointment only.

Lone Star Regional Troubleshooter
  #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.
  #29   Spotlight this post!  
Unread 24-12-2006, 18:29
JBotAlan's Avatar
JBotAlan JBotAlan is offline
Forever chasing the 'bot around
AKA: Jacob Rau
FRC #5263
Team Role: Mentor
 
Join Date: Sep 2004
Rookie Year: 2004
Location: Riverview, MI
Posts: 723
JBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond reputeJBotAlan has a reputation beyond repute
Send a message via AIM to JBotAlan Send a message via Yahoo to JBotAlan
Re: Printf has just entirely failed to do anything

Quote:
Originally Posted by Mark McLeod View Post
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.
Those "special outputs" are 13-16, right? The ones our code has to generate the PWM signal for?

Quote:
Originally Posted by Mark McLeod View Post
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.
OK. That makes sense, as setting an output to max for only 26.2ms outputs a pulse that barely tensions the chain, let alone moving the drivetrain. I just thought that polling the gyro really fast was a good idea, but I didn't realize how short 26.2ms is.

Quote:
Originally Posted by Mark McLeod View Post
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%.
I knew this would be damaging to the algorithm if the victors weren't getting the updated signal, but I didn't think that they were only updated every slow loop. Now that I know this, I have a little more info on why our PID loop was so broken last year (it oscillated beyond control in about 3 seconds. I know how to tweak it now; I didn't then).

Quote:
Originally Posted by Mark McLeod View Post
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.
So you mean poll the sensors if I want an average over that 26.2ms instead of an instantaneous reading during the slow loop?

Quote:
Originally Posted by Mark McLeod View Post
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.
Oh, I forgot it was a separate loop. I ripped that out of last year's code, but in hindsight I could've left it just like it was. About the part that's bolded above: what do you mean? Do you mean that your team has ripped out the separate loop and let main() loop like normal?

Thanks
JBot
__________________
Aren't signatures a bit outdated?
  #30   Spotlight this post!  
Unread 24-12-2006, 19:23
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

Quote:
Originally Posted by JBotAlan View Post
Those "special outputs" are 13-16, right? The ones our code has to generate the PWM signal for?
Yep. Be wary and stay away from them though. They don't work correctly as they are used in the default code. There is some extra work required for those. If you're interested a CD search will point you in the right direction.

Quote:
Originally Posted by JBotAlan View Post
I just thought that polling the gyro really fast was a good idea, but I didn't realize how short 26.2ms is.
...
So you mean poll the sensors if I want an average over that 26.2ms instead of an instantaneous reading during the slow loop?
Using the fast loop to poll the gyro is a really good idea, because you have to average the data to get a meaningful result.
Polling a pot on an arm usually isn't necessary, because it returns absolute position anyway.

Quote:
Originally Posted by JBotAlan View Post
Oh, I forgot it was a separate loop. I ripped that out of last year's code, but in hindsight I could've left it just like it was. About the part that's bolded above: what do you mean? Do you mean that your team has ripped out the separate loop and let main() loop like normal?
Sounds like we had similar solutions. We didn't like a software design that took control away from the main loop.
One of the advantages of ripping the loop out of User_Autonomous_Code is that Process_Data_From_Master_uP and Process_Data_From_Local_IO continue to get called normally from main() without any extra work or duplication of effort. We add a few other improvements to main() such as initial delays to allow the systems and sensors to stabilize on powerup and automatically resetting autonomous on disable. It's nice that these changes apply to every mode and don't have to be implemented again for that autonomous loop.
__________________
"Rationality is our distinguishing characteristic - it's what sets us apart from the beasts." - Aristotle
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Compiling Failed Teh Mike Programming 7 09-02-2005 13:27
pic: Failed attempt at simulation CD47-Bot Extra Discussion 5 17-06-2004 11:03
printf isn't printf-ing. Help! Meandmyself Programming 14 15-02-2004 16:27
And now for something entirely different..... archiver 1999 1 23-06-2002 22:46


All times are GMT -5. The time now is 02:06.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi