search

Ribbit-Network / ribbit-network-frog-hardware

The sensor for the world's largest crowdsourced network of open-source, low-cost, GHG Gas Detection Sensors.
https://www.ribbitnetwork.org/
MIT License
94 stars 26 forks source link

Select Processor Option for Solar Powered Sensor #63

Closed keenanjohnson closed 1 year ago

keenanjohnson commented 2 years ago

Building a Solar Powered Frog Sensor would be great for the sustainability of the project. However, the power consumption of a large always-on device like a Raspberry Pi is too much to have a reasonably sized solar panel + battery.

There are at least two ways to solve this:

keenanjohnson commented 2 years ago

@eren-rudy and @djgood FYI.

djgood commented 2 years ago

I've been thinking of additional possible solution which is a hybrid approach to the two possible ways you've already suggested above: Keep a Linux-capable chip so that we can keep using Balena since it's giving us the huge benefit of simplifying provisioning and deployment (for free! 🤯), but have it turn off / sleep and delegate most of the data acquisition to a lower power microcontroller.

Best of both worlds but highest level of complexity.

keenanjohnson commented 2 years ago

Indeed but perhaps it’s the best solution! There is a Balena playground example where the balena image can flash firmware to an ESP32 microcontroller for example, which might be a good approach to realize what you mentioned below!

https://github.com/balena-io-playground/esp32

On Wed, Nov 3, 2021 at 4:15 PM Desmond Good @.***> wrote:

I've been thinking of additional possible solution which is a hybrid approach to the two possible ways you've already suggested above: Keep a Linux-capable chip so that we can keep using Balena since it's giving us the huge benefit of simplifying provisioning and deployment (for free! 🤯), but have it turn off / sleep and delegate most of the data acquisition to a lower power microcontroller.

Best of both worlds but highest level of complexity.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Ribbit-Network/ribbit-network-frog-sensor/issues/63#issuecomment-960286682, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATQ3FRKCYC2PBZCIPE6RY3UKHGD7ANCNFSM5HKCN5QQ .

daveb377 commented 2 years ago

Seems like a significant amount of hardware overhead and cost driven by a desire to use Balena to update a linux platform I suspect there are lower power solutions out there.

keenanjohnson commented 2 years ago

Definitely so! I would reframe that statement as saying it is a priority of the project to have a good Over-The-Air Update system. Balena is just the only option we've identified that will work easily without us writing a TON of software.

Definitely open to trialing other options as we find them! For example, I've been trialing https://golioth.io/ as a service for OTA with ESp32 devices, but that feature isn't done in development yet.

keenanjohnson commented 2 years ago

The other comment to note that is we're an open-source project, so minimizing recurring software costs is a big priority! That's the biggest advantage to Balena is that we can use their service for free as an open-source project, which is a big cost savings.

keenanjohnson commented 2 years ago

I was introduced to https://toit.io/ as a fleet management software tool for ESP32. It seems really new, but at least seems done. I Will attempt to get trial access for that tool to assess if it is suitable. I'm a bit wary because this requires a proprietary language.

keenanjohnson commented 2 years ago

Here's my slack chat with the Toit developer team.

The summary is that there isn't a way for end device users to reconfigure their wifi connections via ToiT at the moment and we would need to wait on the Toit team to add support for this before it's possible.

image

keenanjohnson commented 2 years ago

See https://github.com/toitware/public/issues/31 for the feature request on the Toit side.

Derek-Gutheil commented 2 years ago

Hey @keenanjohnson can you explain the need for OTA updates to the sensor?

keenanjohnson commented 2 years ago

Hey @Derek-Gutheil! It's a good question!

The main reason is that I consider our backend database (currently based on influxdb), to be a prototype at best. Given that, it's extremely likely we'll need to update the software on devices in the future as we learn and grow the project and establish the best practices for collecting this data.

In theory, we don't "need" OTA, however, I believe it is possible to ship a system with it, so I think it's a goal worth shooting for unless we prove that it can't be done.

Another point of information, I have heard that Golioth.io now supports OTA for ESP32, if someone wanted to try that out, it could unlock that as a processor option!

Derek-Gutheil commented 2 years ago

I don't have experience with fleet management for IOT devices, so forgive my ignorance. I'm looking at this from more of an embedded device perspective.

Doing a bit of digging, it looks like the ESP32 supports OTA updates natively

Looking up a tutorial here they show how the ESP32 can be triggered via serial to look for updated firmware from an AWS S3 bucket. Could the devices simply be triggered from a timer (once a week, once a month, etc.) or a response variable from the server when they upload data to check the S3 bucket for new firmware? The rollout of new firmware images wouldn't be instantaneous, but it seems like a vast majority of devices could feasibly be updated within a week or so without using an external service like balena, golioth, toit, etc.

Again, apologies if I don't understand the complexities of fleet management.

keenanjohnson commented 2 years ago

That is definitely possible @Derek-Gutheil ! The challenge comes from dealing with security and edge cases which is where the additional services you have mentioned create value. For example, what is the power to the device is disrupted during the update download? For security,

These are solvable engineering challenges to be sure, but in my experience, it takes significant software engineering effort to solve them (person-months generally). As an open-source project, ensuring that we take on the least technical risk with our technology decisions is important to keep shipping products given that we don't have a full-time staff. So I just want to be sure that we do an adequate make vs buy trade study here.

Derek-Gutheil commented 2 years ago

Got it, that makes sense! I'd love to help with that make vs buy study, let me know how I can.

charlesrg commented 2 years ago

Just saw this project today, this is definitely a job for a solar powered ESP32 not a Raspberry PI.

fosteman commented 2 years ago

This gets me thinking: Rspberry PI Zero with a solar panel https://www.arrow.com/en/research-and-events/articles/can-you-run-a-raspberry-pi-on-solar-power

Also wondering about the solar panels being winter-proof. I'm in MTL, and would love it to work 365 days with least amount of snow-cleaning.

Screen Shot 2022-08-06 at 12 50 30
keenanjohnson commented 2 years ago

That's a great goal @fosteman ! Cold resilience is something we should definitely prioritize!

The raspberry pi zero is a good option for low power, but here are a few challenges (that are probably solvable), which have caused us to stay away from it:

Like I said all of these are certainly solvable, but so far our take has been that using an easier hardware like an ESP32 microcontroller for example is the better hardware choice in exchange for more software complexity ex: https://github.com/Ribbit-Network/ribbit-frog-micropython/issues/6.

Definitely curious for your thoughts though.

keenanjohnson commented 1 year ago

We're moving to an esp32-based frog for the foreseeable future, so closing this as selected since the esp32s3 should be adequate for future solar developments.

New software repo below:

https://github.com/Ribbit-Network/ribbit-network-frog-software