checkBin

Concept

The main problem of waste management in a lot of big cities is overflowing bins. This brings to garbage left on the streets, bad smells, wild animals roaming and fed up citizens. It is the consequence of an inefficient usage of the resources by garbage pickup companies, both economical and logistical (employees time and garbage trucks). As an example it happens that the usual pickup route empties not yet full bins missing the full ones.

IoT could help solve this problem without having to hire new workers nor buying new trucks, which would generate more long term expenses for the company.

Through a network of intelligent devices we can monitor the fill level of every trash bin and aggregate this data to generate a centralized and complete knowledge on the real time situation of the bins in the city. Using this knowledge companies could plan efficient pickup routes based on the fill level of the bins. They could also make statistical analysis on the collected data to tailor the number of bins in each area according to the real needs.

The Prototype

To see first hand how our system would be implemented on a real bin, we built a prototype. Starting from a standard bin we used hot glue and some 3D printed parts to put on the bin: sensors, actuators and the board. What you can see in these photos is the final result:

We used the following components:

LoRaWAN compatible STM board:

STM32L0 Discovery kit LoRa, Sigfox, low-power wireless. The module is powered by an STM32L072CZ microcontroller and SX1276 transceiver. The transceiver features the LoRa long-range modem, providing ultra-long-range spread-spectrum communication and high interference immunity, minimizing current consumption. In the cities there should be some LoRaWAN gateways to pick up all the signals sent by the bins. To allow the communication the following parameters must be set in the main.h file: dev_eui, app_eui, app_key.

Ultrasonic sensors: to measure occupied volume in the bin.

We use ultrasonic sensors as the main way of measuring the fill level of the bins. In the prototype we used only one sensor but we decided to take three measures every time with a 30 seconds timeout. In this way we can discard measurements taken while the bin was open. Using more ultrasonic sensors would enhance the accuracy of the measures but implies a linear increase in the energy consumption of the sensors of the whole system.

Load cells and a Load Cell Amplifier: to measure the weight of trash in the bin.

To detect anomalies in the data read by ultrasonic sensors we use a load cell. Together with statistics based on gathered data we can compare the occupied volume in the bin and the weight to understand if there is an anomaly in the ultrasonic measure. To estimate the weight based on the ultrasonic measure and to estimate the maximum weight, the following parameters must be set in the main.h file: height of the bin in cm, base area of the bin in square meters, waste type (plastic, metal, glass, paper, food, mixed).

Button: to open the bin when it is locked.

OLED Display: to show the fill level to the citizens.

The OLED Display will provide information about the fill level as feedback to the citizens. It shows a numeric value together with the progress bar. In this way they can be more involved in the process and take responsibility.

Stepper motor: to lock the opening of the bin when it is full and to unlock it when it gets emptied.

Wiring

All the components are wired following the diagram below:

The Logic

The RIOT code implements the logical computation carried out in the LoRa board. In the main function it initializes the sensors, the actuators, the LoRa communication parameters and a thread to handle the button. It then starts a loop which alternates an active phase and a sleeping phase.

In the active phase the code does the following:

• the ultrasonic sensor makes three measurements with a 30 seconds timeout
• among the three values it rules out eventual anomalies and choose the pertinent one
• it then converts it to a fill level between 0 and 9 knowing the height of the bin
• the load cell is used to get the weight of the trash inside the bin
• based on the fill level and the type of garbage, it computes the estimated weight
• it also computes the maximum weight based on the height of the bin, the base area and the type of garbage
• if the fill level is lower than 8 but the weight is more than the maximum one (with a 20% margin) we have an anomaly; it sends to the cloud a fill level of 9 to notify the bin must be emptied but it does not close the bin.
• else if the fill level has changed from the previous measurements it sends the fill level to the cloud and updates the values on the OLED display. Then it also checks:

• if the weight is below the estimated one (with a margin of 20%) when the fill level is greater or equal than 8; in that case it keeps the bin open
• else if the fill level is greater or equal than 8 and the weight is coherent, it closes the bin
• else it opens the bin

Moreover a separate thread is used to handle the bin’s opening using the button:

- if the button is pressed and the bin is locked then the bin is opened.

[NOTE: the code implementing the logic in RIOT OS can be found on the GitHub Repository]

Network Diagram:

Cloud:

The cloud part of the project is composed by the following elements:

• The Things Network
• AWS IoT Core
• AWS Lambda Function
• AWS DynamoDB
• AWS Amplify
• APIs provided by Google Maps.

The format of the messages sent from the board is the following: fill_level.

The DataBase is composed of a single table binTable(DevEUI, id, lat, lng, last_fill_level, last_fill_timestamp) in which:

• the DevEUI assigned to the device is used as primary key of the table;
• id is used to identify the bin on the web dashboard;
• lat and lng are the geographic coordinates where the bin is located;
• last_fill_level is the last fill level received from the board;
• last_fill_timestamp is the timestamp at which the last fill level was received.

As the primary key of the table we decided to use the DevEUI assigned to each bin. In this way we can immediately associate the messages received to the respective bin using information that is automatically sent in the exchange, without the need to add more information in message payload. We also chose to use an ID to identify in a simpler way the bins in the web dashboard. Being the bins often one near the other, a garbage truck driver can use the ID to understand which bin needs to be emptied. Clearly, the id should be written on the physical bin.

MessagePath:

When a message containing the fill level is sent to a LoRa Gateway in The Things Networks (TTN). TTN relays the incoming message to the MQTT Broker in the AWS IoT Core. Once IoT Core receives a new message on the broker, using its Rule Engine, it calls the Lambda Function “writeBinTable_v2”. This function updates the tuple in the DB that has the same DevEUI as the one in the message that just arrived.

WebInterface:

The user interacts with AWS Amplify to get the static content. Once the page on the client browser completely loads, it runs the javascript code that generates the map with markers where bins are located. The user can now click a marker to see the bin id, the last fill level and the time when the last fill level was detected.

From the web interface the user can also add a new bin to the system by filling the latitude and longitude fields and clicking on the “Add Bin” button. It calls the function URL of the “addBin_v2” Lambda Function that creates a new tuple in “binTable” and returns to the user the new bin id.

Moreover the user can delete a bin from the system by inserting the id in the corresponding field and then clicking on the “Delete Bin” button. In this way the Lambda function “deleteBin” is called and the tuple associated with the specified bin’s id is deleted from the DB.

All the data stored in the database can also be reached via a REST API, to ease the integration with pre-existing management systems of the garbage pickup companies. You can call it from here

[NOTE: the code implementing the Lambda Functions can be found on the GitHub Repository]

Requirements:

• The accuracy error of the fill level must be at most 10%;
• The update of the fill levels must be shown in the dashboard within 2 hours from the actual change;
• The system must be energy independent for at least a year;
• The capacity of the bin must not be reduced by more than 5% (both in weight and volume);
• The system must be compliant with the LoRa duty cycle restrictions;
• The ratio of wrong fill level measurements over total fill level measurements must be < 5%.

These requirements were set making reasonable assumptions on the observed real world.

Energy Consumption

A major constraint that we have is energy consumption. We want the system to be energy independent for at least a year, considering the following energy usage:

• The OLED screen will be always on and will be updated at every change of the fill level.
• The stepper motor will be activated only when the bin is full or recently emptied.
• The sensors will be activated at the predefined intervals. The ultrasonic sensor will take three measures with a 30 seconds interval, to discard eventual measures taken while the bin was open. The load cell will also be activated to read a value.

Analysis on sampling frequency

One of the key aspects of the project is how often the sampling is done. Periodic sensing is a good compromise between energy consumption and data availability. It is also possible to tailor the interval between measurements, during the development we choose for our application an interval of 1 hour. Using a bigger interval we would lose accuracy in detecting when the fill level changes. Moreover we need to have a recent enough update so that the trucks can have a realist view to plan their route.

Analysis on radio usage

The second aspect that has a great impact on the consumption of energy is how often the radio is used. We chose to transmit every time a fill level changes: in this way we reduced even more the energy consumption, without losing any relevant information on the status of the bins. The antenna will be also activated when an anomaly is detected between the fill level measure taken by the ultrasonic and the weight measured by the load cell. In that case it will be used to notify the anomaly, sending the max fill level to the cloud to notify the bin must be emptied.

In conclusion we chose to sense every hour and to send data every time there is a change in the fill level of the bin or there is an anomaly. In this way we can also be compliant with the LoRa duty cycle restrictions (in Europe they are regulated by the ETSI EN300.220 standard) and with the requirements about the latency between the change in the fill level and the result visualized in the dashboard.

Measured energy consumption

We used a multimeter and a INA219 to measure the energy consumption of our system. Moreover we used IoTLAB to measure the energy consumption during the sending of LoRa packets of the board we used.

• 76.3mA Energy consumption during wake-up time
• 48.2mA + 6.1mA Energy consumption of the board + the OLED display
• + 8.2mA Energy consumption to activate the sensors and compute the fill level (total 62.5mA)
• + 34.5mA Energy consumption to transmit data using LoRa (total 88.8mA)
• + 90.7mA Energy consumption of the Stepper (total 145mA)

The measured consumption can be visualized in the following plot:

Through the use of INA219, a Arduino UNO and the Adafruit INA219 library we obtained more precise measurements of the energy consumption of the running system:

Battery

To power the system we must use a battery, as there is no infrastructure to keep the device plugged in. Considering the measured energy consumption and the requirements, we would need a 500A battery without using charging methods. Searching for such kind of batteries we found out their weight is not less than 35kg. Considering standard bins with a capacity of less than 500kg, that battery would violate the constraints about the reduction of capacity. Considering that conclusion we must implement some kind of charging method or loosen the constraints.

Sensors precision

The precision of the fill level depends on the height of the bin. The fill level is a value between 0 and 9, computed as fill_level = 9-(10*distance/max_distance). Consequently every step of the fill level will represent a height value of the trash between fill_level*max_distance/10 and (fill_level+1)*max_distance/10. As a consequence we have an intrinsic error percentage of maximum 10% of the total height, which is compliant with the requirement about the accuracy of the fill level.

We measured the precision of the load cell with respect to the conversion formula we used. From the tests we have done we discovered a 2% error, which is acceptable. It is also counterbalanced by the 20% margin used when comparing weights in the code.

We conducted some tests to evaluate the accuracy of the system. Total measurements: 40. Detected anomalies: 2. Undetected anomalies: 1.

Accuracy of the fill level: 92.5%. We expect the accuracy to rise with a greater sample dataset so to be compliant with the requirement about the error rate.

Network Usage

Considerations on Packets and Payload Size

Taking into account our implementation, we sent a LoRa message with a payload of 1 byte. Considering that a LoRa packet uses 13 bytes as header (according to the Specification 1.0.2 we are using), the total packet size is 14 bytes. Knowing that the Spreading Factor is 7, the Region is EU868 and the Bandwidth is 125kHz. Using these information and the calculator provided by The Things Network itself (you can find it here) we obtained that the Time on Air of a packet is 43.6 ms. This is a small time period, at least with respect to the intervals we consider in our project (a bin takes measures once every hour).

At the beginning of the project we considered sending packets with bigger payloads of 7 bytes, in this way we could also send the bin’s ID in the message. Even if the time on air would have had only a slight increase going up to 56.6 ms, a time period admissible for our situation, we opted for sending only a single byte representing the fill level. This choice was made because there is no reason to send the bin’s ID to the cloud. Indeed, the data is processed using the DevEUI, not the ID, and this information is already present in the packet by default.

Considerations on Latency

In our use case it does not make much sense to talk about latency of the whole system, in particular if we consider that the measurement interval in a bin may be governed by a model computed using machine learning.

Instead a more relevant aspect to consider is the latency between the moment the board starts measuring and the time when the data are available to the end user. This time interval is composed of three parts:

• Time on the Board (TBoard): time needed to compute the fill level and send the message;
• Time on Air (TAir): time needed for the message to go from the board to the LoRa gateway;
• Time for Cloud Processing (TCloud): time needed on the cloud to process the data (we also include the time needed by TTN to send the message to AWS IoT Core).

More in details we have that:

• TBoard = TUltrasonic + TLogic where TUltrasonic is the time needed to perform the ultrasonics measures and TLogic is the time needed to perform the computation of the fill level and send the message.

In our case we have that:

• TUltrasonic = 60s because the systems performs 3 measurements (one every 30 seconds) so we have them at t=0, t=30s, t=60s;
• TLogic = 0.05s empirical data tells us that the board does not take more that 50ms to compute the fill level and send it;
• TAir = 0.05s using The Things Network calculator we know that in theory the time on air is 43.6ms, to cope for some eventual delay we assumed 0.05s;
• TCloud = 2s clearly we do not have any control over this aspect but empirical data tells us that it does not take more than 2s.

Said this we have that

• TBoard + TAir + TCloud = TUltrasonic + TLogic + TAir + TCloud = 60 + 0.05 + 0.05 + 2 = 62.1s ≃ 62s

This can be graphically seen in the image below:

Scalability

To be sure our system would work in the real world environment, we also tested its scalability. We chose a block in our city and created an entity in the database for each of the bins.

We used IoTLAB and created an experiment reserving 12 boards b-l072z-lrwan1 on the Saclay site.

We wrote some RIOT OS code to connect to the LoRa gateway, repeatedly generate random fill levels and send them to the cloud. This code was compiled and flashed on every board, using different DevEUI, AppKey and AppEUI which were linked to different bin entities in the database. The experiment ran smoothly to prove our system was capable of supporting more devices.

Here you can see an extract of the recorded experiment:

From this experiment we realized we cannot use the WebSocket technology to update the dashboard every time a bin sends its fill level. Due to the high number of bins, the web dashboard could not keep up with all the updates and kept refreshing. Moreover we realized that the cloud would have had to send a high number of messages to every open dashboard. Analyzing our application, we realized that there is no need for such a feature. Indeed, the latency from the change in the fill level to the update on the cloud can be up to 1 hour. So there is no reason to implement a low latency mechanism in the dashboard. In the end we decided to force the web interface to update every 10 minute, so as not to overload the cloud with requests.

Future plans for technology improvements:

Edge computing

We could use the edge to run a machine learning algorithm which learn and adjust some relevant parameters like the interval between measurements or the specific weights of every waste type. To achieve the proposed goals, edge computing is the best option because the boards do not have enough computational power or energy to run complex algorithms. Moreover the gateways already have the necessary data and can communicate with the boards to send the new parameters. Regarding a possible usage of the cloud, the measure interval is a parameter strictly related to a bin and it would not make sense sending parameters to the cloud to compute as there's no need to aggregate data.

Replacing the OLED with a e-ink display

To further reduce the energy consumption we could replace the OLED with a e-ink display. This kind of displays consumes a relevant amount of energy only when the values are updated. Indeed, during standby their energy consumption is negligible. Taking into account the update frequency of the display in our system, the e-ink option could be more appropriate.

Charging methods

We could add a solar panel to reduce the size of the needed battery and increase the lifetime. We would not have any problem finding the space to add the panel due to the size of standard bins. More details in the evaluation document.

A different option would be using the energy provided by users pressing on the pedal to open the bin. This mechanical energy could be converted into electric energy using a dynamo. However, even if the frequency of this action is considerably high, the energy produced every time would not be able to support the consumption of the whole system.

Conclusions

Here you can find a video demonstration of the prototype.

Here you can find a video presentation of the project.

Check our LinkedIn profiles:

• Alessandro Marzilli - LinkedIn Profile
• Andrea Mazzitelli - LinkedIn Profile
• Andrea Rodriguez - LinkedIn Profile