I need to obtain and process sensor values in realtime in a loop time of 2 milliseconds. With C# I’ve 10 milliseconds at the moment.
The sensors I need are gyro, accelerometer and compass. Then the values are processed with a kalman-filter and a PID-control.
The funny thing is that, a friend of mine is doing the same things in 2 milliseconds with a I believe 12MHz processor in C++, this is 5 times faster than a 72MHz FEZ Spider programmed in C#…
The basic pseudo-code looks like that:
//THREAD1
gyro.ContinuousMeasurementInterval = new TimeSpan(0, 0, 0, 0, 1);
compass.ContinuousMeasurementInterval = new TimeSpan(0, 0, 0, 0, 1);
accelerometer.ContinuousMeasurementInterval = new TimeSpan(0, 0, 0, 0, 1);
gyro.StartContinuousMeasurements();
compass.StartContinuousMeasurements();
accelerometer.StartContinuousMeasurements();
//THREAD2
void loop()
{
while(true)
{
Calculate(); //Loop time is 10 milliseconds
}
}
void Calculate()
{
//do something with gyro, compass, accelerometer values
}
I’m not very experienced with RLP, I tried some basic things and they worked. But how can I use it in my case to speed things up?
It wouldn’t work if I just implement the loop procedure in native c ? Is it possible to obtain sensor measurements directly in RLP?
Loop time is 10ms? As in, with Calculate() being no-operations you can call it only 100 times a second?
Or does that mean the current Calculate() function (code not present) takes 10ms?
Rather than RLP (which I’ve not played with yet), might it be an option to offload the fast loop of sensor scans and kalman filtering and what have you to a separate AVR chip, which can then maybe send a stream of processed heading data or even course correction data back to the FEZ gear via serial, SPI or I2C, your NETMF code is then freed up to think about ‘higher level’ stuff? Something like [this] kit from Sparkfun would get you more than enough of the bits and pieces needed - more likely just need the Atmega328, crystal and couple of capacitors, and maybe even just the chip itself if its internal 8Mhz clock is activated instead of the 16Mhz crystal. I think this is more or less what’s going on in things like the Razor 9dof IMU anyway.
Thanks that could be a solution, I’ll keep that in mind.
But I’d prefer a solution without another chip. So are there other ideas how to handle this? I find it a bit confusing that a single 12MHz chip, is able to deal with all that stuff and a 72MHz needs another helper chip…
The 12Mhz chip is running C/C++ compiled to native machine code on bare metal, the 72Mhz chip is interpreting intermediate managed bytecode on a virtual machine - you gain nicer language constructs and memory management and ease of development and all that, but it’s definitely a lot slower to execute. You might be able to do something with RLP, but my understanding is that when you’re running RLP your NETMF threads are blocked, and when you’re running your NETMF threads your RLP isn’t running - I’m assuming you want your sensor stuff to be continually checked all the time, so if you went down that path you might find that you had to stay in RLP all the time too, losing the ability to do stuff in NETMF (including, as you’re finding, all the driver libraries).
The pseudo looks incorrect to me. Digital controllers don’t work like that. The sensors need to be polled at a specific frequency, so tightly toleranced timing is the key. Not necessarily having it at such high speed that it behaves like analog.
One of the RLP examples shows how to unblock the native code and send the processing back over to managed code for whatever to execute. Other than that, from what I have learned so far, its just accessing pins. So if the sensors are I2C or SPI it should be very straight forward. If they’re analog then it might be a different story.
2 ms (500Hz?) seems extremely sporting for a control algorithm. Especially for attitude control, which is what an accel + gyro + magnetometer leads me to believe. It’s likely that you could run at 1/5 that rate and still be fine. Is the 2 ms supposed to be the sample rate for the kalman filter or something? It make me wonder what your trying to control, and what the bandwidth of the controller is. Do you have a particular application in mind?
