delay() is pretty accurate, but fairly useless for a variety of other reasons.  One of them of course being the problem you are running into.  It's rather useless when used in conjunction with the rest of the program to perform overall timing.

Take a look at the Blink without Delay sample.  That provides a good method for overall timing.

To everyone who assumes my code will not compile, you look really ignorant and rude right now as my code def compiles and will fully upload and run on my build.

No assumptions have been made.  The code you provided in your initial post does not compile, period.
I highly recommend reading the sticky in this forum.  The one titled 'Read this before posting a programming question'.  Perhaps you already think you know what that post contains.  I can assure you though, based on the above comment you've made, you have no idea what that post contains.

You are creating a whole bunch of consecutive pointers into your array inParse, when you can just pass that array into your sort methods.
And since your chan array lines up with your parsed array, you can also loop through the assignments instead of individual separate assignments.  Here's an example (separate from your own sources):

Code:

char buffer[] = "12,345,55,178,9,77,900,122";
//inParse only needs to be as large as the number of individual int strings strtok will find in buffer
//It does not need to be as large as buffer
char *inParse[8];
int values[8];

void setup()
{
  char *s;
  int count = 0;
 
  s = strtok(buffer, ",");
  inParse[count++] = s;
  while(NULL != s)
  {
    s = strtok(NULL, ",");
    if(count < 8) inParse[count++] = s;
  }
 
  //We only need to pass in a single value, a pointer to our array of pointers
  //ie, a pointer to a pointer (char**)
  Convert(inParse);
 
  Serial.begin(115200);
  for(int x = 0; x < 8; x++) Serial.println(values[x]);
}

void loop(){}

//An array of pointers is basically just a pointer to a pointer
void Convert(char** arr)
{
  for(int x = 0; x < 8; x++)
  {
    //Here's where the magic happens.
    //We dereference our array pointer, to pass our char * to atoi()
    //And also increment the array pointer to the next element in our array
    values[x] = atoi(*arr++);
    //Or, if you're having trouble wrapping your mind around that, try this:
    //values[x] = atoi(arr[x]);
  }
}

No, I'm so used to HTML that this is the structure I am used to seeing, and makes it easier for me to read my own code... Even my java looks like that...

When asking strangers for help, it's probably best to try to accomodate them as best as possible.  Help them help you, and you'll get better help.  Hint:  The Arduino IDE has an Auto Format capability in the Tools menu.

I don't have to take serial data as String?

No.  You can, and should, stick to char arrays.

From here on out, it is obvious to me that you are a much more advanced C++ programmer than myself. I have no idea what a bounds check is...

Bounds checking isn't all that advanced stuff.  You should spend some time brushing up on your C++ skills.  In summary, C++ does very little for you.  if you create an array of 5 elements, you can try to access the 10th element, and C++ won't stop you.  You'll just access memory beyond the array, and who knows what value that memory is going to contain.  Worse still would be changing that memory.  It's up to you to make sure you're index values are within the bounds of your array.

This isn't an instance of me frying some hardware, but an amusing instance still.

Back about 12-14 years ago we were working on a new product that supported two new cameras from Dalsa, one a high speed 2k linescan camera, and the other a high speed 2kx2k areascan camera.  Both cameras were in identical packaging with identical connectors.  However, the linescan camera operated on 24v and the areascan camera only operated on 12v.  Needless to say, it was entirely possible to connect the 24v power supply to the 12v camera.  Our lead engineer was constantly lecturing everyone about the risk, and to always be sure what camera and power supply they were using (the power supplies were identical in appearance as well).  About a month into the project, the lead engineer was the one to plug the 24v power supply into the 12v camera.  And of course, the areascan camera was the more expensive of the two as well, $20k at the time vs I think $7k for the linescan.

If I pass a character array to a function, then add to it by using strcat() will my program adjust the memory allocated for this char array, or am I going to run into a memory problem.  For example

strlcat() can be used to prevent writing outside the bounds of the destination buffer.  It will just truncate the second string if necessary.  Here is the reference for all the C string library functions: http://www.nongnu.org/avr-libc/user-manual/group__avr__string.html#ga1fd2a6e188f02599e5eeb17519f67f3e

Code re-use is a wonderful thing:
http://arduino.cc/forum/index.php/topic,106043.0.html

There are plenty of rover kits that are designed to be custom modified as well as integrated with an Arduino.  These kits will almost universally be a better option than buying a new toy and hacking it apart.

Now, buying an old RC toy car from a yard sale for a few bucks, that may be worth the effort, since there's little financial investment involved, and a similarly sized robotic rover will be substantially more money (think of the Dagu Wild Thumper 4wd/6wd rovers).

His code is published for all to see.  Go read it.  There are no physical computations.  There are no torque calculations. I'll sum it up as thus:
He reads an IMU and computes an angle based on those readings.
He feeds that angle into a PID controller that, with three tweakable parameters (Kp, Ki, Kd) outputs a raw value.
He clamps this raw value to the range his motor controller wants to use.
He feeds this value into the motor controller, that simply linearly converts it to some PWM output to drive the motors.

With the exception of some remote control code, that is ALL his code does.  Again, the code is available.  You are arguing that he is doing things that simply aren't in his code.  That's the beauty of PID controllers.  You can spend days, weeks, even months, developing an accurate physical representation in code that MAY be able to properly balance your robot, or you can spend hours writing a simple PID controller, and maybe another couple of hours tweaking the PID to balance your robot.  This is a method that has been used thousands of times by a variety of people, myself included.

If for example the PID says a torque of 1 Nm is needed

The PID does no such thing.  It simply outputs a dimensionless value that abstractly represents how much adjustment needs to be made to attain/maintain it's 'ideal' state (that is, the robot standing straight up) based on it's input mechanism (the IMU).  That value is converted into a PWM output to the motor.  The K values are tweaked to provide optimal balance.  There are no real 'physics' calculations involved at all.  It's just some rather abstract tuning (though the Proportional, Integral, and Differential portions of the PID do have different characteristics regarding how the influence they output value).

Those are some rather extreme examples.  Worst case I ever saw in an actual work environment was a function called:

AsicMonsterOverrideBurstSizeAndInterval(int, int);

I've personally never had any trouble reading CamelCase (even your unrealistic example), and the majority of variables/functions don't need to be more than 2-3 words long to be adequately described anyways.

Looks really nice!
I've read the PDF in your github, it was very informative and easy to understand.
I'm thinking of building a self balancing robot my self and may I ask how are you controlling the motors?
You don't have encoders so I'm guessing its an open loop design(?), how do you control the torque they output?

He's using a PID controller to drive the motors based on feedback from the IMU.

The Arduino's source code highlighting provides the ability for library writers to specify their own keywords to be highlighted that are in some way associated with their library.

If interval is getting highlighted, it's because you have an additional library that you've added that put that word into it's keywords list.
Highlighting has absolutely nothing to do with the code getting compiled.  It's purely a visual 'enhancement' for the code writer.

and I force myself to read 2 hours a day... Too.

Spend less time reading, and more time writing.  That's how you really learn.  Spend those 2 hours a day writing actual code (and, of course, getting it to actually work as well) and you'll learn a whole lot more.

primitive version of TCP that works over serial and protects data integrity.

Primitive and protects data integrity don't really go together well.

At the very least, you'll need a start and end of packet marker that is unique, ie the rest of the data cannot duplicate these markers, which adds a layer of complication itself when dealing with binary data, and a checksum for the actual contents of the data packet.

You'll also have to decide how you want to handle the cases where the packet is compromised as well.  You don't really have complete data integrity if you just ignore corrupted packets.  The typical method of handling this is with some sort of Ack/Nak protocol.  If data transmission isn't bandwidth constrained, a rather simple approach to implementing an Ack/Nak would be:
Sender transmits packet, and waits for an Ack or a Nak.
If no Ack/Nak is received within some timeout period, or a Nak is received, packet is retransmitted and Sender again waits for Ack/Nak.
If Ack is received, next packet is transmitted.

On the receiver side, if a valid packet is received, send an Ack, if a corrupted packet is detected, then send a Nak.  Your corrupted packet detection will need to be fairly good for this to work well.  For the most part, you just want to be able to detect missing start and end packet markers and verify checksum.  Other potential data integrity checks would be a sequence number and/or packet length value added to the packet as well.

Having said that, it looks like serial.print is assuming you have passed a long rather than a char, which I don't understand yet.

All of the various print(type, base) overloads are piping through print(long, base) apparently to avoid code duplication.  The unfortunate side effect is that Hex values print with too many leading Fs.