Making Node firmware Independant of Hardware - Node Configurator UI

[martinglass]

In the Node code, there’s a concept called MultiNode, actually MULTI_RHNODE

I’ve got two conceptual issues with this: 1) it’s a possible source of confusion to call VRXs nodes and MPUs nodes. They should have different monikers. The MPU is actually the node, as it’s defined under the folder name ~/src/node. The VRXs should be called something else, like RSSI_Detector, or RSSI_Sensor (Or VRXs are called nodes and MPUs are called something else) 2) Some (if not many) of the things now in ~/src/node/config.h would be better moved to a node_config.json file under ~/src, or in Cerb’s terms inside the database itself. At least it should be in a place that the user can configure more easily.

As such, many of the thing, if not (almost) all of the #DEFINES in config.h, but certainly including Variant, Max Nodes, should be taken out and put in a ~/src/node_config.json file.

That way, there can be a universal node firmware, independent of hardware.

That opens up a way to envisage a future where the User can set the node configuration on a Webpage, using a Node Configurator UI, which is impossible under the existing Node Firmware.

[pulquero]

Note: MCUs are referred to as node managers, and vrxs as nodes throughout the python code.

[martinglass]

That may be true for Python but I don’t see that elsewhere. In fact I hardly see any mention of any such thing as “node manager” at all, neither in the code nor the docs. The only place where a text search among the node-folder comes up with a find for “manager” is in MQTT (eg MQTT_TOPIC I believe the word node has been used as an abbreviation in place of node-manager too often, eg USB Node, NODE_RESET_PIN etc For example, the README.md file says “ The src/node directory contains the source code for the RotorHazard nodes. The same code may be used on Arduino nodes, or on an S32_BPill multi-node board.” Again, eg, the folder ~/src/node isn’t called ~/src/node_manager

[HazardCreative]

See https://github.com/RotorHazard/RotorHazard/issues/478

[martinglass]

Having second thoughts on this. Even though the principle idea is sound, but many of the compiler Defines (like VARIANT) are necessary for compiling the code.

However, I am still okay with the principle, that as much of the configuration as possible should be taken out of the node firmware and put in the server, where users can configure the node manager and the nodes, more than just assigning frequencies - things like the number of nodes/VRXs to use. Variables, such as the type of Variant, can also be communicated from the node manager to the sever upon connection.

This could enable facilities like plugable node managers and nodes, eg USB, Wireless (WiFi) and Wired Ethernet node managers.

[martinglass]

See https://github.com/RotorHazard/RotorHazard/issues/478

Thanks for the reference. The server-side Node Configurator could link in with the concept of seats and nodes.

It's worth looking at the Race Explorer code. Differentiating nodes and seats is an integral part of the Race Explorer (ReactJS) development.

[martinglass]

More thoughts: The node manager firmware should be able to accept any combination of nodes, so the nodes can be physically changed at will, without having to burn new firmware on the node manager. At present the Firmware attempts to detect nodes by physical connectivity, but it's better done in software, as it removes the need for extra signal wiring.

For example, with the STM32 board, a user could configure / assign the number of nodes.

Also the user could assign the number of frequencies that any node can scan, via a server based Configurator, independently of the node manager firmware, just like the user can assign specific frequencies now.

Moreover, there may be things between the node manager and server, like the IP address of the node manager or server, or whether the manager should switch from serial to Ethernet/WiFi, that can be configured on the server (I thinking ESP32 and the like, where WiFi is integrated into the MPU)

[HazardCreative]

Let me restate and see if we're clear.

• Seats are pilot slots in a race heat that can be assigned a frequency. Seats can have no pilot assigned, and can also be disabled by setting a frequency of none.
• Seats are provided by node managers. A node manager generally provides one seat per node. However, a manager is allowed to provide multiple seats per node by frequency swapping, or use multiple nodes per seat for error checking/improved accuracy
• Nodes are hardware receiver modules that are tuned to detect a frequency

If I have this right, then:

• Seats must be UI-configurable and already are. (frequency)
• Node managers should be UI-configurable, but the settings can be less easily changed than for seats. (seats per node) Node managers could potentially be disabled, but it's not strictly necessary since seats can be disabled.
• Nodes should be detected based on the hardware environment of the manager and reported to the user near the node manager configuration area. Number of nodes need not be configurable because seats can be disabled.

Software-based configuration instead of hardware detection often requires the end-user to make challenging and unfamiliar configuration choices. We need to eliminate this as much as possible, or simplify the options to a basic UI.

This is a separate issue, but seat properties should somehow be reported to the user. Accuracy of poll rate and history collection are both very important to the RD. I'm mentioning here because managers may also need to provide a "seat type" so that seat-specific parameters can be adjusted (Example: RH vs. LapRF calibration)

[martinglass]

Let me restate and see if we're clear.

• Seats are pilot slots in a race heat that can be assigned a frequency. Seats can have no pilot assigned, and can also be disabled by setting a frequency of none.
• Seats are provided by node managers. A node manager generally provides one seat per node. However, a manager is allowed to provide multiple seats per node by frequency swapping, or use multiple nodes per seat for error checking/improved accuracy
• Nodes are hardware receiver modules that are tuned to detect a frequency

If I have this right, then:

• Seats must be UI-configurable and already are. (frequency)
• Node managers should be UI-configurable, but the settings can be less easily changed than for seats. (seats per node) Node managers could potentially be disabled, but it's not strictly necessary since seats can be disabled.
• Nodes should be detected based on the hardware environment of the manager and reported to the user near the node manager configuration area. Number of nodes need not be configurable because seats can be disabled.

Software-based configuration instead of hardware detection often requires the end-user to make challenging and unfamiliar configuration choices. We need to eliminate this as much as possible, or simplify the options to a basic UI.

This is a separate issue, but seat properties should somehow be reported to the user. Accuracy of poll rate and history collection are both very important to the RD. I'm mentioning here because managers may also need to provide a "seat type" so that seat-specific parameters can be adjusted (Example: RH vs. LapRF calibration)

I think it's best that Mark replies to this, but my response is this:

What you've said is very good but I would correct one aspect, IMHO - HazardCreative said: "Number of nodes need not be configurable because seats can be disabled".
I'm not sure that's right, because ...

• It's important to differentiate between frequency and node. Seats have a frequency, not a node. You can have one seat and several nodes on the same frequency, for example. You started out by saying "Seats are pilot slots in a race heat that can be assigned a frequency", where you used the word frequency, not node. That's an important (correct) choice, because although the node gets assigned a frequency, the seat is related to the frequency (and pilot/team) not the node - another node could be used if one fails, for example. I think of it this way - the frequency is what the pilots need to tune into their quad's VTX; whereas the node tunes into the frequency(s) allocated to them by the Server UI (via the Node Manager). The Seat is related to the Pilot and the Frequency; the Node is allocated a Frequency only (not a pilot).
• Similarly, the number of seats can be fewer than the number of available nodes - eg if some nodes are not being used.
• The max number of nodes (or more precisely the max number of frequencies available) is required to ensure that seats aren't allocated to non-existing nodes/frequencies. In the latest version of the Race Explorer, it appears that there can be seats with pilots allocated, but without any frequency assigned. That may be an error, or there may a reason, but I noticed that and I'm not clear about it myself.

One thing I would add is that the system needs to be able to manage team races - where a single Seat is used for the "Team", and several pilots each get allocated to the Team. The easiest way to accomplish this is to call the "Pilot" in that seat by the Team name, but that falls short because everyone needs to know which pilots are in which Team, and also what order the pilots go within the Team race.