spillerrec wrote:I would assume that Simulink takes care of that, though I have nothing to base that on.
Yes, you are quite right. Simulink and Matlab do initialise variables with values of zero.
Oh yeah, I found the problem! The raw sensor data is fed into a series of kinematic equations that are based on the physical dimensions and range of motion of the vehicle. Ideally, the vehicle cannot move sideways, so the equations do not take into account any lateral slippage of the tyres. However, the sensors will pick up movement in any direction. Hence, raw data that include any lateral slippage will not be calculated correctly using the existing equations. The errors will accumulate over time and the vehicle will soon lose its bearings. Running the vehicle on the polished floorboards in my home means that the tyres are constantly slipping longitudinal and laterally. Naturally, errors will add up quickly this way. That's why the NXT seemed to behave so randomly.
I had said before that the positional data had agreed quite well with the path taken by the vehicle even when it seems to go in random directions. In hindsight, I may be mistaken. Since the vehicle does not mark its path physically, I can only take visual note of its general movement. If a path charted in Excel resembles the path taken by the vehicle moments ago, I would say it's a good match for a preliminary test. In this case, the discrepancy between perceived and actual coordinates could differ by several centimetres without my knowledge. Since the vehicle goes out of control so quickly, I never let it run for long except when it goes into the stop-start mode. Had I let the test runs go for longer, the compounded errors would have been so great that physical paths would eventually look very different to the ones plotted in Excel.
Now that I've revised a couple of equations, the vehicle runs quite okay. The algorithm still needs some fine tuning to improve tracking accuracy, but the vehicle will follow the general trajectory set for it. So, Matt and James, you're both quite right that the processor wasn't "overloaded". I've tried various sampling times since, and the processor seem to handle it quite well. I'm really quite impressed with what this little processor can do! However, the tracking performance seemed to take a nosedive when I reduced the sampling time to 0.005s. I discovered that the positional data was way off, and then I remembered that it's most likely due to the sensor being limited by the NXT's 9600 kbps I2C bitrate.
The strange thing is that the stop-start behaviour hasn't gone away. It still happens every now and then. It's not a bother, but I'm curious why this happens. It's almost like the processor is experiencing a brain freeze.
Thanks to both of you for your valuable insights. Now I can concentrate on improving the algorithm without worrying about processor issues.