editor's blog
Subscribe Now

Locus of (Con)Fusion

At the MEPTEC MEMS conference a couple weeks ago, one sensor fusion question kept coming up over and over: Who’s in charge of sensor fusion?

On the one hand, IMU makers in general are giving away sensor fusion packages that help integrate the data from the individual sensors in their combo units. Then there are guys like Movea that don’t make sensors themselves, but integrate across a wide variety of sensors for both high- and low-level motion artifacts (motion in their case, but the concept extends to anything).

So who’s job is it?

I happened to have a conversation with Movea’s DaveRothenberg that same day, and I brought the topic up.

His first comment was that what most IMU makers refer to as sensor fusion is simply the software required to establish orientation, which is a relatively low-level characteristic. He said that this correlated to Movea’s Foundation series, which they’ve actually de-emphasized a bit since it is hard to sell against free software, even if they do think they do a better job.

The sensor guys say they’re the right place to do it because they know their sensors better than anyone else. That actually covers two separate things: the physical characteristics of the sensors and how they operate, and the low-level data details – formats etc. Dave mentioned that it is work for them to adapt their software to different sensors, since they don’t all look or speak alike. (Area for future possible standardization? Future topic…) But they have to get it right in order for the other pieces that lay over it to work properly: errors at the bottom level will compound as further algorithms manipulate them.

(This also ties into the question of loose vs tight coupling, since a sensor maker is in a better position to do things tightly.)

Of course, it’s unlikely that the sensor vendors will want to take on the higher-level algorithms since those, almost by definition, will, at some point, involve sensors that they don’t make. So it looks like things may go the way of the embedded world, where critical low-level drivers and other bits of firmware are provided by (or in close partnership with) the processor maker, with other companies layering higher-value stuff on top. That seems to be how the sensor world is shaping up, which leaves room both for the sensor guys and for the third-party folks.

Leave a Reply

featured blogs
Aug 18, 2018
Once upon a time, the Santa Clara Valley was called the Valley of Heart'€™s Delight; the main industry was growing prunes; and there were orchards filled with apricot and cherry trees all over the place. Then in 1955, a future Nobel Prize winner named William Shockley moved...
Aug 17, 2018
Samtec’s growing portfolio of high-performance Silicon-to-Silicon'„¢ Applications Solutions answer the design challenges of routing 56 Gbps signals through a system. However, finding the ideal solution in a single-click probably is an obstacle. Samtec last updated the...
Aug 17, 2018
If you read my post Who Put the Silicon in Silicon Valley? then you know my conclusion: Let's go with Shockley. He invented the transistor, came here, hired a bunch of young PhDs, and sent them out (by accident, not design) to create the companies, that created the compa...
Aug 16, 2018
All of the little details were squared up when the check-plots came out for "final" review. Those same preliminary files were shared with the fab and assembly units and, of course, the vendors have c...
Jul 30, 2018
As discussed in part 1 of this blog post, each instance of an Achronix Speedcore eFPGA in your ASIC or SoC design must be configured after the system powers up because Speedcore eFPGAs employ nonvolatile SRAM technology to store its configuration bits. The time required to pr...