a5-015 / ramen Goto Github PK

• Raising an issue on Gitlab to ask about why this is the case and whether it is tunable (https://gitlab.com/painlessMesh/painlessMesh/-/issues/390)

Don't call painlessMesh functions from ramen source. Rather, have an adapter in-between so that painlessMesh can be swapped out for another library down the line.

From the proposal:

For our project, we will generate model networks with 20, 50, 100, 200, 500, and 1000 nodes in areas of 500m^2, 1000m^2, and 2000m^2, for both star and mesh topologies. For each combination, we will run 1000 simulations and gather and study the generated statistics.

Work is being done on graphs branch

• Refactor run_coracle to execute coracle simulator n times in docker command and in parallel
• Move to plotly because plotly 4 > matplotlib !!
• Generate table of results showing mean and variance
• Make a template to generate plot for whatever attribute
• Find a way to terminate simulation processes on keyboard interrupt (phew!)
• Find things to generate plots for
• Generate master script to 1) make test file 2) execute simulator

• Add painlessmesh under MCU
• Redo problem definition so that it is not a solution but actually address a problem - Barkin (trying) (I think Nishant accidentally did this)
• Quantify the number of nodes and connection issues under problem statement - Barkin
• Use consistent terms in blackbox model and pugh chart - Barkin
• Add more pugh charts in relevant section - Nishant
• Fix the microcontroller vs development board confusion in the pugh charts
• Identify clearly the aspect that will be optimized and have it quantified - Nishant
• Breakdown the expected final design into subproblems - Barkin
• Cite examples about drones and consensus algorithms around reference 12 - Barkin
• Make obvious which parts are existing literature and which parts are contributions (bringing it to low-power domain, cite vehicle stuff) - Nishant
• Change name of 5W method - Nishant
• Don't mention wired protocols in networking protocols section - Nishant
• Tighten the language and fix grammatical errors - Nishant
• Itemize the design constraints - Nishant
• Refactor appendix - Nishant
• Refactor references - Barkin
• Spell and grammar check through Grammarly - Barkin
• New figure for final design - Barkin
• Answer more than standard set of questions - Nishant

Just dropping this here as a reminder https://www.eclipse.org/sumo/

• Work Breakdown Structure

• Design Structure Matrix

• Critical Paths

• Gantt Chart

use mermaid.js

• Description of how successful it has been to implement proposed design (proper description of implementation with suggestion for improvement)
• Issues faced during implementation/experiments (identifies issues and why they occured with solutions)
• Changes made during implementation (changes made with justifications)
• Initial results (recorded and explained)

• Evaluation Criteria

• Testing Criteria

I think it would be really cool if we go completely wireless in the final prototype for demonstrating the project (related issue #6). Otherwise, there will be many micro USB power cables connected to ESP8266s. It would look bad and kinda against our low-power consumption ideal/metric.

So, we can design a simple PCB with a few buttons, LEDs, 2xAA battery holder, and female pins for plugging an ESP8266 (and maybe even a small OLED screen?). Later, we can 3D print really simple cases for each of these "node"s.

🍜

• Criteria for testing
• Test data
• Discussion on testing data -- whether design meets requirements or not

• Background Research

• Concept Generation with Morphological Chart

• Concept Selection with Pugh Chart or Decision Matrix

The simulation input for Coracle in JSON format.

Having a bunch of ESPs connected to each other

Propagation of signal from one node to the rest of the nodes

Bringing a new node into the network allows for re-organization autonomously

• Understand what to simulate
• Find a simulator for mesh networking
• Find a simulator for consensus algorithms

A subcomponent of #13

https://gitlab.com/painlessMesh/painlessMesh

As far as I remember, Sundays 3 pm was suitable for everyone.

• Problem Analysis

• Problem Clarification (Black-box Modelling)

• Problem Statement

1. Install Visual Studio Code
2. Install PlatformIO IDE as an extension to vscode
3. Clone this repository and start coding!

Implement something like Chaos Monkey for testing the network resiliency in the catch testing.

• Initial proposed design
• Changes made to the initial design

Problem

sim_config.py uses node IDs generated by network_generator.py. However, since the mesh network generation is probabilistic, not the exact number of nodes are generated in the network.

So, if we want a mesh network of 5 nodes, we may actually end up with a list of node IDs in the network such as:

"nodes": [
            {
                "type": "server",
                "id": 1
            },
            {
                "type": "server",
                "id": 4
            },
            {
                "type": "server",
                "id": 5
            },
        ]

instead of

"nodes": [
            {
                "type": "server",
                "id": 1
            },
            {
                "type": "server",
                "id": 2
            },
            {
                "type": "server",
                "id": 3
            },
            {
                "type": "server",
                "id": 4
            },
            {
                "type": "server",
                "id": 5
            },
        ],

As a result, the events section will look like:

"nodes": [
                    {
                        "id": 1,
                        "active": true
                    },
                    {
                        "id": 4,
                        "active": true
                    },
                    {
                        "id": 5,
                        "active": true
                    }
                ]

but Coracle hates that and crashes when it comes across something like that. Turns out Coracle expects node IDs to be sequential and consecutive...

Potential Solutions

1. Overwrite the node IDs so that it looks like:

"nodes": [
            {
                "type": "server",
                "id": 1
            },
            {
                "type": "server",
                "id": 2
            },
            {
                "type": "server",
                "id": 3
            },
        ]

2. Fill in the missing nodes in the events section so that

"nodes": [
                    {
                        "id": 1,
                        "active": true
                    },
                    {
                        "id": 2,
                        "active": false
                    },
                    {
                        "id": 3,
                        "active": false
                    },
                    {
                        "id": 4,
                        "active": true
                    },
                    {
                        "id": 5,
                        "active": true
                ]

https://github.com/kristianmitk/rasp

The format used in the references is not unified due to copying BibTeX style citations from different places. We need to make sure that they all follow the same format.

We just hit the free 300MB storage limit, it is time for some cleaning!

Create a template class to avoid code repetition in messages.hpp. All the classes have a similar structure so it is quite repetitive

The document compiles, but there is a crazy amount of warnings and errors happening in the background. Overleaf somehow fixes these errors on the fly, but the "code" wouldn't compile outside of Overleaf because of these errors. We need to fix them.

A good read related to this issue: https://tex.meta.stackexchange.com/questions/7898/examples-of-overleaf-users-not-noticing-error-messages

or overflows in a controlled manner

• Modelling
• Simulation
• Optimization Plan / Experimental Plan

https://docs.github.com/en/free-pro-team@latest/packages/getting-started-with-github-container-registry/migrating-to-github-container-registry-for-docker-images

• Technical Constraints

• Non-technical Constraints

• Initial design proposed
• Changes made to initial design
• Basic flowcharts/block Diagrams for software
• Basic PCB schematics + layout