Could we use Nuttx + iot.js as headless platform infrastructure?

#1

Hi, Node-RED community:

I have been looking for a platform like this for some time but got hooked when the first time knowing it.

(or you just want to know what's related to the topic, jump to the bold line)

I had some experiment with ROS (robotic operating system), trying to build some simple sensor with ROS's Arduino/mbed library to publish message into the host, but the process was a pain and the result was a failure. The whole system was built locally on Cmake, and MCU build was also managed by it, which resulting unsuccessful/unknown SPI or I2C connection states.

Maybe it has gone too far to just read some data from a sensor, but my goal was to aggregate different sensors and do my test for algorithm iterations ASAP for a demo. ( combining 3D point cloud from a lidar scanner which I glued from some servo with a stereo camera)

Then the scavaging begin. There was a drone project called PX4 used Nuttx OS for ARM cortex-m series as their autopilot/flight control, I think that was a good idea, so many C program could be reused due to its POSIX interface, and onboard SD card with LFS like FS could make logging program streamlined with ease.

Now I have a glimpse(1 hour without actual testing) how this was done on Node-RED regarding Arduino. OH, NO... I don't think Arduino is my first choice. It has to be compiled and uploaded to get a working firmware first, with the overhead libraries to support Node-RED, and while you will have to cross fingers with the payload code to be working properly. An ideal way to get this done, in my current guess, is to integrate micropython for the payload code, Nuttx for the house management, and some Node-RED interface APP on Nuttx to get the job done.

This could work like gnuradio-companion, or simulink, build a stub on the graph, choose a board, write some (micro)python payload code and run the simulation. Well, we could run the graph and get a satisfying look, thanks to Node-RED's initiative and subtleties, then a js based micropython lexicon scanner could "compile" the code, (or even integrate this micropython vm into Node-RED, and), download this payload "firmware" to the ideal Nuttx board.

A simple graph i am trying to do with my keyboard could be like this:

Nuttx -> micropython -> Node-RED protocol -> Node-RED GUI

As this way we can get some distinctive features not existed yet as reasonable dev cost:

  • easy to port to new MCU/Board
  • standard (Nuttx)APP could be reused for resource-constrained devices
  • firmware dev and platform dev could be paralleled
  • much quicker to do a demo even you don't have the real sensor onboard was prototyped.

thanks for your reading.

#2

To be honest, this sounds like a really complex answer to a problem that is already solved a simpler way.

Why would anyone want to tie such different tools together? This is why we use networking protocols - so that we can maintain separation between tools that can then continue to develop on their own paths but continue to be used together.

Node-RED is not especially good at doing real-time controls anyway which is what I would think you would want in a robotic/drone control system. Maybe I'm not quite understanding your use case.

Node-RED does not provide a "protocol" but rather a comprehensive wrapper around a running app engine (Node.JS). Perhaps with v1 this will change somewhat since I know that Nick plans to get better separation between the admin/development side and the runtime engine. At that point, we will need to see what the minimum runtime resource requirements are, should be a lot less than at present and that may well present some opportunities. But you would still need to have a Node.JS environment which generally implies something more than an embedded microprocessor environment.

In the meantime, as long as your robot/drone isn't too power and weight constrained, I would have thought that the combination of a single-board computer (SBC) such as a Pi Zero with either a nano Arduino (or ESP) or similar would be a much better, more robust and easier to use platform.

An alternative to the use of Nuttx would be MongooseOS which is another RTOS but which supports development in JavaScript as well as C++

#3

A simple scenario you can think of:

Now competitive road cycling need a device to measure cyclists' real time aerodynamic drag, due to sit positions. Some companies are building gadgets for it in prototyping stage. An electrical engineering will need three i2c baro meters with a mechanical designers to implement it. And another software designer to implement ANT+ protocol and Garmin cycling computer APP.

What i want it tmr by myself for this month. I can use three stm32f103 board, flash with nuttx, testing each was working with a I2C barometer, with a small battery, then test BLE with json to transmit that data stream onto a RPi-zero, then build a simple logging program.

Or i want it this weekend. I don't want to wait for the sensor and MCU board to ship to begin this project. I just use my imaginary platform with modules and libraries to stub the sensor module in a physical simulation environment, testing sensor configurations, when i get a working simulation, i just ordered my specific sensors with MCU fanout board, meanwhile, refactoring the code.

THIS IS WHY: All i have to do was choose modules, write logic code, test mathematical model, maybe more write a stub bike power meter code with, but all under the same roof, simple python. which i could just download pyc files and run them on the real device when the parts are delivered: i just hook them up and use some duct tape, with a beer in my free time.

If i used RPI I think I will give up just by waiting for it boot up for the 3rd time for checking the fault I2C wiring...

Thanks for your input, I really need to take a deep dive into Red-Node to see how it could be done.

#4

OK, I still think that you might be over complicating things. Sounds like you have the sensor part in hand. All you need to do is decide a communications standard between the MCU's that the sensors connect to and then consume that using your Pi with Node-RED to help.

The best approach will come down to how much data you need to capture and how quickly you need to process it.

I'm certainly not the worlds greatest expert on this stuff but I would probably use some ESP32's as MCU's as that gives you the option for BlueTooth as well as Wi-Fi. You could even capture your data locally if you can process it later rather than realtime.