Go to Post We were also at 9,999 [characters] for Chairmans...Mom always said I was an under-achiever. - Chris Fultz [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 Rating: Thread Rating: 4 votes, 4.75 average. Display Modes
  #1   Spotlight this post!  
Unread 20-03-2007, 23:55
Eldarion's Avatar
Eldarion Eldarion is offline
Electrical Engineer / Computer Geek
AKA: Eldarion Telcontar
no team (Teamless Orphan)
Team Role: Alumni
 
Join Date: Nov 2005
Rookie Year: 2005
Location: Númenor
Posts: 558
Eldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond repute
Send a message via AIM to Eldarion Send a message via Yahoo to Eldarion
Re: Programming tricks (and former trade secrets)

Quote:
Originally Posted by Matt Krass View Post
I don't mean to be rude, but I took a look at the code you provide and I must say, it's terribly disorganized and disheveled. I find it hard to navigate and poorly commented, it took me and a friend several minutes to figure out what is apparently a timeout reset of the cameras. Your project looks promising, but I think you should polish it up quite a bit more before charging such a hefty sum for it. And I'm not certain but is that full blown development board depicted in your picture actually entirely necessary? Seems like you could design your own hardware to house the device and save some money in removal of unnecessary parts.

Again I don't mean to be rude, and if I'd made a mistake in my conclusions, please forgive me, your site is somewhat sparse on details, I'll happily stand corrected if I am wrong.
Very good points. I did just throw together the example code for a temporary example, as I do not have an RC with me right now and so I could not clean up and test the code. I will pull it until I can clean it up and test it.

Would someone be able to direct me to a place that can handle the manufacturing and assembly of circuit boards that can handle BGA devices in small runs? At this point, I have almost zero capital, so I cannot invest in a run of 2000 boards and hope to sell them later.

I kind of rushed this product out here to "test the waters" and see if there would be any interest in a system like this. The actual system itself is very mature and stable, I am having some difficulty with the peripheral stuff, like sample IFI drivers. If you click on the "Add to Cart" link, you will see that I am not actually offering this for sale to the general public yet. (I should probably make that more clear.) What I would like is for one or two teams to be willing to test this, make sure that the manual is clear and such, that I am not overpromising, etc. before making this generally available and investing in a new board design.

You were not rude; this is my first time attempting to bring something to market and as such it is a learning experience for me. I appreciate your criticism and feel free to poke as many holes in my logic above as necessary.

Maybe we could discuss this further via the PM system so as not to tie up this thread?

Thanks again.
__________________
CMUCam not working? Tracks sporadically? Try this instead: http://www.falconir.com!
PM me for more information if you are interested (it's open source!).

Want the FIRST Email blasts? See here: http://www.chiefdelphi.com/forums/sh...ad.php?t=50809

"The harder the conflict, the more glorious the triumph. What we obtain too cheaply, we esteem too lightly; it is dearness only that gives everything its value."
-- Thomas Paine

If it's falling apart it's a mechanical problem. If it's spewing smoke it's a electrical problem.
If it's rampaging around destroying things it's a programming problem.

"All technology is run on 'Magic Smoke' contained within the device. As everyone knows, whenever the magic smoke is released, the device ceases to function."
-- Anonymous

I currently speak: English, some German, Verilog, x86 and 8051 Assembler, C, C++, VB, VB.NET, ASP, PHP, HTML, UNIX and SQL
  #2   Spotlight this post!  
Unread 20-03-2007, 23:13
Mike's Avatar
Mike Mike is offline
has common ground with Matt Krass
AKA: Mike Sorrenti
FRC #0237 (Sie-H2O-Bots (See-Hoe-Bots) [T.R.I.B.E.])
Team Role: Programmer
 
Join Date: Dec 2004
Rookie Year: 2004
Location: Watertown, CT
Posts: 1,003
Mike has a reputation beyond reputeMike has a reputation beyond reputeMike has a reputation beyond reputeMike has a reputation beyond reputeMike has a reputation beyond reputeMike has a reputation beyond reputeMike has a reputation beyond reputeMike has a reputation beyond reputeMike has a reputation beyond reputeMike has a reputation beyond reputeMike has a reputation beyond repute
Re: Programming tricks (and former trade secrets)

Quote:
Originally Posted by Eldarion View Post
I created this: http://www.falconir.com/products.php

After calibrating once at our home practice field, it was literally "set it and forget it". We did not have to recalibrate once at either of the two regionals! It even handled a dim target light on the practice field.

Then we changed our arms out and autonomous broke permanently
Looks cool, but have you checked out your main open-source competition: the avrcam
__________________
http://www.mikesorrenti.com/
  #3   Spotlight this post!  
Unread 20-03-2007, 23:20
Eldarion's Avatar
Eldarion Eldarion is offline
Electrical Engineer / Computer Geek
AKA: Eldarion Telcontar
no team (Teamless Orphan)
Team Role: Alumni
 
Join Date: Nov 2005
Rookie Year: 2005
Location: Númenor
Posts: 558
Eldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond reputeEldarion has a reputation beyond repute
Send a message via AIM to Eldarion Send a message via Yahoo to Eldarion
Re: Programming tricks (and former trade secrets)

Quote:
Originally Posted by Mike View Post
Looks cool, but have you checked out your main open-source competition: the avrcam
That's interesting, but I think it will be hard to beat the raw processing power of a dedicated FPGA. The FPGA allows me to use 320x240 resolution, over 6 times the resolution of the CMUCam or the avrcam. It does sacrifice speed a little bit, runnig at a little over 6 FPS, but I have found that to be more than adequate. The increased resolution allowed me to stably track the lights from the home zone, (and far beyond it, actually ).

It is hard to go up against an open-source project, though...
__________________
CMUCam not working? Tracks sporadically? Try this instead: http://www.falconir.com!
PM me for more information if you are interested (it's open source!).

Want the FIRST Email blasts? See here: http://www.chiefdelphi.com/forums/sh...ad.php?t=50809

"The harder the conflict, the more glorious the triumph. What we obtain too cheaply, we esteem too lightly; it is dearness only that gives everything its value."
-- Thomas Paine

If it's falling apart it's a mechanical problem. If it's spewing smoke it's a electrical problem.
If it's rampaging around destroying things it's a programming problem.

"All technology is run on 'Magic Smoke' contained within the device. As everyone knows, whenever the magic smoke is released, the device ceases to function."
-- Anonymous

I currently speak: English, some German, Verilog, x86 and 8051 Assembler, C, C++, VB, VB.NET, ASP, PHP, HTML, UNIX and SQL
  #4   Spotlight this post!  
Unread 23-02-2007, 20:43
JimGRobot JimGRobot is offline
Registered User
AKA: Jim
FRC #1388 (Eagle Robotics)
Team Role: Mentor
 
Join Date: Nov 2006
Rookie Year: 2005
Location: Arroyo Grande, CA
Posts: 29
JimGRobot is just really niceJimGRobot is just really niceJimGRobot is just really niceJimGRobot is just really nice
Re: Programming tricks (and former trade secrets)

Great thread, there are many good ideas out there.

We talked about the remote PROG button ourselves, but never implemented it.

One thing we did for the drivers was create an "Auto Trim" button for the joysticks. You use the regular trim adjust to get them close, then push the button. This saves the current joystick positions and subtracts those values from all future readings. This is built into a joystick "class" that is part of a code library that will be released to the world this spring.

We have an automatic scoring button, as others have mentioned, and separate buttons for all of the arm preset positions. We used a potentiometer for arm position feedback, and it works well.

One other cool thing is a micro-switch on the tube gripper to automatically close the jaws with a tube is present. This makes tube pickup very quick and easy.

We wired a bunch of momentary switches across a string of resistors connected to a single joystick input on the OI, instead of using 10 digital input bits. I will be making some PC boards over summer so others can do this very easily. The code does a little math to convert the input value into a switch number; this is built into another library class.

I guess that's all for now...
Jim
  #5   Spotlight this post!  
Unread 23-02-2007, 22:02
dpick1055's Avatar
dpick1055 dpick1055 is offline
David Pick
FRC #1739 (Chicago Knights)
Team Role: Alumni
 
Join Date: May 2005
Rookie Year: 2004
Location: Chicago
Posts: 75
dpick1055 is on a distinguished road
Send a message via AIM to dpick1055
Re: Programming tricks (and former trade secrets)

Do you think you could talk more about the auto-trim button. We're having a lot of trouble keeping our joysticks in the right trim position. Or is it a closely guarded secret
__________________
Always remember to take your powered wheels off the ground when first testing code. Otherwise you'll end up with holes in the wall like us
  #6   Spotlight this post!  
Unread 24-02-2007, 00:56
JimGRobot JimGRobot is offline
Registered User
AKA: Jim
FRC #1388 (Eagle Robotics)
Team Role: Mentor
 
Join Date: Nov 2006
Rookie Year: 2005
Location: Arroyo Grande, CA
Posts: 29
JimGRobot is just really niceJimGRobot is just really niceJimGRobot is just really niceJimGRobot is just really nice
Re: Programming tricks (and former trade secrets)

Thanks for the note, no, this one is a loosely guarded secret...

We do some strange things with the scaling of our joysticks, but the principle is the same regardless of how you do it.

Start by creating a static global variable for each joystick axis, like:

char p1_x_offset = 0;
char p1_y_offset = 0;

Any place that you normally use the raw joystick value, use the joystick value minus the offset value, like:

pwm01 = (p1_y - p1_y_offset); //used to be p1_y only

Set the offset value to the joystick value when a button is pressed:

if ( button_pressed )
p1_y_offset = p1_y;

I think you get the idea. You are better off working with integer variables to avoid overflows, and handle limit checking, then converting back to char for writing to the pwm output.

Another thing to consider is adding a button to clear the offset. If you use this method to remove a large error, remember that the offset correction will not be present when the robot is reset, and the thing might take off.

In our implementation we limit the offset value to about 6 counts...

Let me know if you have other questions.

Jim
  #7   Spotlight this post!  
Unread 24-02-2007, 01:18
dpick1055's Avatar
dpick1055 dpick1055 is offline
David Pick
FRC #1739 (Chicago Knights)
Team Role: Alumni
 
Join Date: May 2005
Rookie Year: 2004
Location: Chicago
Posts: 75
dpick1055 is on a distinguished road
Send a message via AIM to dpick1055
Re: Programming tricks (and former trade secrets)

I'm still having a little trouble understanding this. Say when your joystick is centered it gives a value of 130. If you set that to your offset and then move your joystick to 200. Wouldn't that only send you forward at a speed of 70? And then when your joystick is somewhere near 127 you would be going in reverse?

Thanks
-David
__________________
Always remember to take your powered wheels off the ground when first testing code. Otherwise you'll end up with holes in the wall like us

Last edited by dpick1055 : 24-02-2007 at 01:22.
  #8   Spotlight this post!  
Unread 24-02-2007, 01:31
JimGRobot JimGRobot is offline
Registered User
AKA: Jim
FRC #1388 (Eagle Robotics)
Team Role: Mentor
 
Join Date: Nov 2006
Rookie Year: 2005
Location: Arroyo Grande, CA
Posts: 29
JimGRobot is just really niceJimGRobot is just really niceJimGRobot is just really niceJimGRobot is just really nice
Re: Programming tricks (and former trade secrets)

Sorry for the confusion, what I posted earlier only works if you scale your joysticks around zero by subtracting 127 from the joystick reading, and adding 127 back in before writing to the pwm.

So, here is a tweak to my earlier post. Instead of setting the offset to the joystick value, set it to the joystick value minus 127:

p1_y_offset = p1_y - 127;

If the joystick value is 130, and you press the auto trim button, the offset will be 3. When this value is subtracted from 130, you get the null value of 127. When the joystick value is 200, you get 197, and 100 you get 97.

If the offset value is too big, it will limit the range of the joystick value. Suppose you auto trim when the joystick value is 77, the offset is -50. When the raw value of the joystick is 254, the corrected value would only be 204, and if the raw value was less than 50, the corrected value would already be limited at zero.

Play around with this a little. The principle involved is to capture the difference between the joystick's actual value when trimmed, and what you want it to be when trimmed, and apply that difference to future readings.

Jim
  #9   Spotlight this post!  
Unread 24-02-2007, 01:35
dpick1055's Avatar
dpick1055 dpick1055 is offline
David Pick
FRC #1739 (Chicago Knights)
Team Role: Alumni
 
Join Date: May 2005
Rookie Year: 2004
Location: Chicago
Posts: 75
dpick1055 is on a distinguished road
Send a message via AIM to dpick1055
Re: Programming tricks (and former trade secrets)

Oh haha now I get it. I actually scaled our joystick values too so I could use a squaring function for driving. Thanks for the help, this is definitely something our drivers will appreciate.
__________________
Always remember to take your powered wheels off the ground when first testing code. Otherwise you'll end up with holes in the wall like us
  #10   Spotlight this post!  
Unread 24-02-2007, 03:32
6600gt's Avatar
6600gt 6600gt is offline
Registered User
AKA: Lohit
FRC #0226 (Hammerhead)
Team Role: Alumni
 
Join Date: Jan 2006
Rookie Year: 2004
Location: Troy, MI
Posts: 221
6600gt is a jewel in the rough6600gt is a jewel in the rough6600gt is a jewel in the rough
Re: Programming tricks (and former trade secrets)

I started in the summer but I got in working during the build season. When I started I didn't even know the difference between C and C++. Through extensive research I was able to create a kind of "master" dashboard using Visual C++ 2005. It was designed to decrease the debugging time. I also had to develop the support code on the RC to work with this application through the program port.

You can watch any 10 int values simultaneously in a list form. Just choose form two drop down lists, one picks the type of variable(pwms, analogs, D In, D out, joysticks axes, etc.) and the other one is for choosing the number, ex. pwm05, and one can watch any preprogrammed value in real time. No need to reflash just to watch a different pwm!

It also has 16 extras that can be assigned to any variable like this, e_01 = variable(reprogramming is required but its much faster that modifying multiple printfs). Call up E1 from the GUI drop down list and you get a real time stream. The RC only sends 21 bytes over the serial port every loop, yet it provides the GUI with 10 int values.

The GUI can also graph the first 2 columns, allowing one to watch the relationship between the joystick input and the pwm output as it run through his/her algorithms, for example.

Also contains a camera simulator that shows the green tracking box and red cross hair target based on the camera T packet.

Though I haven't gotten around to it yet, I am working on an "fake" OI simulator that will allow me to control the robot from the computer

It was used somewhat for debugging but the robots were never really done...

Last edited by 6600gt : 24-02-2007 at 03:35.
  #11   Spotlight this post!  
Unread 24-02-2007, 16:26
Dave Flowerday Dave Flowerday is offline
Software Engineer
VRC #0111 (Wildstang)
Team Role: Engineer
 
Join Date: Feb 2002
Rookie Year: 1995
Location: North Barrington, IL
Posts: 1,366
Dave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond repute
Re: Programming tricks (and former trade secrets)

Quote:
Originally Posted by JimGRobot View Post
If the joystick value is 130, and you press the auto trim button, the offset will be 3. When this value is subtracted from 130, you get the null value of 127. When the joystick value is 200, you get 197, and 100 you get 97.
Be very careful with this. By doing this you're effectively overriding a safety feature built into the OI by IFI. That feature sets the OI outputs to 127 when the joystick is unplugged. If you have your "auto trim" set to subtract 10 (or whatever), then when a stick gets unplugged your robot will start driving.
  #12   Spotlight this post!  
Unread 24-02-2007, 21:23
JimGRobot JimGRobot is offline
Registered User
AKA: Jim
FRC #1388 (Eagle Robotics)
Team Role: Mentor
 
Join Date: Nov 2006
Rookie Year: 2005
Location: Arroyo Grande, CA
Posts: 29
JimGRobot is just really niceJimGRobot is just really niceJimGRobot is just really niceJimGRobot is just really nice
Re: Programming tricks (and former trade secrets)

Thanks for the note, this is a very good point...

We see the same behavior whenever we reset the RC.

Fortunately, our offsets are small, so the bot doesn't go nuts.

Thanks,
Jim
  #13   Spotlight this post!  
Unread 26-02-2007, 01:34
Dave K.'s Avatar
Dave K. Dave K. is offline
Engineer/Mentor
FRC #0930
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 2005
Location: WI
Posts: 91
Dave K. is a splendid one to beholdDave K. is a splendid one to beholdDave K. is a splendid one to beholdDave K. is a splendid one to beholdDave K. is a splendid one to beholdDave K. is a splendid one to beholdDave K. is a splendid one to behold
Re: Programming tricks (and former trade secrets)

Quote:
Originally Posted by Alan Anderson View Post
Anyone else feel like sharing?
Streamlined, non-directional Encoder Tach code and added a ring buffer. This is used with 100 counts per revolution encoders on each wheel and provides good low speed resolution while still allowing the PID loop to compute new values every 26ms.

Some will recognize Kevin's interrupt framework, but everything else is different.

Here's the relevant portion of the interrupt routine:

Code:
volatile unsigned int Tach_Count[NUM_TACH];
unsigned char Old_Port_B = 0xFF;

void InterruptHandlerLow () {

	unsigned char Port_B;
	unsigned char Port_B_Delta;

  // other interrupt handler code removed for clarity.

	else if (INTCON3bits.INT2IF && INTCON3bits.INT2IE) { // encoder 1 interrupt?
		INTCON3bits.INT2IF = 0; // clear the interrupt flag
		Tach_Count[0]++;
	}
	else if (INTCON3bits.INT3IF && INTCON3bits.INT3IE) { // encoder 2 interrupt?
		INTCON3bits.INT3IF = 0; // clear the interrupt flag
		Tach_Count[1]++;
	}
	else if (INTCONbits.RBIF && INTCONbits.RBIE) { // encoder 3-6 interrupt?
		Port_B = PORTB; // remove the "mismatch condition" by reading port b            
		INTCONbits.RBIF = 0; // clear the interrupt flag
		Port_B_Delta = Port_B ^ Old_Port_B; // determine which bits have changed
		Old_Port_B = Port_B; // save a copy of port b for next time around
	 
		if(Port_B_Delta & 0x10) { // did external interrupt 3 change state?
			if (Port_B & 0x10) {
				Tach_Count[2]++;
			}
		}
		if(Port_B_Delta & 0x20) { // did external interrupt 4 change state?
			if (Port_B & 0x20) {
				Tach_Count[3]++;
			}
		}
	}
}

Initialization:

Code:
unsigned char i, j;

	for(i=0;i<NUM_TACH;i++) {
		TachHead[i] = 0;
		for(j=0;j<TACHBUFSIZE;j++) {
			TachBuf[i][j] = 0;
		}	
	}
And here's the foreground tach code that runs in the 26ms loop:

Code:
#define NUM_TACH 4
#define TACHBUFSIZE 4

extern unsigned int Tach_Count[];  // interrupt routine edge counter
unsigned char i, j;
unsigned int TachBuf[NUM_TACH][TACHBUFSIZE];  // ring buffer
unsigned char TachHead[NUM_TACH];  // TachBuf head pointer
unsigned int Tach[NUM_TACH];  // Tach result register.


			// disable tach interrupts, grab current count, and reset counter

			INTCON3bits.INT2IE = 0;		// Disable INT2 for tach 1
			INTCON3bits.INT3IE = 0;		// Disable INT3 for tach 2
			INTCONbits.RBIE = 0;		// Disable Port B change interrupt for tach 3&4

			// get current tach values into local var, then reset the counter
			for (i=0;i<NUM_TACH;i++) {
				TachBuf[i][TachHead[i]] = Tach_Count[i];	// place current tach count into ring buffer & inc buffer
				Tach_Count[i] = 0;
			}

			INTCON3bits.INT2IE = 1;		// INT2 on
			INTCON3bits.INT3IE = 1;		// INT3 on
			INTCONbits.RBIE = 1;		// Port B change interrupt on


			// sum up the tach counts in ring buffer into Tach[]
			for (i=0;i<NUM_TACH;i++) {
				Tach[i] = 0;
				for(j=0;j<TACHBUFSIZE;j++) {
					Tach[i] += TachBuf[i][j];
				}
				if (++TachHead[i] >= TACHBUFSIZE) {
					TachHead[i] = 0;
				}
			}

                        // Tach[] now contains the unsigned wheel speeds
__________________
--Dave
  #14   Spotlight this post!  
Unread 26-02-2007, 06:55
Alan Anderson's Avatar
Alan Anderson Alan Anderson is offline
Software Architect
FRC #0045 (TechnoKats)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2004
Location: Kokomo, Indiana
Posts: 9,112
Alan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond repute
Re: Programming tricks (and former trade secrets)

Quote:
Originally Posted by Dave K. View Post
Streamlined, non-directional Encoder Tach code and added a ring buffer. This is used with 100 counts per revolution encoders on each wheel and provides good low speed resolution while still allowing the PID loop to compute new values every 26ms.
We did that for the shooter wheel last year, but with a twist. Recognizing that the buffer is essentially a filter that slows down the measurement response, we added the newest value from the buffer multiple times. The resolution stays high, but the sum more quickly represents a change in velocity.

I also came up with an interesting result when I figured how long it took to maintain the ring buffer. With as many as ten entries, it turned out to be faster to move all of the values every time than to index through an array. Array operations are convenient and make for easier coding in many cases, but they can be remarkably slow.
  #15   Spotlight this post!  
Unread 26-02-2007, 13:37
Dave K.'s Avatar
Dave K. Dave K. is offline
Engineer/Mentor
FRC #0930
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 2005
Location: WI
Posts: 91
Dave K. is a splendid one to beholdDave K. is a splendid one to beholdDave K. is a splendid one to beholdDave K. is a splendid one to beholdDave K. is a splendid one to beholdDave K. is a splendid one to beholdDave K. is a splendid one to behold
Re: Programming tricks (and former trade secrets)

Quote:
Originally Posted by Alan Anderson View Post
We did that for the shooter wheel last year, but with a twist. Recognizing that the buffer is essentially a filter that slows down the measurement response, we added the newest value from the buffer multiple times. The resolution stays high, but the sum more quickly represents a change in velocity.

I also came up with an interesting result when I figured how long it took to maintain the ring buffer. With as many as ten entries, it turned out to be faster to move all of the values every time than to index through an array. Array operations are convenient and make for easier coding in many cases, but they can be remarkably slow.
I agree that a weighted average approach can help. In this case, to get the resolution we needed, a sample window of about 4*26 (100ms) worked out about right, but only performing the PID calculations at that rate, made the loop somewhat hard to optimize and user response more sluggish.

I don't doubt that individual moves would be faster as it avoids one or more multiply operations to compute the array index.

Although the interrupt routines use an arrayed variable to store the tach counts, the use of an absolute index allows the compiler and linker to resolve this to a fixed memory location at build time.

The overall simplification of Kevin's code by reworking the logic to remove direction sensing as well as the overhead of function calls helps reduce the CPU loading where the impact is the greatest.

My primary point in sharing the idea was to provide a simpler example of how a velocity only interrupt could work, and to introduce the idea of using a sliding window for data values to improve resolution.


I chose to use arrayed variables in the 26ms loop for the tach code as well as all of the remaining PID code just to help with readability and to make it easy to change the size of the ring buffer, or add/delete motors.

Certainly if the CPU didn't have any idle time left, the arrays are one of the first things I'd go after.
__________________
--Dave
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
Former FIRST student and mentor dies in a tragic rocket attack in Iraq today. Munkaboo General Forum 48 19-04-2005 12:21
Off-season competetions and former teams Venkatesh Off-Season Events 5 10-12-2004 17:23
Harry Potter and the Chamber of Secrets Ryan Dognaux Chit-Chat 33 01-12-2002 19:57
scouting tips and tricks Rick Scouting 1 08-01-2002 00:52


All times are GMT -5. The time now is 21:23.

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