acesrg / remote-control-lab Goto Github PK

Hacer una tarea que lea dos variables globales y las publique por uart.

Since this board supports over the air programming it would be very usefull to enable this configuration. When connected to the setup, the OTA comes in very handy.

bschwind uses and old version version of esp-open-rtos, new version has much more features. Rebuild docker image.

Set up a local runner to build and flash CI projects. Documentation is key in this step, since in a (hopefully) near future the laboratory runners must be set up.

Gitlab runners will be used, Gitlab-CI is free for external open source repositories. It has a lot of advantages compared to Travis, and im also sort-of used to it.

Requires

• Basic release of -software-control-package-

Test

• Commms
• Encoder read
• Propeller

Decide how to communicate the tasks and the websockets. Draw the threads and communications diagram.

Result
Comms explained and drawn in the wiki.

Add (copy) some basic example project, maybe an http server to get started.

This example should be compliant with esp-open-sdk.

Goal

The data will be stored in static structures, but is transmitted as a json. Research for a possible library to parse this. See JSMN.

Do all the parsing work and write some tests doing an operation and re-sending data.

Background

To this date, the remote-control-lab API is quite messy. It consists on passing variables inside jsons, that will change depending on the opened uri of the Websocket.

The json-coded variables don't seem off, but the idea of the communication behaving differently for each uri does ring a bell. This data-flow should be, ideally, uniform.

Before firing with ideas, lets set the boundaries.

Requirements

• A lighweight communication protocol. (must fit in ESP8266)
• A scalable protocol. (Needs to work almost without modifications for other subsystems)
• Ultra Low latency for sensor-actuator stuff. (how low? whats the control system limit?)
• Normal latency for configuration and set-up.
• Reliability for configuration messages.
• Some reliability for high frequency messaging (like actuator-sensor stuff)

Nice to have

• ReSTful.
• Standard.
• Testable.

What needs to be done

Do the necessary research to define an API that fulfills every requirement, or the closest one.

Write a POC.

Goal

Create the project skeleton as shown in the following sequence diagram. Create endpoints for the database interaction but don't interact with said database.

Assume that the client communicates with a frequency of 20 Hz.

Tests

• Threads started (specially the one created by the uri)
• Endpoints
• Frequencies

TODO: description

Add the pwm writing endpoints.

TODO: description

Description
For simplicity and testing add a /ping option to the websocket communication and test it.

Replicate

in one terminal

make flash
make monitor

in the aeropendulum directory:

python3 -m unittest discover -v -s tests/

Run the former command multiple times

Behavior

Sometimes comms stop, another times, the uri is unrecognized

Add a firmware flash CI job for the ESP8266

When creating a task, after several calls to websocket_write (inside a task, not a callback) the communication is aborted, and the program appears to fail creating the new task according to the selected uri. A change in the quantity of attempts was observed.

With 256 stack each task, the problem presented itself after 15 calls. With 1024 stack each task, the problem appeared after only 4 calls (the pattern is clear). This was independent of the not-websocket-calling task, which continued to work flawlessly, regarding of the problem on the other tasks.

Tenemos al pin D0 como una salida digital, y al pin A0 como entrada analógica.

Asignarlos de esta forma apenas se inicialize el código.

Add a code-quality job. I only know pep8.

• Research if it's good for C
• Implement a Job in the pipeline

What needs to be done

The embedded system should control the operative restrictions of the dynamic system, such as: maximum PWM values, range of the pendulum, etc.

How can it be accomplished

• Research, what are this values that we want to restrict.
• Enable some basic firmware restrictions, at first the limits will be hard-coded.
• Define and document in the wiki the limits and the actions that are taken when limits are surpassed.
• Specify how this values can be customized, implement some configuration (maybe via HTTP with firmware defaults).

• Implement a Job on the pipeline to make the doxygen docs.

• Publish them automatically, after each merge to master.

• Write the missing docstrings, fix the ones that aren't working.

Background

In the simple_json_compose strcat is being used a lot. According to some sources, snprintf is better than strcat for most purposes.

The case of use is the following.

ParseRvType json_simple_compose(char *result, SimpleJSONType *inputs, size_t len) {
    result[0] = '\0';
    snprintf(result, JSON_SENSOR_MAX_LEN, "{");
    for (int i = 0; i < len; i++) {
        char stringed_pair[TOKEN_NAME_MAX_LEN+TOKEN_FLOAT_MAX_LEN+8];
        snprintf(stringed_pair, JSON_SENSOR_MAX_LEN, "\"%s\": \"0x%04X\"", inputs[i].name, inputs[i].value);
        strcat(result, stringed_pair);
        if (i != len-1) {
            strcat(result, ", ");
        }
    }
    strcat(result, "}");
    return PARSE_OK;
}

Checklist

• Research about the difference between strcat and snprintf.
• If it's worth it, refactor to use snprintf.
• Remove the filter -runtime/printf in CPPLINT.cfg

Use the bschwind building environment in a basic .yml to build example code.

Write a nice readme with compilation instructions and goals of this repo

The error debug prints are ok, but a logger would be much better.

leave only the required suff for the http communication to work

Currently the system supports sample times of approx 30ms. Research if a sample time of 50 ms would be ok for this systems or is to little.

The current systems to support are:

• Aeropendulum.
• 4 tank system.
• Heat transfer system.

Create a containerized building environment for the ESP8266 (version D1 mini).

Required tools:

• esp-open-sdk
• esp-open-rtos

Add the part of the communications that reads and writes to the database. Use mutexes to avoid multiple access.

Tests

• Endpoints
• Multiple access