Downloaded 112 times
Uploaded byDataWorks Summit
Real-Time Robot Predictive Maintenance in Action
This document describes a predictive maintenance system for robots using real-time sensor data. A team of 4 engineers built a solution in 2 months using standard open source software like H2O and MapR. Sensors on a robot collected accelerometer, gyroscope and other data. This raw data was analyzed using anomaly detection algorithms in H2O to build a machine learning model that identified normal vs abnormal robot states. The model was deployed as a microservice to make real-time predictions on new sensor data and detect potential failures. The solution was able to analyze data from hundreds of robots and identify anomalies within 3 seconds, demonstrating an effective low-cost predictive maintenance system.
More Related Content
Similar to Real-Time Robot Predictive Maintenance in Action
More from DataWorks Summit
Real-Time Robot Predictive Maintenance in Action
- 1. © 2017 MapRTechnologiesMapR Confidential 1 State of the Art Robot Predictive Maintenance with Real-time Sensor Data Mateusz Dymczyk, Software Engineer @ h2o.ai Mathieu Dumoulin, Data Engineer @ MapR DataWorks Summit Sydney 2017
- 2. © 2017 MapRTechnologies 2 Mathieu Dumoulin • Data Engineer, MapR Technologies • From Montreal, Canada • Living in Tokyo, Japan for last 3 years • Previous experience as data scientist, search engineer and data engineer.
- 3. © 2017 MapRTechnologies Industry 4.0 is Now source: PwC 2016 Global Industry 4.0 Survey • End-to-end factory digitization • 907B$/y investment until 2020 • Japan and Germany early leaders • Smart sensors everywhere • Refine products based on advanced data analysis
- 4. © 2017 MapRTechnologies 4 Predictive Maintenance: Lower Cost, Greater Efficiency • Less unplanned downtime • Just-in-time order of rare/expensive parts • Less inspection downtime • Increased operational efficiency
- 5. © 2017 MapRTechnologies 5 Requirements for a Predictive Maintenance System Create Business Value! • Limited time, budget and people • Don’t impact normal operation • Ok to miss failure sometimes • “Perfect” is the enemy of the “good enough” • Improve the model over time
- 6. © 2017 MapRTechnologies 6 Requirement: Know Robot State in 3 sec or less
- 7. © 2017 MapRTechnologies 7 Requirement: Scale to 100’s of Robots Tesla Factory photo by Paul Sakuma/AP
- 8. © 2017 MapRTechnologies 8 Requirement: Low R&D Cost - Use Standard OSS
- 9. © 2017 MapRTechnologies 9 We Made It! • 4 Engineers, 2 Months (part-time) • Real-time Anomaly Detection • Scalable by default • Standard Big Data software • Minimized custom code • Streaming Architecture • Prediction Microservice
- 10. © 2017 MapRTechnologies 10 Video of solution in action 2m
- 11. © 2017 MapRTechnologies 11 How We Made it • A clear goal: Real-time anomaly detection using data from sensor on a robot • Small team of 4 Engineers • Existing hardware • A Robot – Wireless sensor LPMS-B2 – Augmented Reality (AR) headset • Existing expertise – Machine Learning – Enterprise big data – Sensor and AR hardware • No additional dependencies
- 12. © 2017 MapRTechnologies 12 Data Source: LPMS-B2 Measurement Unit • Bluetooth wireless • Lots of sensors: – 3-axis gyroscope – 3-axis accelerometer – 3-axis magnetometer – temperature, pressure and humidity • Very noisy data
- 13. © 2017 MapRTechnologies 13 Demo Pipeline
- 14. © 2017 MapRTechnologies 14 Demo Pipeline – Normal State
- 15. © 2017 MapRTechnologies 15 Demo Pipeline – Anomaly State
- 16. © 2017 MapRTechnologies 16 Machine Learning
- 17. © 2017 MapRTechnologiesMapR Confidential 17 Machine Learning Project Flow Explore and Analyze Choose Algorithm Build Model Evaluate Model Put into production Problem evaluation & definition Data preparation
- 18. © 2017 MapRTechnologies 18 Problem definition 1. Problem: 1. Automatically deduce data patterns describing the normal state of a machine 2. Create a model classifying machine’s current state (normal/pre-failure) 2. Machine Learning goal/metrics: 1. Detect abnormal events > 90% accuracy 2. Avoid false positives 3. Decide output Normal State (OK!) PREDICT FAILURE
- 19. © 2017 MapRTechnologies 19 Data preparation 1. Choose (after consultation with hardware engineers) only linear acceleration data (X, Y, Z) 2. “Window” (concatenate into single record) data from 200ms worth of records 200ms window Ref: 21 Great Articles and Tutorials on Time Series
- 20. © 2017 MapRTechnologies 20 Algorithm selection • Unlabeled data -> unsupervised learning • Training data consists only of data during “normal state” runs – Only train on normal op. data • Conclusion: anomaly detection • Possible algorithms: • Simple auto encoders • LSTM auto encoders • KNN, Local Outlier Factor Anomaly Detection Get Ted Dunning’s Anomaly Dectection Book Anomaly!
- 21. © 2017 MapRTechnologies 21 ML – Anomaly Detection • Unsupervised • Anomaly detection • H2O uses autoencoder algorithm (deep learning) • H2O’s R API for modeling • Very productive API • Good graphs • Parameter tuning of models • See H2O’s training-book on GitHub
- 22. © 2017 MapRTechnologiesMapR Confidential Anomaly detection with Autoencoders • 1 • 2 • 3 • 4 • 5
- 23. © 2017 MapRTechnologies 23 Tooling
- 24. © 2017 MapRTechnologies 24 Training the Model
- 25. © 2017 MapRTechnologies 25 ML – Results Note: Time window: 200ms, Threshold: 1SD
- 26. © 2017 MapRTechnologies 26 H2O - production 1. H2O REST endpoint 1. Out-of-the-box after modeling 2. Great for testing 3. Slow for production 2. Deployable WAR 1. Easy to deploy if an application server is running 2. Requires H2O.ai’s Steam 3. POJO/MOJO 1. Pure Java classes/serialized objects 2. Fast 3. Very easy to use
- 27. © 2017 MapRTechnologies 27 Deploy to Production: How to Make Real-time Predictions
- 28. © 2017 MapRTechnologies 28 Real-time Predictions
- 29. © 2017 MapRTechnologiesMapR Confidential 29 Real-time Predictions - Multiple Outputs
- 30. © 2017 MapRTechnologiesMapR Confidential 30 Real-time Predictions – Scale Up
- 31. © 2017 MapRTechnologies 31 Conclusion: You Can Do it Too!
- 32. © 2017 MapRTechnologies 32 • OSS enterprise big data software is much better than custom, closed source systems for next gen AI applications • Don’t get stuck on Machine Learning complexity • Converged Platforms reduce complexity (MapR) Predictive Maintenance is Real and it’s Now Poster by J. Howard Miller (1943)
- 33. © 2017 MapRTechnologies 33 Q&A ENGAGE WITH US mateusz@h2o.ai mathieu.dumoulin@mapr.com PROJECT GITHUB: github.com/mdymczyk/iot-pipeline Our thanks to: LP RESEARCH www.lp-research.com contact: Klaus Peterson klaus@lp-research.com
- 34. © 2017 MapRTechnologies 34 Thank you to LP-RESEARCH! Hardware design and production Expertise in Motion sensors Gyroscope Accelerometer Magnetometer Sensor fusion algorithm development Multi-platform application development See all our products: https://www.lp-research.com/products/ LPMS-B2 LPMS-CU2 LPMS-CANAL2 LPMS-USBAL2OEM also available!
Editor's Notes
- #4 Industry 4.0 is all about digitization of the factory. Sensors everywhere. All this data makes possible new opportunities for automation, cost savings, higher productivity and higher quality. Our talk will focus on Data & Analytics for improving the efficiency of operations of factories with lots of industrial robots. We combine Smart sensors, DB Analytics (ML), Cloud computing and AR to power a real-world, state of the art predictive analytics system.
- #5 Predictive Maintenance generates value from the following
- #6 Requirements for such a system start with a clear view of business value before any work is done. Need to have an image of the impact of a successful system on the business.
- #7 Based on known real-world requirement of state of the art Japanese car-parts manufacturers.
- #8 Scale with number of sensors, robots and factories. GB a day quickly become many GB per hour or even minutes. This is comfortably on moderate sized clusters (5-25 nodes) using current big data platforms used by attendees of Strata.
- #9 Standard big data OSS has come a long way over the past 5 years and is now at a point where a state of the art project like this can be constructed by judicious assembly of projects: Distributed storage Distributed streaming Distributed stream processing Distributed machine learning
- #14 ありがとうございました もう少し、デモについて詳しく説明します。 ロボットに動作検知をするためのセンサーがついています。 センサーはマシンの振動（しんどう）やノイズを検知しています。 このデータは Raspberry Pi に無線で送信されます。 Raspberry Pi がデータを収集して、MapRに送信します。 アナリティカルパートでモデルを作ります。 オペレーショナルなパートで作成したモデルで、robotの状態を可視化システムでoperatorがreal-timeで監視できます。 これは先ほどお話しした通りですね。
- #15 異常がない場合、ご覧いただいた通り緑のマークが表示されます。
- #16 異常がある場合は、赤いマークが表示されます。 その後、フレンドリーなジャーマニーエンジニアを呼ぶ必要があるとわかります。
- #18 What do we even want?! I.E.: Data gathering Feature selection, extraction, engineering and data transformation 3) Pick all potential algorithms 4) Build a model using your library/tool of choice 5) Evaluate according to previously defined metrics 6) If not good enough then either try a different approach, features or method parameters 7) Otherwise extract the model and put it into production!
- #19 Mention why we are doing it with machine learning at all! No rules, automatically learn the best parameters for each application without new coding and not based on supervised techniques. Especially good when we don’t know what we are looking for: machines can break in a variety of ways.
- #20 Mention why we are doing it with machine learning at all! No rules, automatically learn the best parameters for each application without new coding and not based on supervised techniques. Especially good when we don’t know what we are looking for: machines can break in a variety of ways.
- #21 Mention why we are doing it with machine learning at all! No rules, automatically learn the best parameters for each application without new coding and not based on supervised techniques. Especially good when we don’t know what we are looking for: machines can break in a variety of ways. Peeking: ML modeling mistake where some data is used to train a model includes information about the answer
- #22 教師なし学習 => unsupervised learning 異常認識 => anomaly detection The real data is very noisy Why use ML at all? We don’t want to use rules for every type of robot and every situation Don’t mention threshold, just say we did some parameter tuning of the ML algorithms or something /
- #23 Keep?
- #24 Mention why we are doing it with machine learning at all! No rules, automatically learn the best parameters for each application without new coding and not based on supervised techniques. Especially good when we don’t know what we are looking for: machines can break in a variety of ways.
- #26 閾値 (shiki-ichi) => threshold 標準偏差 (hyoujun-hensa) => SD
- #27 Mention why we are doing it with machine learning at all! No rules, automatically learn the best parameters for each application without new coding and not based on supervised techniques. Especially good when we don’t know what we are looking for: machines can break in a variety of ways.
- #33 Amazing evolution in last few years Lots of learning material, Experts are out there A minimal working model is easy to make (H2O) Get more value: Improve it over time Contract with experts as needed Only one cluster, little configuration, ”it just works”