I’ve checked in the sources in hg, but it’s still not visible at the codeplex website.
https://hg01.codeplex.com/9dof
… still no source control over codeplex site. But you can use the url I posted and have a look at the code.
shall I join too? I am working at the same code
What’s your CP name, Terr?
it’s the same as the name i use here. I try to maintain the same identity elsewhere…
You’re in.
thanks buddy
question to ponder:
why is the imu sampling all the time when the data is not used? Why not put it to sleep and respond to the controller when the controller needs data?
That means the sampling rate is controlled only on the main controller side.
If you don’t poll the IMU, the receive buffer on the FEZ will overflow.
For a quadrocopter you need the data as fast as possible, so I why should I set it to sleep? If you need the data less frequent you can reduce the baud rate on both sides.
But never ever put the IMU to sleep, otherwise the IMU will not be able to provide accurate data.
My implementation doesn’t. The IMU does exactly as it normally does, but when it gets to the output section of the FW, it looks to see if it has a “P” in it’s input buffer. If it has a “P” it will execute the function to write to serial. Otherwise it will not.
I think we should at least have an option to poll the IMU in our driver. Some people don’t need/want their processor to be at work constantly receiving and parsing. I know it’s a very efficient parser, but that doesn’t change the fact that the proc will still have to take time off from whever else it’s doing.
Part of the reason I I am so against just receiving uncontrollable streams of data is because I did some testing in this area and found that when the FEZ was constantly sampling the IMU, cycling a servo 0-180 degrees took about a few minute when it was only suppose to take a second. the proc had to adjust the wave, then immediately deal with the IMU, rinse repeat.
The thing of it is that the IMU was never used during that servo cycle, so why bother taking time away from a legit task to parse it?
If the messages from the IMU are always the same sentence, then I guess you only need the latest one. Instead of parsing when you get the data, you can store it in a rolling binary buffer (since that operation is very quick) but save the stringification (yeah, I said stringification) and parsing until you actually pull the data.
I’m heading that direction on the GPS code I’m using and will probably go complete with that approach soon. GPS is a little tougher because I have multiple sentence types interleaved together so I’ll want to keep the latest of each. I’ll have to have the GPS output them with the same frequency and have the buffer be big enough that I’ll always have one full set of NMEA sentences.
Chris, I am doing the exact same thing you are. I am having another if statement independent of the sampling routine to check if there is an “I” in the serial buffer and outputs the roll, pitch and yaw angles if it sees one.
(And yes, I hate the processor parsing data that it doesn’t need)
But if we think about how ‘old’ the data will be when it is fetched, then I think a request/respond type of approach might be better. The main controller will request a new set of data to the IMU which samples and outputs data after getting the request. By then we can ensure we are getting the freshiest data.
I just need to determine the response delay and compare it with the approach I have now…
BTW, GC still kicks in once every minute or so for my implementation. I am sending the angles * 100 in int (raw bytes not strings) meaning if I got a reading of 23.34 degrees the IMU will send 2334 in raw bytes and in the parser I use BitConverter to convert the byte arrays into Int16 and divide the converted values by 100. I don’t see any need for GC here though…
There is no reason to believe that the data is “old” or “stale”. If the IMU doesn’t see anything in the buffer, it just doesn’t output. It does not store data waiting for it to be requested.
yah i know… why try sampling data and calculate the tilt if they eventually won’t be sent? just some thinking lol…
Don’t mean to jack up your thread here, but I have been following because I am trying to figure out serial and now starting to think about parsing…
Well I only have 2 technical questions(I know, I am a newbie, what can I say, if I don’t ask I won’t know).
-
What is a GC?
-
IMU, also?
Mike in MN
(I probably will kick myself when I get an answer because it’s probably obvious, but I don’t see it right now.)
[quote]
- What is a GC?[/quote] Garbage Collector??
Mike in MN
Mike, GC is indeed Garbage Collector.
IMU stands for Inertial Measurement Unit, which is the key sensor for all flying robots.
terrorgen,
Thanks for the definitions.
I will get it over time… 
Mike in MN
I know that this thread is quite old but:
Is there any changes in your razor firmware or in the NETMF management of a razor device?
I am spending hard time to have a razor IMU working properly with my EMX board.
I am using a modify version of the AHRS code available on the 10736 sparkfun tutorial website. Modification consists in basically sending continuous stream composed of Yaw Pitch Roll GYRX GYRY GYRZ send as float (4 bytes) each set of 6 floats being separated with a coma.
Sometimes there’s some artefacts, sometimes it’s a glitch and I can not isolate the bug.
Do you have a reliable solution for your razor based IMU that can give YPR and angular speed?
Regards