Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This page is part of the Lifecycle Management with Edge Impulse tutorial series. If you haven't read the introduction yet, we recommend you to do so here.
In this tutorial, we'll guide you through deploying updated impulses over-the-air (OTA) to Arduino using Edge Impulse. We'll build on Arduino firmware update workflow, incorporating Edge Impulse's API to check for updates and download the latest build.
Let's get started!
Edge Impulse Account: If you haven't got one, sign up here.
Trained Impulse: If you're new, follow our data acquisition and impulse design guides.
Here’s the complete C code for implementing OTA updates with Edge Impulse on ESP-EYE (ESP32).
A trained impulse in Edge Impulse Studio
Installation of required software as detailed in the tutorial
Begin by setting up your device for OTA updates following Espressif's OTA firmware update workflow. Use the built binary from the C++ example and modify it to incorporate OTA functionality.
Clone the example repository and adjust it according to your project and connectivity settings.
Modify the ESP OTA example server to check for updates to your project
Modify the Edge Impulse C++ example for ESP32 to check for updates to your project and download the latest build.
We will need to add a few libraries to the project to facilitate the OTA update process. These are taken from the ESP32 OTA example and are already included in the example project.
NVS is utilized to persistently store data like configuration settings, WiFi credentials, or firmware update times, ensuring retention across reboots.
This library facilitates HTTP requests to the server for checking and retrieving new firmware updates.
These headers aid in executing OTA operations, including writing new firmware to the flash and switching boot partitions.
FreeRTOS ensures OTA updates are conducted in a separate task, preventing blockage of other tasks and maintaining system operations during the update.
Compare the model's timestamp or hash with the stored version. If it's different or newer, call the download_model() function.
Monitor the device to ensure the new impulse performs as expected and repeat the update process as needed.
This tutorial provides a comprehensive guide for implementing OTA updates on Espressif ESP-EYE (ESP32) with Edge Impulse. Follow each step meticulously, ensuring all prerequisites and preparation steps are completed before proceeding to the deployment phase. Happy coding!
Note: Adjust the code snippets and steps to suit your specific requirements and always ensure to test thoroughly before deploying updates to live environments.
This page is part of the Lifecycle Management with Edge Impulse tutorial series. If you haven't read the introduction yet, we recommend you do so here.
In this tutorial, we'll guide you through deploying updated impulses over-the-air (OTA) to Arduino using the Arduino IoT Cloud and Edge Impulse.
Let's get started!
Edge Impulse Account: Sign up here.
Trained Impulse: If you're new, follow our data acquisition and impulse design guides.
Remote Update: Update your Arduino board firmware remotely.
Integration with Edge Impulse: Seamlessly incorporate machine learning models.
Here’s an example Arduino sketch for implementing OTA updates with Edge Impulse:
To expand the Arduino sketch to work with the Edge Impulse API, you'll need to add functionality to fetch the latest model updates from Edge Impulse and apply them to your device. Below is an extended version of the loop()
, connectToWiFi()
, and onOTAEvent()
functions, integrating Edge Impulse API interactions:
loop()
FunctionThe loop()
function regularly checks for updates from the Edge Impulse API.
connectToWiFi()
FunctionThe connectToWiFi()
function includes a maximum number of attempts to connect to WiFi.
onOTAEvent()
FunctionThe onOTAEvent()
function is triggered when a new update is available, downloading and applying the update.
This sketch sets up the Arduino to connect to the Arduino IoT Cloud and listens for OTA update notifications. When an OTA update is available, the onOTAEvent
function is called, where you can implement the logic to download and update the firmware.
Setup Arduino IoT Cloud: Configure your device and variables in the Arduino IoT Cloud.
Connect your device: Ensure your Arduino board is connected to the internet.
Integrate with Edge Impulse: Export your trained impulse from Edge Impulse as an Arduino library.
Update Sketch: Incorporate the Edge Impulse library into your Arduino sketch.
Listen for OTA Updates: Use the Arduino IoT Cloud to push OTA updates to your device.
Test and Monitor: After deploying the update, monitor your device's performance and ensure the new impulse is functioning correctly.
ArduinoIoTCloud: Manages cloud connectivity and OTA updates.
WiFiNINA: Handles WiFi connections for compatible boards.
This tutorial provides a basic guide for implementing OTA updates on Arduino boards using the Arduino IoT Cloud and integrating with Edge Impulse. Expand and develop this example to suit your project's needs. Remember, testing is crucial before deploying updates in a live environment. Happy coding!
This tutorial is part of the Lifecycle Management with Edge Impulse series. If you haven't read the introduction yet, we recommend doing so here.
We'll guide you through deploying updated machine learning models over-the-air (OTA) to the Nordic Thingy:53 using Edge Impulse. This process leverages the Nordic Thingy:53 app, allowing users to deploy firmware updates and facilitating on-device testing for Lifecycle Management.
User-initiated firmware deployment via the Nordic Thingy:53 app.
Remote data collection and on-device testing for machine learning models.
Seamless integration with Edge Impulse for Lifecycle Management.
Edge Impulse Account: Sign up if you don't have one here.
Trained Impulse: If you're new, follow one of our end-to-end tutorials
Nordic Thingy:53: Have the device ready and charged.
Nordic Thingy:53 App: Installed on your smartphone or tablet.
Begin by connecting your Nordic Thingy:53 to the Edge Impulse platform and setting it up for data collection and model deployment.
Connect your Nordic Thingy:53 to the Edge Impulse using the Nordic Thingy:53 app. This will be your interface for managing the device and deploying updates.
Use the Nordic Thingy:53 to collect relevant data for your machine learning application.
Upload this data to Edge Impulse and train your model.
Once your model is trained and ready, use the Nordic Thingy:53 app to deploy it to the device.
The app allows you to initiate the OTA update, which downloads and installs the latest firmware containing the new model.
Conduct remote testing through the app to evaluate the model's performance in real-world scenarios.
This step is crucial for validating the effectiveness of your machine learning model.
Continuously collect new data with the Nordic Thingy:53.
Re-train your model on Edge Impulse with this new data.
Deploy these updates to the Thingy:53 via the app, maintaining the cycle of Lifecycle Management.
This tutorial provides a straightforward approach to implementing OTA updates and Lifecycle Management on the Nordic Thingy:53 using Edge Impulse. The user-friendly Nordic Thingy:53 app facilitates easy deployment of firmware updates, making it ideal for rapid prototyping and iterative machine learning model development.
This guide helps users leverage the capabilities of the Nordic Thingy:53 for advanced IoT applications, ensuring devices are always updated with the latest intelligence and improvements.
Welcome to the tutorial series on OTA Model Updates with Edge Impulse Docker Deploy on Jetson Nano! In this series, we will explore how to update machine learning models over-the-air (OTA) using Edge Impulse and Docker on the Jetson Nano platform.
Before getting started, make sure you have the following prerequisites:
Jetson Nano Developer Kit
Docker installed on Jetson Nano
Edge Impulse account
Be familiar with Edge Impulse and Docker deploy
In this tutorial, we will explore how to enable GPU usage and use a camera with the Jetson Nano. We will then deploy a machine learning model using Edge Impulse and Docker on the Jetson Nano. Finally, we will update the model over-the-air (OTA) using Edge Impulse.
After installing the toolkit, restart the Docker service:
Now you can use the GPU for machine learning tasks in Docker containers.
To use a camera with Jetson Nano, you need to install the libgstreamer and libv4l libraries. Run the following commands to install the libraries:
After installing the libraries, you can use a camera with Jetson Nano.
To deploy a machine learning model with Edge Impulse and Docker, follow these steps:
Export your model from Edge Impulse as a Docker container. Copy the generated Docker command from the deployment section. Modify the Docker command to use the GPU and camera on Jetson Nano. Run the Docker command on Jetson Nano to deploy the model.
To update the model over-the-air (OTA) with Edge Impulse, follow these steps:
Train a new model in Edge Impulse. Export the new model as a Docker container. Copy the generated Docker command from the deployment section and build a new Docker image.
Run the Docker command on Jetson Nano to deploy the new model.
docker run --rm -it --privileged --runtime nvidia -v /dev/bus/usb/001/002:/dev/video0 -p 80:80 public.ecr.aws/z9b3d4t5/inference-container:73d6ea64bf931f338de5183438915dc390120d5d --api-key ei_07e1e4fad55f06b30839c062076a2ad4bbc174386330493011e75566405a5603 --run-http-server 1337
Test the new model on Jetson Nano.
Monitor the model performance and update as needed.
In this tutorial series, we explored how to update machine learning models over-the-air (OTA) using Edge Impulse and Docker on the Jetson Nano platform. We enabled GPU usage, used a camera with Jetson Nano, deployed a machine learning model, and updated the model over-the-air.
Now you can easily update your machine learning models on Jetson Nano devices using Edge Impulse and Docker.
This page is part of the Lifecycle Management with Edge Impulse tutorial series. If you haven't read the introduction yet, we recommend you to do so here.
In this tutorial, we'll guide you through deploying updated impulses over-the-air (OTA) to the ESP32 using Edge Impulse. We'll build on Espressif's end-to-end OTA firmware update workflow, incorporating Edge Impulse's API to check for updates and download the latest build.
We will modify the Edge Impulse C++ example for ESP32, and combine it with the OTA example from the ESP IDF repository. This will allow us to check for updates to your project on the server side of the IDF example and download the latest build. We will then modify the C++ example to incorporate the OTA functionality and update the device with the latest build. Finally we will add calls back to our ingestion service to monitor the performance of the updated impulse, and gather data. Closing the loop on our active learning cycle.
Let's get started!
Edge Impulse Account: If you haven't got one, sign up here.
Trained Impulse: If you're new, follow one of our end-to-end tutorials
Knowledge of the ESP IDF development framework and C++ for ESP32
Installation of required software as detailed in the tutorial
Begin by setting up your device for OTA updates following Espressif's OTA firmware update workflow. Use the built binary from the C++ example and modify it to incorporate OTA functionality.
Let's get started!
We created an example repository which contains a small application for Espressif ESP32, which takes the raw features as an argument, and prints out the final classification. Download the application as a .zip, or import this repository using Git:
We will need to add a few libraries to the project to facilitate the OTA update process. These will be taken from the ESP32 OTA example and are already included in the example project.
We are going to use the ESP IDF OTA example as a starting point. Running a python server to check for updates and download the latest build from edge impulse. This detemines if there is a new build available and downloads it to the device.You could add more advanced checking for model performance and versioning to this process. This example will only download the latest build if there is a new build available based on date to save lengthy code examples.
This example is available in the ESP IDF repository. You can find the example in:
Starting with the device side code, we will need to add a few libraries to the project to facilitate the OTA update process. These are taken from the ESP32 OTA example and are already included in the example project.
Modify the ESP OTA example python server to check for updates to your project, we will use the date to determine when a new update should be performed to keep things simple. You could add more advanced checking for model performance and versioning to this process. This example will only download the latest build if there is a new build available based on date to save lengthy code examples.
Building the firmware to deploy to our device in the field. We will use the IDF build system to build the firmware. This would be automated but again to save time and complexity we will do this manually.
Compare the model's timestamp or hash with the stored version. If it's different or newer, call the download_model() function.
Monitor the device to ensure the new impulse performs as expected and repeat the update process as needed.
Here we would make calls back to our ingestion service to monitor the performance of the updated impulse, and gather data. Closing the loop on our active learning cycle.
Now lets modify the C++ example to incorporate the device side of the OTA functionality and update our edge impulse project with the device side data. We will add the OTA functionality to the C++ example and update the device with the latest build.
Include the necessary headers and components in your main ESP32 C++ based edge impulse project. There are a number of components that are required for the OTA update process:
NVS is utilized to persistently store data like configuration settings, WiFi credentials, or firmware update times, ensuring retention across reboots.
This library facilitates HTTP requests to the server for checking and retrieving new firmware updates.
These headers aid in executing OTA operations, including writing new firmware to the flash and switching boot partitions.
FreeRTOS ensures OTA updates are conducted in a separate task, preventing blockage of other tasks and maintaining system operations during the update.
Lets start by adding the necessary headers to the main.cpp file in the edge impulse project.
Step 3: OTA Task Implement the OTA task that will handle the OTA update process. Connecting to the python server we created in the beginning of this tutorial. Which is checking for updates to your project
In the simple_ota_example_task function, you'll need to replace http://192.168.1.10/your-ota-firmware.bin
with the actual URL where your firmware binary is hosted.
Step 4: App Main Here’s how the app_main function should look like:
Step 5: Set the target and configuration Make sure you have the partition table set up correctly to support OTA. In the IDF Menu Config, An OTA data partition (type data, subtype ota) must be included in the Partition Table of any project which uses the OTA functions.
Step 6: Compile and Flash You should compile the firmware and flash it to your ESP32 using the IDF build system commands.
Note: Before you run this code, make sure to replace http://192.168.1.10.com/your-ota-firmware.bin
with the actual URL where your new firmware binary is hosted. Make sure that your ESP32 is connected to the internet to access this URL. Also, always test OTA functionality thoroughly before deploying it in a production environment.
This tutorial provides a basic guide for implementing OTA updates on Espressif ESP-EYE (ESP32) with Edge Impulse. It can be extended to include more advanced checking, utilizing more of espressif OTA functionality, and extending the python server to check for model performance and versioning. Happy coding!
This page is part of the Lifecycle management with Edge Impulse tutorial series. If you haven't read the introduction yet, we recommend you to do so here. Balena can serve as the platform for deploying OTA updates to edge devices, including new models trained with Edge Impulse.
An active Edge Impulse account with a project and trained impulse. See the Edge Impulse - Object Detection Tutorials for more information on how to create a project and train an impulse.
Follow the Edge Impulse Docker documentation.
Balena Example Repo - A sample balena project to deploy your impulse as on balena. It exposes an API which the "cam" service uses to get repeated inferences from the images captured by the webcam. See the README
Balena offers a comprehensive platform for building, deploying and managing large fleets of IoT devices. It simplifies fleet management, enhances security, and streamlines the deployment of software and hostOS updates. This tutorial will guide you through using balena to deploy Edge Impulse model updates across your device fleet efficiently. This can be particularly useful for managing multiple devices in the field, ensuring they are always running the latest model. Devices like the NVIDIA Jetson Nano, NVIDIA Jetson Orin, Raspberry Pi, and other single-board computers are supported by balena and can be used to deploy Edge Impulse models.
For this example, we will deploy an Edge Impulse model as a Docker container on a Raspberry Pi using balenaOS. The model will run an HTTP inference server, allowing you to send data to the device for processing and receive predictions in real-time.
An active Edge Impulse account with a trained model.
Follow the Edge Impulse Docker documentation.
Balena is a platform that provides tools for building, deploying, and managing large fleets of IoT devices. It simplifies the process of managing fleets of devices, offering a robust framework for deploying software and hostOS updates, monitoring device health, and ensuring security. Balena could serve as the fleet management and device management platform for deploying OTA updates, including new models trained with Edge Impulse.
Go to your Edge Impulse project, navigate to the Deployment section and select Docker container as the deployment option. Follow the instructions to generate the Docker container command. It will look something like this:
Note the Container address and the api-key, as we will need to use them in a subsequent step below.
Log in to your balenaCloud dashboard and create a new fleet.
BalenaOS - Add a new Device Select the appropriate device type that matches your hardware. Follow the instructions to add a device to your application and download the balenaOS image for it. Flash the downloaded OS image to your device's SD card using balenaEtcher or a similar tool. Power on your device with the SD card or USB key inserted; it should connect to your balena application automatically.
Clone the balena boilerplate Edge Impulse project from Github or start with a Dockerfile.template in a new directory on your local machine. Modify the Dockerfile.template to use your container address and api-key as mentioned earlier. Since balena uses Docker containers, you will simply use the container generated by the deployment screen of your Edge Impulse model.
Use the balena CLI to build, and scan for your local device and push your application to balenaCloud:
Wait for the application to build and deploy. You can monitor the progress in the balenaCloud dashboard.
Once deployed, your device will start the Docker container and run the HTTP inference server.
You can access it using the device's IP address on your local network or through the Public Device URL feature provided by balenaCloud if enabled for your device. Remember that we decided to point this server to the port 80, but feel free to use another port.
With your Edge Impulse inference server running on balena, now you can monitor and manage the other services running on your device fleet using balenaCloud's dashboard and tools. This includes monitoring device health, deploying updates, and rolling back changes if needed.
Furthermore, to deploy the latest ML model deployed from Edge Impulse after retraining, you will need to restart the edge-impulse service running in the connected devices. You can do it from the balenaCloud Fleet Devices page selecting them.
If you have any questions or any issues feel free to contact the balena team using the balena forums.
By following these steps, you should have a functional Edge Impulse inference server running on your balena devices, ready to process data and make predictions. This setup can be integrated into a robust OTA model update process, enabling Lifecycle management and improvement of your Edge AI enabled devices.
Additional Resources
Webinar - Edge Impulse and Balena webinar exploring this topic in more detail.
This page is part of the Lifecycle Management with Edge Impulse tutorial series. If you haven't read the introduction yet, we recommend you to do so here.
OTA DFU with Notehub Blues Wireless have created a unique way to update firmware on your Notecard device is to perform an over-the-air DFU with Notehub.io. For instructions on how to update your Notecard firmware with Notehub.io, please visit the Manage Notecard Firmware guide.
NOFU: Notehub Outbound Firmware Update allows you to update the firmware on the Swan from Notehub.
Blues Wireless has created their own Edge Impulse ingestion API integration which allows you to collect data from the notecard.
Edge Impulse Account: If you haven't got one, sign up here.
Trained Impulse: If you're new, follow one of our end-to-end tutorials
Blues Wireless Account: If you haven't got one, sign up here.
Blues Wireless Notecard: If you haven't got one, order here.
Watch the full webinar here for insights into MLOps and its integration with Edge Impulse, Blues, and Zephyr.
Webinar Overview:
Implementing MLOps Workflow:
Data collection using the Notecard.
Sending data to Edge Impulse for model training.
Deploying the trained model using Zephyr.
Monitoring and continuous improvement.
Author: TJ VanToll link: https://dev.blues.io/blog/robust-ml-ops-workflow/
In TinyML projects, the effectiveness of a machine learning model greatly depends on the quality of its training data. Gathering comprehensive training data is particularly challenging in TinyML due to the limited power and connectivity of tiny devices. At Blues, in collaboration with Edge Impulse and Zephyr, we have developed a workflow that facilitates MLOps (Machine Learning Operations) for tiny devices.
This tutorial outlines a method to implement a robust MLOps process, focusing on how to collect ML data from remote devices and update ML models on these devices in the field. The result is a workflow that seamlessly integrates data collection and model updating.
see the Establishing a Robust MLOps Workflow for TinyML Blues Guide for the in depth guide.
Let's assume we're managing devices monitoring industrial equipment with accelerometers to detect abnormalities. For a successful MLOps workflow, these devices need to send accelerometer data to the cloud for training an updated model. Here, we use the Blues Notecard for this purpose.
The Blues Notecard
The Notecard is a system on module designed for easy connectivity in embedded projects. Its features include:
500MB of cellular connectivity
Global cellular support over LTE-M, NB-IoT, or Cat-1
Secure device-to-cloud communication
Low-power hardware and firmware
Easy embedding options
To set up the hardware, you'll need a Blues Starter Kit, which includes a development board (Notecarrier) and a Swan microcontroller. Additionally, an LIS3DH accelerometer connected to the Notecarrier via a Qwiic cable is required.
The Firmware
The project’s firmware gathers accelerometer readings and sends them to the cloud via the Notecard. We use Zephyr for firmware implementation, as it offers both low-level access and development conveniences. Zephyr firmware is compatible with STM32-based boards like the Swan, and the Notecard has a Zephyr SDK.
The firmware performs the following functions:
Establishes a connection between the Notecard and Notehub
Gathers data from the accelerometer
Sends the data to Notehub
For example, the firmware takes accelerometer readings at intervals set by the Edge Impulse SDK and sends this data as a binary stream to Notehub.
Notecard's new firmware (v5.3.1) introduces 'card.binary' APIs, enabling fast data transfer for large data packets. The data is then sent to Notehub using the 'web.post' method.
The data from Notehub is forwarded to Edge Impulse through an HTTP server. This server, which can be created using any language or framework, listens for POST requests and parses the floating-point accelerometer values. The data is then sent to Edge Impulse's ingestion API, adding new entries to the model’s training set.
see the section of the Blues Guide for more information.
The final aspect of the MLOps process is updating the models on the devices in the field. For this, we use Notecard Outboard Firmware Update. This feature allows OTA firmware updates without writing any code, offering flexibility and safety against bricking devices.
see the Updating ML Models section of the Blues Guide for more information.
Notecard Outboard Firmware Update
Requires specific wiring (provided in the Blues Starter Kit)
Activated via a 'card.dfu' request in the firmware
Involves building a new firmware image file with the updated model
The new firmware is uploaded to Notehub and applied to devices
see the What is notecard outboud update? section of the Blues Guide for more information.
The combination of data collection and model updating forms a robust MLOps process. This approach ensures continuous improvement of ML models based on real data and updates models remotely. The provided GitHub samples offer a reference implementation, adaptable to various project needs.
For more information, refer to the [Notecard Outboard Firmware Update guide](https://dev.blues.io/guides-and-tutorials/notecard-guides
The combination of data collection and model updating forms a robust MLOps process. This approach ensures continuous improvement of ML models based on real data and updates models remotely. The provided GitHub samples offer a reference implementation, adaptable to various project needs.
Build Your Edge ML Application: Follow the step-by-step Blues Swan tutorial.
This tutorial acts as a reference to the webinar and tutorial from Blues Wireless: Optimized MLOps with Edge Impulse, Blues, and Zephy view the full webinar.
In this section we will explore how firmware updates and other scenarios are currently addressed, with traditional OTA. It should help you to get started planning your own updated impulse across a range of platforms.
Starting with platform-specific examples like Arduino Cloud, Nordic nRF Connect SDK / Zephyr and Golioth, Particle Workbench and Blues Wireless. Finally we will explore building an end-to-end example on the Espressif IDF.
By covering a cross section of platforms we hope to provide a good overview of the process and how it can be applied to your own project. With more generic examples like Arduino, Zephyr and C++ which can be applicable to all other vendors.
These tutorials will help you to get started with the following platforms:
Edge Impulse Account: If you haven't got one, sign up here.
Trained Impulse: If you're new, follow one of our end-to-end tutorials
Edge Impulse recognises the need for OTA model updates, as the process is commonly referred to although we are going to be updating the impulse which includes more than just a model, a complete review of your infrastructure is required. Here is an example of the process:
The initiation of an update to your device can be as straightforward as a call to our API to verify the availability of a new deployment. This verification can be executed either by a server or a device with adequate capabilities. Changes can be dependent on a range of factors, including but not limited to the last modified date of the project, the performance of the model, or the release version of the project e.g. last modified date of the project endpoint:
https://docs.edgeimpulse.com/reference/getprojectlastmodificationdate
After we inquire about the last modification, and if an update is available, proceed to download the latest build through:
https://docs.edgeimpulse.com/reference/downloadbuild
We could add further checking for impulse model performance, project release version tracking or other metrics to ensure the update is valid. However in this series we will try to keep it simple and focus on the core process. Here is an example of a more complete process:
Identify components that influence change: Determine the components of your project that require updates. This could be based on performance metrics, data drift, or new data incorporation.
Retrain: Focus on retraining based on the identified components of your project.
Test and Validate: Before deploying the updated components, ensure thorough testing and validation to confirm their performance before sending the update.
Deploy Updated Components: Utilize available OTA mechanisms to deploy the updated components to your devices. Ensure seamless integration with the existing deployment that remains unchanged.
Monitor on device Performance: Post-deployment, continuously monitor the performance of the updated model to ensure it meets the desired objectives. See Lifecycle Management for more details.
The aim will be to make sure your device is always equipped with the most recent and efficient impulse, enhancing performance and accuracy.
We hope this section has helped you to understand the process of OTA model updates and how to implement it in your own project. If you have any questions, please reach out to us on our forum.
In today’s tech world, CI/CD (Continuous Integration/Continuous Deployment) is crucial for delivering fully tested and up-to-date software or firmware to your customers. This tutorial will guide you through integrating Edge Impulse Studio with GitHub workflows, enabling seamless build and deployment of your Edge Impulse model into your workflow.
Edge Impulse provides a comprehensive REST API for seamless integration with third-party services, allowing for the automation of tasks within Edge Impulse Studio. The GitHub Action we created available here simplifies the process of building and deploying models into your workflow.
This example was adapted from the Edge Impulse Blog - Integrate Your GitHub Workflow with Edge Impulse Studio By Mateusz Majchrzycki.
GitHub repository for your firmware source code.
Edge Impulse project created in the Studio.
Obtain Project ID and API Key
Navigate to your Edge Impulse project in the Studio.
Select "Dashboard" from the left pane, then click on "Keys" at the top.
Note down the Project ID and Project API Key.
Add GitHub Action to Your Workflow
Open your workflow YAML file in your GitHub repository.
Add the following code to your workflow YAML file:
Replace ${{ secrets.PROJECT_ID }} and ${{ secrets.API_KEY }} with your actual Edge Impulse Project ID and API Key.
Extract the Model and SDK
After the build and deployment action, you may want to extract the model and SDK.
Use the following example code in your workflow:
Customize Deployment Type (Optional)
Here's an example of downloading the Arduino library:
Real-world Use Case
Utilize the GitHub Action for CI/CD purposes.
For example, testing public examples to prevent breaking changes.
Here's an example of using the Action with Nordic Semiconductor/Zephyr inference example:
6. Notification for Workflow Errors
Thanks to GitHub Actions notification, the person responsible for the commit that created an error in workflow will be notified.
Integrating Edge Impulse Studio with GitHub workflows enhances your CI/CD pipeline by automating the build and deployment process of your Edge Impulse models. This simplifies the development and testing of firmware, ensuring its accuracy and reliability. GitHub repository for your firmware source code. Edge Impulse project created in the Studio.
At Edge Impulse, we recognize that the lifecycle of your impulse is dynamic. As data grows, unanticipated factors, or drift occurs retraining and redeployment becomes essential. Many of our partners have already starting to address this with integrations to our platform, or documenting details for implementation on aspects like OTA updates to your impulse, and Lifecycle Management. We have put together this section to help you understanding and explore how to create your own implementation of a Lifecycle Management system.
MLOps is a set of practices that combines Machine Learning, DevOps, and Data Engineering. The goal of MLOps is to streamline and automate the machine learning lifecycle, including integration, testing, releasing, deployment, and infrastructure management.\
Continuous Learning is a key concept in the domain of Machine Learning Operations (MLOps), which is a set of practices that combines Machine Learning, DevOps, and Data Engineering. Here is an example of the process:
In this section we will explore how firmware updates and other scenarios are currently addressed, with traditional OTA. It should help you to get started planning your own updated impulse across a range of platforms. Starting with platform-specific examples like Arduino Cloud, Nordic nRF Connect SDK, Zephyr, and Golioth, Particle Workbench and Blues Wireless.
Finally we will explore building an end-to-end example on the Espressif IDF. By covering a cross section of platforms we hope to provide a good overview of the process and how it can be applied to your own project.
With more generic examples like Arduino, Zephyr and C++ which can be applicable to all other vendors.
These OTA Model Update Tutorials tutorials will help you to get started.
Edge AI solutions are typically not just about deploying once; it’s about building a Lifecycle Management ecosystem. You can configure your device to send labeled data back to Edge Impulse for ongoing model refinement, and leverage our version control to track your model performance over time.
This bidirectional data flow can be established with a straightforward call to our ingestion API you can explore how to collect data from your board in the following tutorial:
By integrating these elements, you establish an Lifecycle Management cycle, where the impulse is not static but evolves, learns, and adapts. This adaptation is can be as simple as adding new data to the existing model, or as complex as retraining the model with new data and deploying a new model to the device. Based on metrics you can define, you can trigger this process automatically, or manually. In the esp-idf example, we will explore how to trigger this process manually, and conditionally based on metrics.
We hope this section has helped you to understand the process of Lifecycle Management and how to implement it in your own project. If you have any questions, please reach out to us on our forum.
Allxon provides essential remote device management solutions to simplify and optimize edge AI device operations. As an AI/IoT ecosystem enabler, connecting hardware (IHV), software (ISV), and service providers (SI/MSP), Allxon serves as the catalyst for fast, seamless connectivity across all systems.
Allxon Over-the-Air (OTA) deployment works perfectly with Edge Impulse OTA model update on NVIDIA Jetson devices. This tutorial guides you through the steps to deploy a new impulse on multiple devices.
This guide demonstrates how to deploy and manage Edge Impulse models on NVIDIA Jetson devices using Allxon's Over-the-Air (OTA) deployment capabilities. Allxon provides essential remote device management solutions to streamline and optimize edge AI device operations.
Before you begin, ensure you have the following:
Updated impulse as a Docker container from Edge Impulse.
Get Allxon officially supported devices(https://www.allxon.com/).
Create an Allxon account.
Allxon's services are compatible with a variety of hardware models. Follow these steps to complete the required preparations.
Install Allxon Agent: Use the command prompt to install the Allxon Agent on your device.
Pair Your Device: Follow the instructions to add your device to Allxon Portal.
Once added, your devices will appear in the Allxon Portal for management and monitoring.
To perform an OTA deployment, ensure you have your updated Impulse deployed as a Docker container from Edge Impulse.
Generate OTA Artifact: Use the Allxon CLI to generate the OTA artifact.
Deploy OTA Artifact: Follow the Deploy OTA Artifact guide to complete the deployment.
Below are example scripts to help you set up the OTA deployment.
Two minor modifications have been made to the standard Docker command from Edge Impulse docker deploy:
The -it
option has been removed from the Docker command to avoid an error related to the lack of standard input during deployment. An &
has been added to the end of the Docker command to send the process to the background.
By following these steps, you can efficiently deploy and manage Edge Impulse models on NVIDIA Jetson devices using Docker through Allxon. This setup leverages Allxon's remote management capabilities to streamline the process of updating and maintaining your edge AI devices.
We hope this section has helped you understand the process of Lifecycle Management and how to implement it in your own project. If you have any questions, please reach out to us on our forum.
This page is part of the tutorial series. If you haven't read the introduction yet, we recommend you to do so .
In this tutorial, we'll guide you through deploying updated impulses over-the-air (OTA) using the Particle Workbench. We'll build on Particle's firmware update workflow, incorporating Edge Impulse's API to check for updates and download the latest build.
We will modify the Edge Impulse Photon 2 example to incorporate the OTA functionality and update the device with the latest build. Based on the particle workbench OTA example.
Edge Impulse Account: If you haven't got one, .
Trained Impulse: If you're new, follow one of our
Knowledge of the Particle Workbench
Installation of required software as detailed in the
Begin by setting up your device for OTA updates following the particle documentation. https://docs.particle.io/getting-started/cloud/ota-updates/
Let's get started!
Development Devices: Specific devices can be marked for internal testing to validate firmware updates before a broader rollout.
Firmware Upload: Developers upload the compiled binary to the console, ensuring the firmware version is included.
Firmware Locking: Specific devices can be locked to run certain firmware versions for testing purposes.
Release Targets: Firmware can be released to all devices or specific groups to control the rollout process.
Intelligent Firmware Releases: Ensures timely delivery of updates without disrupting device operation, taking into account the device’s status and activity.
Particle OTA is a fully-integrated over-the-air software update system that is built into the Particle IoT PaaS and Device OS. It allows customers to safely and reliably push software updates to single devices or entire fleets of devices directly from Particle’s device management console and developer tools, with no implementation work necessary.
Particle OTA allows you to update your entire IoT device (both the Particle device and any other components) by delivering three kinds of updates:
Application OTA allows users to update the firmware application they are running on the Particle device in order to introduce new features, fix bugs, and generally improve the software application over time.
Device OS OTA allows users to update Device OS to the latest version alongside an application update so that Device OS can be kept up to date with improvements and bug fixes while properly testing against the user-generated software application.
Asset OTA allows users to include bundled assets in an OTA software update that can be delivered to other processors and components in the electronics system so that the Particle device can be responsible not just for updating itself but also the system that surrounds the device.
Export your impulse to the Particle Workbench library:
Add the library through the Particle Workbench via:
Extract the .zip library.
Particle: Import Project and select project.properties. Examples can then be found in: yourprojectname/examples/
We created an example repository which contains a small application for your particle device.
When you're ready to compile your project, make sure you have the correct Particle device target selected and run particle compile <platform>
in the CLI or click the Compile button in the Desktop IDE. The following files in your project folder will be sent to the compile service:
Everything in the /src
folder, including your .ino
application file
The project.properties
file for your project
Any libraries stored under lib/<libraryname>/src
You should now have a compiled binary file in your project folder named firmware.bin
.
Next lets look at the OTA functionality and how we can incorporate it into our project.
You will need to have a device deployed with an existing firmware containing an impulse before you can roll out a new version. Then you can use the OTA workflow to update the firmware on your device to a new version. While blocking all other devices from updating to the new version.
Lock Devices: Lock specific devices to the new firmware version and monitor their behavior. Unlock Devices: Unlock the devices once testing is complete and you are satisfied with the firmware's performance.
Release Targets: Choose to release the firmware to specific groups or the entire fleet of devices. Intelligent Firmware Release: Opt for this to have the Particle Device Cloud intelligently manage the update rollout. Important Tips: Avoid Disruptions: Utilize Device OS APIs to control OTA availability, ensuring devices aren’t disrupted during critical operations. Managing OTA Updates: Use the console or REST API to force enable OTA updates if needed. Monitoring: Keep an eye on the devices' behaviors post-update to quickly identify and address any potential issues. With Particle's OTA capabilities, developers can ensure that their IoT devices are always running the latest, most secure, and most efficient version of their firmware, enhancing the reliability and functionality of their IoT ecosystems.
This guide supplements the tutorial on OTA Model Updates with Edge Impulse on Particle Workbench, focusing on configuring a Particle webhook for sending data to the Edge Impulse ingestion API.
Access Particle Console:
Log in with your Particle account credentials.
Navigate to Integrations:
Click on the "Integrations" tab in the left-hand menu.
Select "Webhooks" from the available options.
Create a New Webhook:
Click "New Integration".
Choose "Webhook".
Webhook Configuration:
Name: Assign a descriptive name to your webhook.
Event Name: Specify the event name that triggers the webhook (e.g., "edge/ingest").
URL: Set this to the Edge Impulse ingestion API URL, typically something like https://ingestion.edgeimpulse.com/api/training/data
.
Request Type: Choose "POST".
Request Format: Select "Custom".
Custom Request Body:
Input the JSON structure required by Edge Impulse. This will vary based on your project's data schema.
HTTP Headers:
Add necessary headers:
x-api-key
: Your Edge Impulse API key.
Content-Type
: "application/json".
x-file-name
: Use a dynamic data field like {{PARTICLE_EVENT_NAME}}
.
Advanced Settings:
Response Topic: Create a custom topic for webhook responses, e.g., {{PARTICLE_DEVICE_ID}}/hook-response/{{PARTICLE_EVENT_NAME}}
.
Enforce SSL: Choose "Yes" for secure transmission.
Save the Webhook:
After entering all details, click "Save".
Test the Webhook:
Use example device firmware to trigger the webhook.
Observe the responses in the Particle Console.
Debugging:
If errors occur, review the logs for detailed information.
Ensure payload format aligns with Edge Impulse requirements.
Verify the accuracy of your API key and other details.
Copy and paste the following into the Custom Template section of the webhook:
Below we will do a basic example of sending data to Edge Impulse for Lifecycle Management. We could further extend this example to include more advanced checking, utilizing more of Particle OTA functionality, and add checks for model performance and versioning. The code gathers data from analog sensors, processes it, and sends it to Edge Impulse for Lifecycle Management. The webhook is triggered with the event name edge/ingest/sample.
This tutorial provides a basic guide for implementing OTA updates on your Particle Workbench connected device (Photon 2). It can be extended to include more advanced checking, utilizing more of espressif OTA functionality, and extending the python server to check for model performance and versioning. Happy coding!
By default, the GitHub Action downloads the C++ library. You can customize the deployment type using the deployment_type input parameter. We can use a simple Python script here
You will need to treat this as a new project and follow the instructions in the to set up your environment for local development.
If your project includes a library that has not been registered in the Particle libraries system, you should create a new folder named /lib/<libraryname>/src
under /<project dir>
and add the .h
, .cpp
& library.properties
files for your library there. Read the for more details on how to develop libraries. Note that all contents of the /lib
folder and subfolders will also be sent to the Cloud for compilation.
Mark Devices for Testing: In the Particle console, mark specific devices for internal testing to validate firmware updates. Upload Firmware: Compile and upload the firmware binary, ensuring to include the product ID and version.
Visit .
This code continuously samples voltage and current, calculates RMS current, and then sends a JSON array of the sampled data to the Edge Impulse ingestion API. The publishData function uses Particle's Particle.publish method to send the data to the specified event. This triggers the webhook configured to send data to Edge Impulse. See the for more information.
This page is part of the Lifecycle Management with Edge Impulse tutorial series. If you haven't read the introduction yet, we recommend you to do so here.
In this tutorial, we'll guide you through deploying updated impulses over-the-air (OTA) using the Zephyr RTOS. We'll build on Zephyr's firmware update workflow, incorporating API calls to check for updates to your edge impulse project and download the latest build. As Zephyr does not have an OTA update service, and Golioth is used in their OTA guide. We'll use Golioth's OTA update service to deliver the updated firmware to the device. On devices running Zephyr RTOS, leveraging Golioth's cloud platform for the firmware update portion of the process.
Secure and encrypted firmware delivery
Delta updates to minimize download size
Integration with Zephyr RTOS
Edge Impulse Account: If you haven't got one, sign up here.
Trained Impulse: If you're new, follow one of our end-to-end tutorials
Knowledge of Zephyr RTOS and nRF Connect SDK
A Golioth account and the Golioth SDK installed
Clone the Golioth Zephyr SDK examples repository:
Navigate to the Golioth firmware examples folder we are going to modify the device firmware update example to connect to the ingestion API to send data back from device.
Now copy the edge-impulse-sdk folder from the cloned repository into the dfu folder.
You will need to merge in the run inference function from your existing project. This will be the function that will be called to run inference on the device.
Now add the run inference function to the main loop of the dfu example. This will run inference every 2 seconds.
With the classification, ingestion code and Golioth implementation in place, proceed to build and run the application on the nRF9160 Development Board. Utilize the following commands:
These commands will build and flash the firmware onto your development board.
To verify that the Edge Impulse model is running and updating OTA with Golioth, observe the console output. It should display inference results at regular intervals. Also, you can monitor the device’s firmware version and its updates via the Golioth console.
Simulate an OTA update by changing the Edge Impulse model and repeating the build and flash process. Monitor the Golioth console for updates and check the device console to observe the changes in inference results.
Congratulations! You've successfully implemented OTA model updates with Edge Impulse on Zephyr RTOS and nRF Connect SDK, facilitated by Golioth. You can now continuously enhance and deploy machine learning models to your edge devices securely and efficiently.
In this tutorial we will demonstrate how to securely collect and process sensor data from a managed device with the Golioth on AI example project. The managed device is connected via cellular and streams labeled but unstructured data to a mutually accessible Object Storage (S3 Bucket), by collecting labeled sensor data in this method we can also demonstrate a common use for this form of data acquisition, performing automated Data processing or Data Quality steps to the collected data via custom transformation blocks.
We will then apply data processing steps on the collected data using the custom CBOR transformation block to convert this data to a format we can use to later train a model. This same process can be adapted to perform Data Quality techniques that would typically be performed by an ML engineer.
To follow along with this example, ensure that you have the following:
Golioth account with an organization and a connected compatible device (e.g., nrf9160).
Edge Impulse enterprise account.
Trained Edge Impulse project ready for deployment.
AWS account with access to S3.
Basic knowledge of AWS S3, Docker, and Zephyr.
Example from the Golioth on AI tutorial repository here
This tutorial was created for the Golioth on AI launch see the associated video on youtube Read it here.
Before proceeding with the integration, ensure that your Golioth device is set up with the appropriate firmware. For detailed instructions on initializing your Zephyr workspace, building, and flashing the firmware, please refer to the Golioth on AI repository README.
Clone the Golioth on AI repository and initialize the Zephyr workspace with the provided manifest file.
Log in to Golioth and create a new project. This project will handle the routing of sensor data and classification results.
Log in to Edge Impulse Studio and create a new project. This project will receive and process the raw accelerometer data uploaded from the S3 bucket.
Once your device is set up, follow the instructions in the repository README to create the necessary Golioth pipelines. This includes setting up the Classification Results Pipeline and the Accelerometer Data Pipeline. Latest detailed steps can be found in the repository Golioth on AI repository README.
Golioth Pipelines allows you to route data between different services and devices efficiently. You will need to configure two pipelines for this demo:
This pipeline routes classification results (e.g., gesture predictions) to Golioth's LightDB Stream, which stores data in a timeseries format.
You will configure a path for classification results (e.g., /class) and ensure that the data is converted to JSON format.
This pipeline handles raw accelerometer data by forwarding it to an S3 object storage bucket. Ensure the pipeline is set up to transfer binary data.
Important: Configure your AWS credentials by creating secrets in Golioth for AWS_ACCESS_KEY and AWS_SECRET_KEY, and specify the target bucket name and region.
Follow the instructions in the continuous motion recognition tutorial to generate a gesture recognition model.
Download the generated library from Edge Impulse Studio and extract the contents.
Build the firmware:
Set Golioth Credentials::
Add the same configuration to the Golioth secret store
Navigate to your Golioth Secret Store: https://console.golioth.io/org//project//secrets
Add your AWS credentials (Access Key ID and Secret Access Key) and the S3 bucket details to the Golioth secret store.
Press the button on the Nordic Thingy91 to start sampling data from the device's accelerometer.
Raw accelerometer data will be automatically routed to your S3 bucket via the Golioth pipeline. You can later import this data into Edge Impulse Studio for further model training.
Classification results will be stored in Golioth's LightDB Stream. You can access this data for further analysis or visualization.
In Edge Impulse Studio, use the Data acquisition page to import your raw accelerometer data directly from the S3 bucket
Once imported, label your data appropriately to prepare it for model training.
Below is an example of classification data you can expect to see in the Golioth console:
Raw accelerometer data uploaded to S3 can be imported as an array of X-Y-Z float values, which will appear in the Edge Impulse Studio as time-series data.
From here we can perform a number of data processing steps on the collected data:
Use the custom CBOR transformation block to convert raw accelerometer data to a format suitable for training a model in Edge Impulse.
Apply custom transformation blocks to perform data quality checks or preprocessing steps on the collected data.
Import the transformed data into Edge Impulse Studio and train a new model using the collected accelerometer data.
Deploy the trained model back to the Golioth device for real-time gesture recognition.
In this tutorial, we demonstrated how to securely collect and process sensor data from a managed device using Golioth and Edge Impulse. By leveraging Golioth's data routing capabilities and Edge Impulse's machine learning tools, you can easily build and deploy custom models for gesture recognition or other applications. This example showcases the end-to-end workflow from data acquisition to model training and deployment, highlighting the seamless integration between Golioth and Edge Impulse.
For more information on Golioth and Edge Impulse, visit the official documentation and tutorials: