标签: sensors

A few days ago, I wrote about Nighttime Aerial Drone Ballet . This little rascal boasted a video showing a large number of drones flying at night with their movements and accompanying light display choreographed to match a live performance of Beethoven’s Fifth Symphony.   I was originally alerted to this video by my chum Arthur Smith in the UK. Once my blog had posted, I emailed Arthur to tell him about it, and he responded by saying:   Hi Max, thank you for the mention in your great blog. With this kind of control it becomes feasible to deliver a lot of stuff by drone. Engine and battery capabilities are still too weak for human flight, as far as I know, but I would not be too surprised if this does happen in the not-so-distant future as it would be very useful.   Well, you could blow me down with a feather because, shortly after I read Arthur's message, I received an email from Nathaniel Berman pointing me at this article and this video and asking if I'd heard that E-Volo's Semi-Autonomous Volocopter had successfully completed its first flight.   This film shows the prototype 2-seater VC200 and product concepts based on the Volocopter platform. Now, if you've only ever flown one of the smaller, simpler drones, you may feel a tad wary with respect to trusting your precious body in a larger version. My first drone-flying experience didn’t end so well to the extent that the little scamp disappeared into the distance, never to be seen again.   But things are changing so fast in this area -- the combination of extremely accurate sensors and sophisticated control algorithms removes much of the complexity involved in flying these little beauties. One of the guys in my office has a DJI Phantom 3 Standard Quadcopter . He says you can fly it to a particular location in 3D space, take your hands off the controls, and it will remain exactly where you left it, even in gusting winds.   Similar technology involving myriad sensors and networked microprocessors in the VC200 means that the pilot can use very simple controls to express his or her desires, and the processors do all of the hard work to control the 18 rotors in such a way as to achieve rock-steady realization of the pilot's wishes. If you take your hands away from the controls, the VC200 maintains its current position as if it were "pegged to the sky."   Now, I have to admit that the 2-seater VC200 does look very, very tasty. For myself, however, I would LOVE one of the 1-seater VC100s, which also makes an appearance in the above video. I can so imagine myself flying to work in the morning...

The trillion-sensor world is not likely to take over anytime soon.   Bernie Cole recently reported that GE, Cisco, and others predict that, by the end of the decade, about 1 trillion sensors will be deployed and connected to the Internet, with a market value of $15 trillion. This is part of the so-called Internet of Things.   (Daily we're faced with ridiculous IoT hype as if this were some new concept. Has everyone forgotten the notion of "embedded systems"? For about 20 years, we've been building devices with sensors that connect to the Internet; before that, they were hooked up to a variety of ad hoc networks. The IoT is a new marketing buzzword and nothing more.)   Charles Manning, an email correspondent, applied a bit of engineering analysis to the notion of a trillion sensors. I've scoffed at the 1 trillion number for some time, and now, expanding on Charles' thinking, I am even more convinced that this is all some marketing person's pipe dream.   The web page for the TSensors Summits claims that about 10 billion sensors (or something like that; the wording is unclear) were sold in 2013. So it seems a median of 200 billion will be sold each of the next five years to reach the 1 trillion number.   (Source: Motherboard )   Does it seem likely that we'll see a jump in shipments from 10 billion a year to 200 billion in the next 12 months? Not really. So presumably the final year of this decade will show the bulk of sales, with far more than 200 billion pushed out the door that year. If shipments double every year, then the aggregate sum of devices will be a bit more than 1 trillion, with about 470 billion shipped in 2019 alone.   According to a Global Issues article titled " Poverty Around the World ," about half the people in the world live on less than $2.50 a day. Fully 80% squeak by on less than $10 a day. It's hard to imagine buying sensors instead of food. If the 20% with money represent the market, then 1.6 billion of the expected 8 billion people in the world in 2020 will be buying these devices. Per capita, that's 300 Internet-connected devices each in 2019 alone. How many e-gadgets did you buy last year?   What about IP addresses? Only 4% of today's connections use IPv6; 96% are on IPv4, which can accommodate only 4 billion devices.What about IP addresses? Only 4% of today’s connections use IPv6; 96% are on IPv4, which can accommodate only 4B devices. Of course, with the Dynamic Host Configuration Protocol (DHCP), network address translation (NAT), and other fixes some space can be recovered, but most addresses have been allocated. So the 1T sensor world will require an immediate and massive switch to the new IP system, which isn’t supported by most routers today. The $15T valuation of these devices represents 4% of the cumulative world GDP over the rest of the decade. It’s hard to make sense of this number. World semiconductor shipments are around $350B today, so the ICs in these gadgets will be just 2% of the value chain, unless the IoT boom makes the semiconductor industry explode. Maybe we should run out and buy stock in ARM! A device like a mobile phone has a lot of sensors, and, happily, each sensor does not have its own IP address. But the reason there are so many is that they cost nothing. A MEMs device is pennies in the enormous quantities used. So how can they contribute much to the $15T number? For decades one truism has been that electronics costs decline at a staggering rate. A transistor, CPU, or MEMs device that costs a buck today will sell for a penny tomorrow. $15T is a mouth-watering figure to a venture capitalist or CEO. Figure on seeing a lot of startups...and tons of bankruptcies. Sure, the semiconductor/IoT/device market will continue to grow, but these numbers veer into absurdity. Meanwhile, we engineers will be quietly building these devices - and much more. What’s your take on the IoT and a trillion sensors?

Sensors form the edge of the electronics ecosystem, in which the physical world interacts with computers, thereby providing a rich array of data to be available at a click of a mouse. We have had sensors, actuators and RFID tags around for a couple of decades now which has made our lives easier to a great extent. From identification and tracking of objects while managing inventory to even the miniscule sensors present in our cell phones, gaming consoles and automobiles, Sensors have become quite ubiquitous. With the “Internet of Things” era being ushered in, the potential of sensors have grown multi-fold. The Internet of Things (IoT) is the networked interconnection of objects through identifiers such as sensors, RFID tags and IP addresses. The Internet of Things aims to interconnect all things around us and ensure intelligence. There are several reasons why the IoT has become the flavor of the day; Internet Protocol Version 6 extended the number of unique Internet addresses making it possible for trillions of objects to connect to the net. This along with the ascent of cloud computing and the depreciating cost of sensors, have contributed to making the world a much connected and smaller place to live in. Some of the standard sensors include movement (via accelerometer), sound, light, electric potential (via potentiometer), temperature, moisture, location (via GPS), heart rate, GSR (galvanic skin response/ conductivity) and more. These sensors are included in a variety of devices and solutions. The trend is moving towards multi-sensor platforms that incorporate several sensing elements. Here is a look at how sensors are relevant in our day-to-day life: Sensor and Medical Electronics: Advanced development in sensors has enabled the design of miniature, cost effective smart medical devices. Medical professionals today require real-time, reliable and accurate diagnostic results which are provided by devices that are available either at hospitals or with patients at home being monitored remotely. There are developers constantly working towards incorporating sensors into the lives of patients which can capture both beneficial and detrimental health factors. Imagine physiological data being collected without your realization. Sensors embedded in the floor mat can measure your weight and gait; an arm patch can detect heart rate, blood pressure and blood sugar, while sensors in your toothbrush can detect cavities that would require attention or early signs of ulcer. Though these examples seem surreal, there are several of these sensor embedded devices already available in the market. The medical sensors in wearable devices are being used to build applications which can detect panic or medical emergency and which will notify friends, family or emergency services for help. Approved in 2011, digestible sensor is another interesting development in healthcare. A digestible sensor is a sensor (similar to a pill) that transmits information about a patient to medical professionals to help them customize the care to the individual. Digestible sensors will monitor your bodily systems and wirelessly transmit what’s happening in your body to another device like your smartphone or computer for your own review or the review of your doctor. With the advent of IoT, health records are getting networked and vital information can be made available to patients and his/her practitioner at any point of time and location. The various sensors that find application in healthcare include pressure, temperature, chemical flow, level, position and image and biosensors.   Sensors and Home Automation: Smart buildings or homes are now the order of the day for those looking at convenience, security and a green environment. Networked homes automatically dim or turn off lights when people leave and adjust energy use based on physical presence. Such networked homes depend on a network of sensors to determine people’s usage of resources along with environmental factors like temperature, humidity and the time of the day. One of the most popular use of sensor technologies is the motion detector. These sensors can sense when there are people entering or leaving the room. The benefits are two-fold – to switch lights on and off when entering or leaving a room or to trigger a burglar alarm when the house is empty. Light sensors or photosensors as they are commonly called monitors ambient light levels and reports them back to the automation controller. These are used in conjunction with motion sensors to switch lights on automatically when someone enters a room. They can be also used to ensure few lights only operate after dark. Temperature sensors are usually embedded into a thermostat unit or radiator actuator valve, but there are sensors that can be easily embedded into walls as well. Combined with a humidity sensor, these sensors can be used to automatically control air conditioners or de-humidifiers or even to control windows (automatically open or shut).   Sensors and Industrial Automation Sensors play a very important role in the Industrial automation segment by making products or systems highly intelligent and automatic. This allows one to detect, analyze, measure and process various changes occurring in the system. These sensors also play an important role in predicting and preventing future events. The type of sensors used in Industrial automation include proximity sensor, vision sensors, ultrasonic sensors, position sensors, photoelectric sensors, temperature sensors, inclination sensors etc. At the heart of industrial automation is a new generation of advanced intelligent sensors and motor drives which are connected through low-latency and real time networks to high performance performance programmable logic controllers (PLC) and Human-Machine Interface (HMI) systems. In order to be beneficial, sensors must be fast and reliable to be able to monitor or measure conditions in a fast paced industrial environment. The network should then be able to communicate this information with minimum latency and interruptions to ensure response in real time.   Sensors and Wearable Electronics: A few years ago, it was difficult to integrate sensors with wearables because of the size of the sensors. With the advent of miniaturized, high-quality sensors, wearables can now be easily deployed for gathering physiological and movement data (gesture and voice recognition). Most wearables use multiple sensors that are typically integrated into sensor networks. In the case of body-worn sensors for medical purposes, data can be gathered and uploaded to a remote site such as a hospital server. Sensors in wearables allow continuous physiological monitoring with reduced manual intervention and at a low cost. The explosion in Internet-connected sensors means that new classes of technical capability and application are being created. Seeing how sensors have progressed in the last decade, it is exciting to think of the new sensing capabilities that will become widely available in the future. Authored by: Sachidananda Karanth, Lead Architect, Mistral Solutions

    Is this wise? What happens if the hardware doesn't support the algorithm? Well, I suppose that could happen but only if I completely misunderstood the nature and function of the hardware. Fortunately, that's never happened to me. But wait, you say. I thought you were advocating doing device drivers first. I was, and am. That's where the outside-in, as opposed to top-down or bottom-up, development comes in. I wasn't lying about avoiding the hardware as long as possible. I also wasn't lying about wanting to be sure the I/O devices are working and that I have good, robust device drivers to interface with them. I need both. I need to know the hardware—particularly the sensors and actuators—works. I'll be testing them using standalone test software, the moment the devices are available. But I don't test the hardware by running my entire application on top of it. Instead, I write simple little test programs to verify that (a) the hardware works and that (b) I know how to talk to it. Then I can get back to developing my other software, confident that I can marry it to the real hardware when the time comes. Code and unit test Ok, let's assume I've found an environment that allows frequent testing, with an edit-compile-test cycle measured in seconds. I've got my software architecture designed, I've identified a unit (subroutine, function, module, or whatever you choose to call it), to start with, and I'm ready to begin coding. When do I start testing? If you've gotten the point of this series at all, you already know the answer: I start now. In the classical, waterfall-diagram approach to software, there's a phase called "code and unit test." In the original concept, you're supposed to build a given unit until it's complete. Then you test it and move on to the next unit. That's not the way we do it anymore. I've told you that I tend to test as I go, testing each time I've added a handful of lines of code. What I haven't said is, test it how? Answer: Using a test driver. As far as I'm concerned, there is no other option. I worked with one group developing a huge application, so big and slow it took multiple processors, each having multiple cores, to run it. And yet, the only way programmers had to test their functions was to load it into the big Mother of All Programs, run that big mother, and set a breakpoint where their function got called the first time. That's insane. End of discussion. What's that you say? You can't test each unit individually, because they all depend on each other and pass data items around among them? You're actually admitting that you write spaghetti code? Sounds to me like time to do some major refactoring. I submit that if you can't separate one module from its neighbors, you also can't tell if any of them are actually working. So I'm going to write a test driver that I develop along with the unit under test (UUT). I'll do this for every unit, and every collection of units, right up through the final, main program. Each test driver is going to invoke the UUT, pass some data to it, and test it. What should the first version look like? Since my initial function has no executable lines of code in it, the test is going to be pretty doggone simple. It's a stub of both the UUT and its test driver—which is why I'm perfectly comfortable with starting with the null program void main(void){} . The test driver calls no function at all. If you feel uncomfortable about this, you can always write the universal test-driver/UUT pair: void foo(){}    // function prototype void main(void)    //main program {     foo( ); } My next step, of course, is to flesh out the UUT, sending data to it from the test driver, and checking the data it returns. The next obvious question is, what data do I use, and how do I know if the UUT got the right result? The test case(s) Answer: I must generate test case(s). Good ones. I can't tell you how many times I've seen otherwise good programmers try to slide on this point. Generating a good test case is not always easy. Some folks seem to just pull some input values out of the air, look at the results, and say, "Yep, that looks about right." Give me a break! You can't do that! What does "about right" even mean, anyhow? In the worst case, it simply means your module compiled and ran without crashing, and gave a number that wasn't ridiculous. But come on, you'll have to do better than that. My pal Jim Adams, one of the best software engineers I know, puts it this way: When testing, never ask a computer a question unless you already know the answer. The test case should be reasonable, in the sense that the inputs should be in the same range as the values expected in the real world. More to the point, the test case should include every computation, not just those that lead to output values. In the old days, we used to call this a "hand check." I still do, because this is exactly how I use the test. As I'm testing, I check the value generated by every single instruction, and compare it to my hand check. They have to agree. Now, when I say "agree," I don't just mean "looks reasonable." I mean agree, as in, the numbers should match exactly, within the limits of floating point arithmetic. Anything greater than this, and we need to go track down the source of the discrepancy. Do not pass "go" until the questions are resolved. In olden times, I was sometimes pretty cavalier in the lower-level testing. I wouldn't write things down, I'd just think up some input data on the fly, then I'd check the output. If I were writing, say, a vector add routine, I might add the two vectors and . Not very imaginative, but if the answer was , I'd declare success. It's hard to imagine a way that any function could get that answer, without adding the numbers and getting their sums right. For the record, you needn't worry about making your input numbers seem more "realistic." You can trust your math processor to get the floating point arithmetic right. If it can add 2.0 and 3.0, we have to believe it can add 1.41421356 and 1.61803399. The one exception occurs when your algorithm is limited to a range of values. Sometimes algorithms fail at edge conditions. The square root function, for example, can't accept negative numbers. The arcsine function can't accept inputs outside the range –1..+1. The operation 1/x fails when x = 0 . When testing, it's absolutely essential that you test these edge conditions, with values at the edge, and also just inside and just outside it. Especially in embedded software, bouncing out on an unhandled exception is not an option. Sometimes people tell me that they can't really test such edges in their program, because the edges are down inside the UUT, and they can't compute what values of the inputs correspond to an internal edge condition. In that case, someone has some refactoring to do. We still have to test the edges—all of them. When I was testing, I at least should have written down the test case inputs I used. I didn't. Now I do. As Jim Adams has pointed out, if I don't document the test case, either in my databook or a test report, I'm doomed to re-invent it. And since by that time, I'm likely to have forgotten the subtleties of the algorithm, I'm more likely to get the test driver wrong. On the other hand, I don't want to make the test drivera my life's work. For the lowest-level UUTs—as low as a square root function—I can't afford to waste the time writing a test plan, a test report, and everything that goes in between. Between Jim and I, we've worked out an approach that documents the test cases and their results, without causing undue paperwork. We'll write a test driver that passes test case data (which includes edge-condition values) to the UUT. It evaluates the results, and reports any failures. It does not report successes. It's the very opposite of "verbose." Under normal conditions, you don't want to see line after line of output that goes: Testing case 1 Case 1 passed Testing case 2 Case 2 passed etc. In this case, no news is good news. A null output means that the UUT passed its tests. This approach also allows one level of test driver to call others, with no verbosity in between. How does the test driver report failure? I usually take the coward's way out and use the C/C++ mechanism, assert( ) . You can choose a more sophisticated mechanism. You might choose to have the test driver report each failure, then move on to the next test. This approach may seem more sophisticated, but I'm not convinced it's better. A failure is a failure is a failure, and the first one calls for it to be fixed before continuing. In the end, the test drivers go into the project library. They get archived and kept under version control right along with the UUTs. You can collect all the test drivers into a parent driver, which becomes a permanent regression test driver. Generating the test cases We still haven't discussed the nature of the test cases, and where the test case data comes from. We've only established that it should exist, and be comprehensive. This is where the discussion starts to really get interesting. Hold that thought for next time.  

    Is this wise? What happens if the hardware doesn't support the algorithm? Well, I suppose that could happen but only if I completely misunderstood the nature and function of the hardware. Fortunately, that's never happened to me. But wait, you say. I thought you were advocating doing device drivers first. I was, and am. That's where the outside-in, as opposed to top-down or bottom-up, development comes in. I wasn't lying about avoiding the hardware as long as possible. I also wasn't lying about wanting to be sure the I/O devices are working and that I have good, robust device drivers to interface with them. I need both. I need to know the hardware—particularly the sensors and actuators—works. I'll be testing them using standalone test software, the moment the devices are available. But I don't test the hardware by running my entire application on top of it. Instead, I write simple little test programs to verify that (a) the hardware works and that (b) I know how to talk to it. Then I can get back to developing my other software, confident that I can marry it to the real hardware when the time comes. Code and unit test Ok, let's assume I've found an environment that allows frequent testing, with an edit-compile-test cycle measured in seconds. I've got my software architecture designed, I've identified a unit (subroutine, function, module, or whatever you choose to call it), to start with, and I'm ready to begin coding. When do I start testing? If you've gotten the point of this series at all, you already know the answer: I start now. In the classical, waterfall-diagram approach to software, there's a phase called "code and unit test." In the original concept, you're supposed to build a given unit until it's complete. Then you test it and move on to the next unit. That's not the way we do it anymore. I've told you that I tend to test as I go, testing each time I've added a handful of lines of code. What I haven't said is, test it how? Answer: Using a test driver. As far as I'm concerned, there is no other option. I worked with one group developing a huge application, so big and slow it took multiple processors, each having multiple cores, to run it. And yet, the only way programmers had to test their functions was to load it into the big Mother of All Programs, run that big mother, and set a breakpoint where their function got called the first time. That's insane. End of discussion. What's that you say? You can't test each unit individually, because they all depend on each other and pass data items around among them? You're actually admitting that you write spaghetti code? Sounds to me like time to do some major refactoring. I submit that if you can't separate one module from its neighbors, you also can't tell if any of them are actually working. So I'm going to write a test driver that I develop along with the unit under test (UUT). I'll do this for every unit, and every collection of units, right up through the final, main program. Each test driver is going to invoke the UUT, pass some data to it, and test it. What should the first version look like? Since my initial function has no executable lines of code in it, the test is going to be pretty doggone simple. It's a stub of both the UUT and its test driver—which is why I'm perfectly comfortable with starting with the null program void main(void){} . The test driver calls no function at all. If you feel uncomfortable about this, you can always write the universal test-driver/UUT pair: void foo(){}    // function prototype void main(void)    //main program {     foo( ); } My next step, of course, is to flesh out the UUT, sending data to it from the test driver, and checking the data it returns. The next obvious question is, what data do I use, and how do I know if the UUT got the right result? The test case(s) Answer: I must generate test case(s). Good ones. I can't tell you how many times I've seen otherwise good programmers try to slide on this point. Generating a good test case is not always easy. Some folks seem to just pull some input values out of the air, look at the results, and say, "Yep, that looks about right." Give me a break! You can't do that! What does "about right" even mean, anyhow? In the worst case, it simply means your module compiled and ran without crashing, and gave a number that wasn't ridiculous. But come on, you'll have to do better than that. My pal Jim Adams, one of the best software engineers I know, puts it this way: When testing, never ask a computer a question unless you already know the answer. The test case should be reasonable, in the sense that the inputs should be in the same range as the values expected in the real world. More to the point, the test case should include every computation, not just those that lead to output values. In the old days, we used to call this a "hand check." I still do, because this is exactly how I use the test. As I'm testing, I check the value generated by every single instruction, and compare it to my hand check. They have to agree. Now, when I say "agree," I don't just mean "looks reasonable." I mean agree, as in, the numbers should match exactly, within the limits of floating point arithmetic. Anything greater than this, and we need to go track down the source of the discrepancy. Do not pass "go" until the questions are resolved. In olden times, I was sometimes pretty cavalier in the lower-level testing. I wouldn't write things down, I'd just think up some input data on the fly, then I'd check the output. If I were writing, say, a vector add routine, I might add the two vectors and . Not very imaginative, but if the answer was , I'd declare success. It's hard to imagine a way that any function could get that answer, without adding the numbers and getting their sums right. For the record, you needn't worry about making your input numbers seem more "realistic." You can trust your math processor to get the floating point arithmetic right. If it can add 2.0 and 3.0, we have to believe it can add 1.41421356 and 1.61803399. The one exception occurs when your algorithm is limited to a range of values. Sometimes algorithms fail at edge conditions. The square root function, for example, can't accept negative numbers. The arcsine function can't accept inputs outside the range –1..+1. The operation 1/x fails when x = 0 . When testing, it's absolutely essential that you test these edge conditions, with values at the edge, and also just inside and just outside it. Especially in embedded software, bouncing out on an unhandled exception is not an option. Sometimes people tell me that they can't really test such edges in their program, because the edges are down inside the UUT, and they can't compute what values of the inputs correspond to an internal edge condition. In that case, someone has some refactoring to do. We still have to test the edges—all of them. When I was testing, I at least should have written down the test case inputs I used. I didn't. Now I do. As Jim Adams has pointed out, if I don't document the test case, either in my databook or a test report, I'm doomed to re-invent it. And since by that time, I'm likely to have forgotten the subtleties of the algorithm, I'm more likely to get the test driver wrong. On the other hand, I don't want to make the test drivera my life's work. For the lowest-level UUTs—as low as a square root function—I can't afford to waste the time writing a test plan, a test report, and everything that goes in between. Between Jim and I, we've worked out an approach that documents the test cases and their results, without causing undue paperwork. We'll write a test driver that passes test case data (which includes edge-condition values) to the UUT. It evaluates the results, and reports any failures. It does not report successes. It's the very opposite of "verbose." Under normal conditions, you don't want to see line after line of output that goes: Testing case 1 Case 1 passed Testing case 2 Case 2 passed etc. In this case, no news is good news. A null output means that the UUT passed its tests. This approach also allows one level of test driver to call others, with no verbosity in between. How does the test driver report failure? I usually take the coward's way out and use the C/C++ mechanism, assert( ) . You can choose a more sophisticated mechanism. You might choose to have the test driver report each failure, then move on to the next test. This approach may seem more sophisticated, but I'm not convinced it's better. A failure is a failure is a failure, and the first one calls for it to be fixed before continuing. In the end, the test drivers go into the project library. They get archived and kept under version control right along with the UUTs. You can collect all the test drivers into a parent driver, which becomes a permanent regression test driver. Generating the test cases We still haven't discussed the nature of the test cases, and where the test case data comes from. We've only established that it should exist, and be comprehensive. This is where the discussion starts to really get interesting. Hold that thought for next time.