39 replies to this topic

[Chris Seto]

Terrorgen (from TinyCLR) and I were going to make a few IMUs roughly based on the Sparkfun 9DoF Stick: http://www.sparkfun.com/products/10321 Our board would be close to the same as the Sparkfun board, except that we are planning to replace the old HMC5843 for the far less expensive, higher resolution, smaller HMC5883L. We are also replacing the 0402 passive components in the reference design for 0603 for ease of assembly. As it is set, Terrorgen will do the board assembly, but we might do something different depending on how many people want in. We estimate each IMU will be between $30 and $40. Anybody else want to get in on this? This is a cross post from: http://www.tinyclr.c...31/#/1/msg23385 Interested: Freds Brandon G JonnyBoats Quiche31?

[freds]

Terrorgen (from TinyCLR) and I were going to make a few IMUs roughly based on the Sparkfun 9DoF Stick: http://www.sparkfun.com/products/10321

Our board would be close to the same as the Sparkfun board, except that we are planning to replace the old HMC5843 for the far less expensive, higher resolution, smaller HMC5883L.

We are also replacing the 0402 passive components in the reference design for 0603 for ease of assembly.

As it is set, Terrorgen will do the board assembly, but we might do something different depending on how many people want in.

We estimate each IMU will be between $30 and $40.

Anybody else want to get in on this?

This is a cross post from: http://www.tinyclr.c...31/#/1/msg23385

Ahhh, raw board, raw board + parts, or finished board?

[Chris Seto]

finished board, however we'll see. Terrorgen and I just discovered a few things about this. For one, price may be higher than what we thought.

[bill.french]

wiki on IMUs: http://en.wikipedia....easurement_unit

[freds]

You can put me down for a couple. Do you have to poll this board or does it generate interrupts for regular samples?

[Brandon G]

I'd take one as well, that was the board i was going to buy but didnt want the old magnetometer, polling via i2c works for my application

[Quiche31]

I'd take one as well, that was the board i was going to buy but didnt want the old magnetometer, polling via i2c works for my application

This small stick looks awesome! However I have two quick questions, apologies if they are too naive; I have a project in mind but have never used an IMU before:

• Do I understand correctly that the stick has 3 sensors, no on-board MCU, and would deliver the 3x3 raw data without any form of compensation?
• If so the compensation would need to be performed by the Netduino MCU?

My guess is that for some use-cases, such as evolution is real 3D environement, compensation is mandatory, and would rather be performed on an on-board MCU, in native code, rather than on the Netduino in C#, correct? Indeed I am still looking at the 9DOF-Razor which costs that much more, but which would deliver accurate data with greater overall performance, right? Chris Seto, I know that you are expert in this field, so please correct me from wrong

Thanks

[Brandon G]

Chris will be able to answer better, but yes from what i understand there would be no compensation and no mcu. from the razor one here's an implementation by zerov https://code.google..../QuadroLib/Ahrs which might give you an idea of the data coming down

[Quiche31]

Chris will be able to answer better, but yes from what i understand there would be no compensation and no mcu.
from the razor one here's an implementation by zerov https://code.google..../QuadroLib/Ahrs which might give you an idea of the data coming down

Thanks Brandon, that was useful. One difference at least with the stick is that you don't need to parse serial data output, obtained at 38400 bauds, as the stick delivers the individual values via I2C; however by putting in balance the two terms, does this parse-time "compensate" (so to speak) the compensation code performed on the on-board MCU? I found the code below here; in other words what would we lose by executing the below in C# on our 48MHz ARM7, rather than in native C on the on-board 8MHz ATMega?

void Compass_Heading()
{
   float MAG_X;
  float MAG_Y;
  float cos_roll;
  float sin_roll;
  float cos_pitch;
  float sin_pitch;
  
  cos_roll = cos(roll);
  sin_roll = sin(roll);
  cos_pitch = cos(pitch);
  sin_pitch = sin(pitch);
  // Tilt compensated Magnetic filed X:
  MAG_X = magnetom_x*cos_pitch+magnetom_y*sin_roll*sin_pitch+magnetom_z*cos_roll*sin_pitch;
  // Tilt compensated Magnetic filed Y:
  MAG_Y = magnetom_y*cos_roll-magnetom_z*sin_roll;
  // Magnetic Heading
  MAG_Heading = atan2(-1*MAG_Y,MAG_X);
}

[JonnyBoats]

I am interested in purchasing one of these, please add me to the list. Thanks.

[Brandon G]

I think it really depends on the applications requirements. In my case I am controlling a loop and want to read every 200ms which I think can be acomplished and the overhead is ok. I am no expert though I'm learning as I go. What are you using the imu for?

[Chris Seto]

Tell you guys what, Maybe we could have a phone conference or chat conference on this? IF everyone has Skype, that would be ok too. I know Brandon's Skype handle; everyone else PM me with contact info

[JonnyBoats]

Here is a nice introduction to IMU basics: http://www.starlino.com/imu_guide.html

[terrorgen]

Hello, I am the same terrorgen in TinyCLR forums. As Chris Seto had told me, seems like people are interested in having an IMU+microcontroller board. What we thought of is throwing in a cheap dsPIC to do all the calculations. Now some questions to be answered: 1. Shall it be user-programmable? 2. How shall it be interfaced with the main microcontroller (netduino in this case)? I personally prefer SPI/I2C. 3. Motor control Output Pins?

[Quiche31]

Hi Terrogen!

My own take:

• Yes, it should be user-programmable, and a DSPIC is fine
• SPI is faster; watch out with I2C if the on-board MCU needs to be a master too, which I'd assume to be the case. Apparently Netduino does not support I2C multimaster mode; though I don't know the multimaster equivalent to SPI. Or preferably the IMU would be seen as one unique device , whether SPI or I2C (slave in both cases), masking the on-board sensors? I'm fine with this option too, as the firmware can always passthrough the individual, raw, sensors values without compensation, if needed
• How about PWM output pins, that may be used for driving motors or servos

And as you seem to gather potential customers inputs, how about a form factor that allows for breadboarding (0.1") with minimum footprint (e.g. keep the option pins e.g. PWM outputs on an edge for folks to solder if needed, but which would not require additional pins); real eastate in the fuselage of my RC model is a challenge; hence, I like very much the "thin & stick" form factor that you seem to have in mind.
JP

[Chris Seto]

Are are leaning towards a lean pinout mode, so I'm not sure any additional headers would be appropriate... I was mainly thinking about just having a strip of digital headrs that could be bit-banged to whatever protocol the user wanted to use. UART? No problem. I2C? No problem. SPI? No problem. The firmware will be user reloadable, or at least I need it to be to develop it. Well have an ICSP PICKIT header on it. The headers will definitely be standard to breadboard and such. If it's one thing that I _hate_ it's stupid electromechanical connection schemes like the one the Ublox GS507 uses. Proprietary, single mat connector that can't even hold it's own weight without breaking? No thanks... As for sensor masking, the MCU would be used to cross compensate the sensors into pitch/roll/yaw angles which would be available from the chosen comms bus. I think it only makes sensor to also include registers for all the of the raw sensor values, as well as any extras like temperature that sensors may have. ( I haven't looked to see what extra values are available in the datasheets, so no promises yet...)

[Quiche31]

Are are leaning towards a lean pinout mode, so I'm not sure any additional headers would be appropriate...

I was mainly thinking about just having a strip of digital headrs that could be bit-banged to whatever protocol the user wanted to use. UART? No problem. I2C? No problem. SPI? No problem.

The firmware will be user reloadable, or at least I need it to be to develop it. Well have an ICSP PICKIT header on it.

The headers will definitely be standard to breadboard and such. If it's one thing that I _hate_ it's stupid electromechanical connection schemes like the one the Ublox GS507 uses. Proprietary, single mat connector that can't even hold it's own weight without breaking? No thanks...

As for sensor masking, the MCU would be used to cross compensate the sensors into pitch/roll/yaw angles which would be available from the chosen comms bus. I think it only makes sensor to also include registers for all the of the raw sensor values, as well as any extras like temperature that sensors may have. ( I haven't looked to see what extra values are available in the datasheets, so no promises yet...)

You can put me in given these requirements. We have made some progress since the first post!

[darkSol]

Chris, add me to the list - sounds like a great board!

[Chris Seto]

Woops, I noticed a few typos in that last post. I need to be more careful when I am typing a post in a rush Anyway, we'll have some sort of organized meeting sometime this week. For now, everyone post a time that you are free and I think we will just pull the most common one and then air-raid the Netduino chat then. I am pretty flexible, but after 4PM all this week I will be busy. EDIT: My 4PM "busy time" usually will not extend till after 7PM. On Wednesday I may be out much longer. I am west of St. Louis, MO, which means I am in CST (GMT - 6).

[terrorgen]

Anytime after 7pm CST (GMT -6) this week EXCEPT Friday... we got a single's party for valentines day... LOL