Chris Maunder - Professional Profile
|We're in the thick of it[^] now.
Team 1 have gone an interesting direction and are looking at including an alcohol sensor in their solution. To me this is a good idea in theory, but won't work in practice.
Team 1 also made the statement that they only need short distance (100m). However, they may need to consider that two cars each doing 120kmh-1 will close a 100m gap in 1.5 seconds. If there's an emergency situation that needs action then, given mass and momentum, 1.5 seconds isn't going to buy you anything.
- it's a little Big Brother. I don't want to send my breathe alcohol (and it's breath, not blood) settings to an unknown company.
- It's inaccurate unless it's setup properly (ie user has to blow for a proscribed period into a tube). Otherwise it could pick up alcohol from passengers
- it misses the point. The point being that distracted driving now kills more than drunk driving, and fatigue is right up there too. Instead of a seemingly easy solution that's doomed to fail, why not get smart and add some driver heuristics that will detect not only drunk, but distracted, fatigued, and drivers under the influence of drugs. Steering variability, braking patterns, speed. Things that trigger alarms.
100m just isn't going to cut it I'm afraid - not for highway speeds at least.
As an aside: I love code samples. I love, even more, comments in code samples that explain what's happening.
void sensor_trig_HCSR04l(int pin)
LPC_GPIO2->FIOPIN &= ~(1 << pin);
LPC_GPIO2->FIOPIN |= (1 << pin);
LPC_GPIO2->FIOPIN &= ~(1 << pin);
left_start_time = lpc_timer_get_value(lpc_timer0);
Just not sure what's happening here...
Team 2 have some tangible goodness for those working with Curie: "Zephyr is destined to be the operating system of choice for the forthcoming Curie SDK...The only problem is that the documentation on the Zephyr project website is outdated and inconsistent". So they put together a guide to Zephyrizing the Curie. Awesome guys.
As a further aside Team 2 have posted a comment on the fundamental issue in IoT: Security. I am really, really hoping Team 1 focus on this, given that they are writing in C and are trying to control 2 tons of speeding death. Team 2 is building their stuff from the ground up to ensure things are secure. Read this and be worried.
The golden rule is to not try and build your own security. The fact that Team 2 needs to speaks volumes.
As another aside: if you've ever wondered how you write a system that will integrate multiple devices (some using Bluetooth, for instance) then follow their work on Iotivity. It's fascinating, and their discussion on basic Iotivity “Servlet” processing is brilliant.
Team 3 are continuing their work with MQTT to act as their pub/sub framework. Some good, commented code samples. As I said: I love a good code sample.
Team 3 have also posted some great tips for those looking to use Intel Curie boards in the Arduino IDE. Some tips in case you're having problems uploading skethes to your board.
Team 4 are fighting boards and sensors and APIs. And Zephyr. However, they've settled on using Apache Mynewt as their OS for their bluetooth smartcart system. It's all there, including a handy Docker container to get them going.
...and finally Team 5. Team 5 are getting down and dirty with the Arduino IDE on Linux with a handy step-by-step guide to getting you started. They then have to deal with some machanics: FFmpeg for getting their crop images to their gateway
One thing I was thinking about Team 5's efforts: they are reliant on fixed camara installations to detect crop issues. I'm fairly certain crop issues aren't going to conveniently pose in front of the limited number of fixed cameras, so why not make the cameras mobile? A fairly straightforward app to control a drone that would fly a course and take representative shots of a crop (flying on when the weather service says the conditions are OK) would require less hardware and provide greater coverage. And be way more cool.
Frankly I am concerned that IoT, as pushed by some pundits, is missing the point. We've had connected devices forever. The differences now are
So can I suggest that we step back a little and give equal focus to security and privacy. It's important.
- the devices are super cheap and there are tons of consumer-ready versions
- They are connected to via internet gateways for (potentially) all to see
- we're now using them to lock our houses, control our webcams and furnaces, and collect our biometric data
General News Suggestion Question Bug Answer Joke Praise Rant Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.