<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Normed Space &#187; inertial sensors</title>
	<atom:link href="http://instk.org/blog/?feed=rss2&#038;tag=inertial-sensors" rel="self" type="application/rss+xml" />
	<link>http://instk.org/blog</link>
	<description>My inertial life</description>
	<lastBuildDate>Mon, 17 Sep 2012 23:05:39 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=4.2.3</generator>
	<item>
		<title>Comments on &#8220;inertial sensor prices&#8221;</title>
		<link>http://instk.org/blog/?p=178</link>
		<comments>http://instk.org/blog/?p=178#comments</comments>
		<pubDate>Wed, 29 Aug 2012 23:25:29 +0000</pubDate>
		<dc:creator><![CDATA[odtu_ee]]></dc:creator>
				<category><![CDATA[IMU]]></category>
		<category><![CDATA[inertial sensors]]></category>

		<guid isPermaLink="false">http://instk.org/blog/?p=178</guid>
		<description><![CDATA[&#8220;vendor-XYZ&#8221; has sent me the following comments regarding to the previous blog post. As his comments contain precious information for any INS designer, I am reposting them here with his permission.  &#8220;The sensor manufacturers keep everything related with their sensors &#8230; <a href="http://instk.org/blog/?p=178">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p>&#8220;vendor-XYZ&#8221; has sent me the following comments regarding to the <a title="Inertial sensor prices" href="http://instk.org/blog/?p=165">previous blog post</a>. As his comments contain precious information for any INS designer, I am reposting them here with his permission.</p>
<hr />
<blockquote><p> &#8220;The sensor manufacturers keep everything related with their sensors as confidential. They are even unwilling to share the per unit price of their sensors.&#8221;</p></blockquote>
<p>Sadly this is true in most cases, it even makes it difficult to us vendors, who want to openly do a competitive comparison. From a competitive standpoint, no one wants to be the first to change this and be at a competitive disadvantage and expose their own IP.</p>
<blockquote><p> &#8220;Intersense is a cheap MEMS inertial sensor manufacturer whose product is much lower quality than the other items in the list.&#8221;</p></blockquote>
<p>BTW, I&#8217;ve received multiple confirmations from NAVCHIP customers that Intersense will be pulling the NAVCHIP from the market.</p>
<blockquote><p> &#8220;Systron Donners SDI500 is a 6DOF IMU. The specification in their website is quite promising. However, I find it difficult to believe that that unit will be capable of showing the specified performance in the field.&#8221;</p></blockquote>
<p>I also heard from Systron insiders that the company is going through some financial difficulties and re-orging, but none the less I think they make good products since they&#8217;ve been around for decades now.</p>
]]></content:encoded>
			<wfw:commentRss>http://instk.org/blog/?feed=rss2&#038;p=178</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Inertial sensor prices</title>
		<link>http://instk.org/blog/?p=165</link>
		<comments>http://instk.org/blog/?p=165#comments</comments>
		<pubDate>Tue, 31 Jul 2012 18:18:31 +0000</pubDate>
		<dc:creator><![CDATA[odtu_ee]]></dc:creator>
				<category><![CDATA[IMU]]></category>
		<category><![CDATA[inertial sensors]]></category>

		<guid isPermaLink="false">http://instk.org/blog/?p=165</guid>
		<description><![CDATA[The sensor manufacturers keep everything related with their sensors as confidential. They are even unwilling to share the per unit price of their sensors. And yet, they seriously expect us to decide on selecting their units without actually knowing any &#8230; <a href="http://instk.org/blog/?p=165">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p>The sensor manufacturers keep everything related with their sensors as confidential. They are even unwilling to share the per unit price of their sensors. And yet, they seriously expect us to decide on selecting their units without actually knowing any single thing about them.</p>
<p>Anyway, recently I had to select some inertial sensors for one of the projects I was working on. Therefore, I had sent a couple of emails to manufacturers asking for their prices. Here is a short list of these prices. If you are also in search of some compact inertial sensors, this list will save you waiting for weeks before those bastards graciously accept to answer your quote requests:</p>
<blockquote><p>Goodrich<br />
SiIMU02: $9,000<br />
AIMU: $11,000</p>
<p>Honeywell (Only accelerometers)<br />
QA650: $1,200<br />
QA700-010: $1,800<br />
QA700-020: $1,900<br />
RBA500 :$1,200</p>
<p>Systron Donner<br />
SDI500: $16,000<br />
SDG1000:$2,000<br />
QRS116:$2,900<br />
QRS14: $1,100<br />
SDG500: $700</p>
<p>KVH (Miniature Fiber Optic Gyroscope)<br />
DSP-1750: $4000(Single Axis, Dual axis is $8000)</p>
<p>Intersense<br />
Navchip ($1300) (Engineering Sample:$4000)</p>
<p>Litef (Previously independent, but now a subsidiary of Northrop Grumman)<br />
µIMU-IC: 12,000 Euro</p>
<p>&nbsp;</p></blockquote>
<p>Among the above sensors I should say that I was impressed by the KVH&#8217;s mini fiber optic gyroscopes. For years, we were stuck with MEMS sensors when we have very tight space constraints. Finally, a manufacturer can think of compacting its FOGs as an alternative to  MEMS. (In fact Honeywell has some compact and rugged RLGs for years. But, I do not know if it is possible to buy them.) The size of DSP-1750 is less than 3inch which is perfect for many application with tight space. I hope in the future they will release more FOG units like that so that we can totally get rid of other arrogant MEMS manufacturers.</p>
<p>Intersense is a cheap MEMS inertial sensor manufacturer whose product is much lower quality than the other items in the list. However, I like their design and engineering. (It is at least better than the similar products of Analog devices which is a hopeless manufacturer. It is indeed a mystery for me that how the engineers in Analog devices can succeed in being so dumb.) So if you are looking a MEMS unit in that price range, you may want to check the Intersense&#8217;s navchip. (I was planning to build a high accuracy IMU block with redundant configuration using this sensor. Yet, due to reasons that are out of my control, I was not able to realize this plan. I still believe that using 8 navchip in a single IMU block can be better that buying another expensive option.)</p>
<p>Honeywell is almost unrivaled in its accelerometers. If you need an accelerometer, you do not need to look for any further than Honeywell. Recently I heard of another company called &#8220;japan avionics electronics&#8221; who is said to have also some good accelerometers. However, I could not find any meaningful information in their website. Also, those bastards did not return my email. That is why I do not know their accelerometer price either. However, in any case, I do not think that their accelerometers can be any match to Honeywell&#8217;s unit.</p>
<p>Systron Donners SDI500 is a 6DOF IMU. The specification in their website is quite promising. However, I find it difficult to believe that that unit will be capable of showing the specified performance in the field. Lab test results of MEMS units can always be misleading. That is why, I find it a risk to invest on that product for any project. Instead of using it, I would prefer to go for KVH&#8217;s fiber optics with honeywell&#8217;s accelerometers.</p>
<p>PS: , I have to mention that there are plenty of other sensors out there with better performance/price ratio. I had inquired the above sensors with some space limitations on my mind. If you have no space constraints in your project I would advice you go for older generation products of Litton or Honeywell. (Though it is really a pain to by anything form honeywell. Most probably you won&#8217;t even be able to get a list of their RLGs.)</p>
]]></content:encoded>
			<wfw:commentRss>http://instk.org/blog/?feed=rss2&#038;p=165</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Zero motion detector for inertial sensors</title>
		<link>http://instk.org/blog/?p=134</link>
		<comments>http://instk.org/blog/?p=134#comments</comments>
		<pubDate>Mon, 19 Mar 2012 01:00:35 +0000</pubDate>
		<dc:creator><![CDATA[odtu_ee]]></dc:creator>
				<category><![CDATA[Android]]></category>
		<category><![CDATA[IMU]]></category>
		<category><![CDATA[INS]]></category>
		<category><![CDATA[zero motion]]></category>
		<category><![CDATA[inertial sensors]]></category>
		<category><![CDATA[zero motion detector]]></category>

		<guid isPermaLink="false">http://instk.org/blog/?p=134</guid>
		<description><![CDATA[Zero motion detection for low cost MEMS units is an extremely important topic that has not received enough attention in the navigation community. For most low-cost inertial navigation applications, the only aiding source that can be used to limit the &#8230; <a href="http://instk.org/blog/?p=134">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p>Zero motion detection for low cost MEMS units is an extremely important topic that has not received enough attention in the navigation community. For most low-cost inertial navigation applications, the only aiding source that can be used to limit the velocity errors (and thus reduce the position error divergence rate) is the zero-velocity updates. Despite its significance, there is only a couple of papers that deal with the detection of the zero-motion instants and, unfortunately, some of these papers are written by self-deceptive ignorants. (After this blog entry, I am planning to write another entry just to expose one such example.)</p>
<p>Theoretically, it is impossible to detect zero velocity instants by relying only on the accelerometers and gyroscopes. Even if we had perfect inertial sensors, which are completely noise free, and used the magnitude of the gravity and Earth rotation rate as our decision thresholds, our detection algorithm would not be able to differentiate a constant motion from a zero-velocity.</p>
<p>However, because of its importance especially for human motion tracking algorithms, we have to improvise some kind of a zero-motion detection method. As long as these algorithms do not generate too much false positives (zero-motion detection during a motion), we can still use them to diminish the accumulated velocity errors and, to a certain extent, to stabilize the roll/pitch errors.</p>
<p>In addition to this false-positive problem, zero-motion detectors also impose a big burden on the processing side. As I have described in my previous blog entries, we do not need inertial sensors to have very high data rates. As long as they provide angle and velocity increments, we can read their outputs at a very low rate without causing any algorithmic error. However, this is not the case for zero motion detectors at all. Zero-motion detectors need as many samples as possible to reduce their false positive probabilities. That is the reason why we need MEMS sensor producers to embed such decision algorithms into their sensors so that we don’t have to deal with all the problems associated with the high data rates.</p>
<p>Unfortunately, realizing this approach is not as easy as it may seem. First of all, what is a zero motion detection algorithm? Does anyone has ever answer this question? Or, does anyone have ever been able to come up with an optimal detector? The answer is unfortunately no. As a matter of fact the answer will always be “no”, because theoretically it is impossible to find one. All we can do is to adapt some ad-hoc method and hope for the best. In this case, what kind of algorithm can we expect from MEMS producers to embed in their system? Can such a thing be possible by any means?</p>
<p>Recently, I have been working on this issue. I tried to invent a method to be embedded in MEMS sensors such that it can be used for both ordinary and advanced users to detect zero motion instants. Ordinary users only need auto-decision result (regardless of its false positive rate), whereas an advanced user would possibly require all the raw sensor data to generate its own decision. A practical algorithm should also be capable of helping the user in between these groups by providing only the sufficient amount of useful data required for a meaningful decision.</p>
<p>At first I tried to formulate zero motion detection problem in terms of H-infinity settings. For a robust detection algorithm, we have to assume that nature always try to deceive us as much as possible. Therefore, I hoped I could come up with a meaningful 2-people zero-sum game definition and then robustly estimate the worst case motion. However, as in the case of my previous PhD topic, I totally failed. (I had studied the application of H-infinity theory to the navigation systems for 2 years before switching to my last PhD topic of redundant sensors and finally being able to graduate.)</p>
<p>Meanwhile, I realized one important fact about the motion: an acceptable motion definition certainly requires a scale to be associated to the data. Both a spike and almost a constant value in the sensor outputs may denote (hint) a motion. A spike cannot be detected if the data is analyzed at higher levels (averaged signals), whereas a small (almost) constant level output will be burried into additive sensor white noise if the analysis is performed at a very low level (row signal level).</p>
<p>As a result, I abandoned h-infinity concept and turned my attention into multi-resolution signal techniques. At the end, I came up with reasonable (non-orthogonal) signal bases each of which represent the change in different scales within a given data window. Together with these bases I also needed to derive some kind of threshold for the decision algorithm. I did not have to think about this part at all because I already knew that Allan variance coefficients is nothing but the Haar wavelet variance of the stationary signal. Therefore, previously computed Allan variance coefficients contain all the threshold values that I needed. Combining all these pieces of findings together, I finalized my zero-motion detector for low cost MEMS units. Given a data window, my detector first computes the signal coefficients for each basis function and then compares these coefficients with the threshold values to determine whether a motion exists or not.<br />
In the following video, you can see the result of my zero motion detector. I wrote a simple application to broadcast the inertial sensor data of my “wannabe death” htc phone. I also coded simple python scripts to process these data in real time with my zero motion detector on the PC side. At the end, I output the result of the detector using a simple 2-color GUI. The red rectangle means a zero-motion detection instant and the green rectangle represents motion.</p>
<p><iframe width="450" height="338" src="http://www.youtube.com/embed/1eTtztltuRM?feature=oembed" frameborder="0" allowfullscreen></iframe></p>
<p>As you can see from the above video, my motion detection algorithm is at least capable of reasonably detecting motion/no motion instants. Although this video does not contain an example, my algorithm unavoidably suffers from false positives too. However, as the video proves, it can be still be considered sufficient for simple human motion tracking applications.<br />
The most important feature of my algorithm is not its zero motion detection capability. The power of this algorithm comes from the fact that it relies on multi-resolution signal analysis. Therefore, it can serve for any user group equally well. If such an algorithm is embedded in an inertial sensor, the user can easily determine the amount of useful decision data to be delivered from the sensor. For instance, an average user can request the sensor to send only the biggest 5 coefficients, whereas an advanced user can request all the coefficients to reconstruct the original signal. In the above video, the decision is based on only the biggest coefficient which is all an ordinary user would probably care about.</p>
<p>With this final invention of mine, I am one step closer to my ultimate smart front-end design for MEMS inertial sensors. I know one day I will be able to convince some MEMS producers to listen to my genuine ideas.</p>
]]></content:encoded>
			<wfw:commentRss>http://instk.org/blog/?feed=rss2&#038;p=134</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
