Home > On-Demand Archives > Theatre Talks >
Making a Robot Butterfly with an RTOS
Erin Kennedy - Watch Now - EOC 2025 - Duration: 16:02
Making a Robot Butterfly goes beyond aesthetic appeal—it requires managing inputs, outputs, and coordinating them seamlessly. This project is ideal for beginners, as it leverages ESP32 and the accessible FreeRTOS API through the Arduino IDE. In this talk, we’ll delve into code that enables smooth coordination between the butterfly’s flapping wings, lights (outputs), and environmental sensors (inputs)—and relate these to RTOS principles. This creates a responsive and interactive experience with its surroundings. Whether you're an embedded systems engineer, hobbyist, or creative technologist, this session offers valuable insights into breathing life into robotic creatures through embedded programming. https://github.com/RobotGrrl/RobotButterfly/.
Thank you Erin for the presentation.
I do have some feedback I'd like to share.
First off, I think it is very misleading in the way you compare the two versions to eachother. An embedded developer would not use blocking delays to animate LEDs or control servos. We would use an interrupt-driven approach along with timers for the animations. This is quite a basic, non-complex way of solving it. Of course, we can go further and implement a simple event qeueue which we poll in our mainloop to feed the FSM.
It is easy to think that an RTOS will magically solve your problems, but this is not the case. It is easy to shoot yourself in the foot, when it comes to race conditions and synchronization. On a technical note, vTaskDelay is actually a blocking call. I think what you meant was the OS is free to switch context/thread, but the call to the delay will block in the current thread.
I would generally say that an RTOS is not the answer for smaller projects. Usually we can solve problems using simpler methods, and I believe we shall strive for simplicity.
I am happy to get your feedback on this. Cheers!
Hi Jonathan,
Thanks for taking the time to type and share your feedback as well as being open to a response about it. I'm glad at EOC we can all learn from our experiences, this is what makes it great :)
The bare metal proximity demo did not have a blocking delay, yet, the FreeRTOS version was still more responsive.
Here's the code for proximity mode if you'd like to take a look
Bare metal version:
https://github.com/RobotZwrrl/RobotButterfly/blob/main/firmware/RobotButterflyIntegrated2/State4.ino
FreeRTOS version:
https://github.com/RobotZwrrl/RobotButterfly/blob/main/firmware/library/RobotButterfly/examples/RobotButterflyIntegrated3/State4.ino
It is a subtle difference in video, but when interacting in reality it is more noticeable - same with the servo movements being smoother.
Your point about simplicity is interesting! One of the reasons for venturing in to FreeRTOS was indeed the simplicity and accessibility of the tools - having it available straight in the Arduino IDE (with ESP32 boards), made the setup process incredibly simple.
Would you have any recommendations for novices to pay attention to for race conditions and synchronisation, who may only have 'printf debugging' at the moment?
Excellent presentation Erin!
Thank you!
Hi Erin,
after missing you on last year's EOC, this presentation again was so inspiring and well done, not just to concentrate on technology but to make a product which targets the owner's heart. Thanks a lot for your presentation and engagement.
Thank you Thomas! I am glad to hear that aspect resonated. Lots of gratitude to the organisers Jacob and Stephane for being open to this different angle (and also beginner view) in EOC.
Thank-you for giving your time to prepare and give this presentation. I would have liked the source code to have been displayed a little longer.
Thank you! I will keep the feedback about source code in mind for future videos and documentation.
Good to hear the mention of Micrium uC/OS-III, which felt like it died when it was open-sourced a few years back around the time when SiliconLabs took it over and FreeRTOS took off. It's well documented, easy to use and has full source code.
https://github.com/weston-embedded/uC-OS3
https://micrium.atlassian.net/wiki/download/attachments/132386/100-uCOS-III-ST-STM32-003.pdf?version=1&modificationDate=1383921876000&cacheVersion=1&api=v2
Hi SimonSmith,
that is true, if you use SiliconLabs chips, then uC-OS is a good option!
As an embedded designer that has used both RTOS and bare-metal implementation for many projects over the last few decades, I like the way this presentation shows some of the benefits that an RTOS can bring to decomposing the problem to be solved into largely independent tasks that can use synchronization primitives to synch/communicate between them. This can really simplify the main loop scafolding and timing that would otherwise have to be built to handle the project in a baremetal superloop implementation allowing the designer to focus on "doing the thing" rather than building a bare metal executor that will require more and more attention as the complexity of the project grows.
I'm certainly not saying that the RTOS is a one-size-fits all solution to every problem, but there are certain classes of problems with parallelizable, largely indepent functions that are a nice fit for an RTOS -- even when not needing some of the higher powered features that an RTOS can bring to the party.
Kudos on a good presentation!