Description: The Intel® Edison is an ultra small computing platform that will change the way you look at embedded electronics. Each Edison is packed with a huge amount of tech goodies into a tiny package while still providing the same robust strength of your go-to single board computer. Powered by the Intel® Atom™ SoC dual-core CPU and including an integrated WiFi, Bluetooth LE, and a 70-pin connector to attach a veritable slew of shield-like “Blocks” which can be stacked on top of each other. It’s no wonder how this little guy is lowering the barrier of entry on the world of electronics!
The 9 Degrees of Freedom Block for the Intel® Edison uses the LSM9DS0 9DOF IMU for full-range motion sensing. This chip combines a 3-axis accelerometer, a 3-axis gyroscope, and a 3-axis magnetometer. By default, the IMU is connected to the Edison through the I2C bus. Each sensor in the LSM9DS0 supports a wide range of, well, ranges: the accelerometer’s scale can be set to ± 2, 4, 6, 8, or 16 g, the gyroscope supports ± 245, 500, and 2000 °/s, and the magnetometer has full-scale ranges of ± 2, 4, 8, or 12 gauss. Additionally, the LSM9DS0 includes an I2C serial bus interface supporting standard and fast mode (100 kHz and 400 kHz) and an SPI serial standard interface.
If you are looking to add a little more stability to your Intel® Edison stack, check out this Hardware Pack. It will provide you with increased mechanical strength for stacking Blocks on your Edison!
Note: We are currently working on a Hookup Guide for this kit. Check back later for more updates.
Note: While there are jumpers for SPI, it is not supported.
Based on 11 ratings:
3 of 3 found this helpful:
This works perfectly with RTIMULib of richard-tech which is open source. This library is so good that you can work without difficult configurations (i2c bus, address, chip type, registers etc..) .
Project top https://github.com/richards-tech/RTIMULib
Document for Linux (Including instruction for Intel Edison) https://github.com/richards-tech/RTIMULib/tree/master/Linux
2 of 2 found this helpful:
This is everything you need to start reading the sensor data without a bunch of extra crap:
Please, please be a friend and vote for us!
2 of 2 found this helpful:
I received this board last week along with the PWM board, I now have a working Intel Edison based quadcopter.
I have just one remark about the mechanic: the mounting holes of the Sparkfun boards are not the same as the Intel breakout board. I will have to buy specific screws to mount all the boards.
5 of 5 found this helpful:
The hardware appears nice so far, and the options for power management, data capture modes and especially the programmable interrupts seem quite professional (at least to a software guy like me).
The complexity leads to the downside: the apparent lack of libraries / documentation is not making it easier to get started. At least getting links to the datasheet (1) and the code for a similar Arduino breakout(2) would have been appreciated.
Still, the block itself has exceeded expectations so far. If anyone is interested in very rough C code that uses the block, see my hacks here: https://github.com/jku/LSM9DS0 .
0 of 1 found this helpful:
good working system
Too bad this device is hardcoded to one of two address. It limits any device to one (or two) IMU per project. When one thinks of a robot arm, it is useful to know the orientation of EVERY part and thus I have a need for one IMU per element. Unfortunately this is impossible with this device.
I’m using it with the Edison Mini Breakout. The Mini-breakout has some headers (J1 and J2, I think) that get in the way and disallow the board from stacking. The headers would go through roughly where the X/Y/Z diagram is.
Would any Sparkfun tech mind telling me if it’s okay to file away that spot until it fits? I don’t see any PCB traces there, but I want to be sure before I go at it with any tools.
Shawn wanted me to pass this along to you - “ If there are no traces present, you should be able to file away PCB without hurting anything. Alternatively, you can de-solder J1 and J2 in order to stack the Block.”
The performance of this tiny little chip’s performance exceeds expectations, having survived a sustained acceleration of over 30G’s for over an hour in a centrifuge. Real time communication was still possible, even without the external antenna for the Edison - through a foot of reinforced concrete.
Even with (relatively inefficient) Python program logging the data, sampling rates of 1200Hz per axis of the accelerometer is possible. Highly recommended for just about any application or project!
Calibration is tough. I seem to get pretty stable readings on the x axis and plane, but y and z tend to be erratic. I even tried to replicate what was done the arduino example code for the other 9dof board with the same chip, but it still doesn’t zero out and set a bias. I am wondering if the wifi signals from the Edison affect the readings. Still working on it
I used RTIMULib to get up and running. I am not sure I like how RTIMULib is handling the compass data as it seems to neglect magnetic inclination, but I can deal with that.
I debated 2 stars, but I’m curious what other’s have noticed. Some of the sensor data is quite noisy. To quantify, with the system running only on battery power (no outside charger) and sampling at about 350hz and a moving average filter to 50hz (7 sample moving average) below is the standard deviation I get for each sensor: AccX = 0.0042 G / AccY = 0.0027 G / AccZ = 0.0097 G / GyroX = 0.264 deg/s (average = 0.0015 deg/s) / GyroY = 0.352 deg/s (average = 0.0023 deg/s) / GyroZ = 0.272 deg/s (average = 0.0030 deg/s) / CompassX = 3.2 / CompassY = 0.58 / Compass Z = 0.96
I can live with the Z axis accel being 2-3X as noisy as I’m putting it in a car to measure dynamics with a GPS and we can live without vertical motion. The X axis of the compass being 3-5X more noisy than the other axes is a problem and I can’t really use it to filter the gyros or differentiate heading (GPS) from orientation (compass + gyro). Note that I did the RTEllipsiod calibration of the compass per RTIMULib but I don’t see anything in the calibration that would create such an issue. Additionally the angle appears to be correct as the average points towards magnetic north (including inclination)
Though I am pleasantly surprised at the zero accuracy of the MEMS gyros. I haven’t put it on a turn table so not sure how accurate the dynamics are…
Maybe I got a busted sensor? Is there any QC program
update: further experimentation on orientation I think the magnetic sensor isn’t going to work well buried in an edison stack. The battery is right next to it and that’s likely having a big impact on the magnetic reading. I can get very different numbers for magnetic dip (angle to horizontal) depending on orientation which I think is due to the battery and other components in the stack. Maybe responsible for the noise, maybe not…