Open austinstover opened 6 years ago
Fork it.
Your problem now Mr. Systems Team Lead
Ok... ok... I'll look into this eventually
That would be awesome!
I'm probably just going to start an entirely new project coded from scratch that should work wirelessly as well, we'll have to see. It's kind of overkill to be using an Arduino if we're just using it for ADC, and making everything go through a serial connection probably makes it slow. Much easier to just have a GUI which saves settings for what different inputs on an SPI ADC board correspond to and plots them. This also has the added benefit of letting us use 16bit ADC boards which will really increase the resolution, 1024 distinct values isn't that much in terms of accuracy, 65536 is quite a bit better (or rather, 6 bits better...). I'll probably have stuff log to an SQLite database and use stuff like pandas, flask, and plotly to organize the data and visualize it in a webpage, everything can probably be run on a simple raspberry pi zero W. This also allows us to add stuff like pitot tubes or GPS for ground speed if we so desire. Now just to find some time. I've done all of this before it just takes a while to implement in a way that's clean (I'd like to design PCBs with pads for all these things) so it might take a while. Maybe if I'm not too busy this summer.
While using Flask really would be nice, Christophe, the Arduino isn't actually being used as an ADC. To interface with the thrust sensor, we are already using the much superior 24-bit HX711 ADC, so the scale is limited not by its precision, but its accuracy. The Arduino also outputs thrust values to an LCD screen, which proved convenient during actual thrust testing, and receives data from a (currently buggy) separate Arduino nano running a tachometer (now that seems like overkill to me, but I see no other easy way of running a tachometer with custom filtering--although it might be useful to replace the nano with the faster Adafruit feather, and use an SPI interface instead).
The real problem with this app, though, is not the UART Serial interface (which can still be pretty fast) but with the lethargy of the graphing apparatus. We just need to use a different library for graphing: PyqtGraph.
Yeah, I was thinking about the current and voltage sensors which could probably use a bit more than a 10bit reading. A raspberry pi/other random linux microcontroller can also drive one of those screens though and run a webserver at the same time, the disadvantage is it is indeed much more complicated in terms of booting up and shutdown (whereas you can just yank an Arduino to no ill effect). The advantage though is that you get a self-contained apparatus which serves high quality graphs wirelessly. It should be easy enough to fork this project to support pyqtgraph so you can most certainly do so, but I'm not sure that it's worth it in my eyes to have better real-time graphs without a major rework given the fact that everything should hopefully be logged to CSV now (I have no good way to test it but it's an easy fix). Using something like plotly and dash would allow you to serve a flask app (maybe even embedded in a tkinter frame) which will look much cleaner, be more responsive, and should be easier to maintain since a lot of the code in the current software is setting up buttons whereas plotly uses HTML.
System information Occurs whenever you try to use the app to actually gather data OS Platform: All Install: All Exact command to reproduce: Use the software
The data just doesn't graph quickly enough to provide a good visualization of the data incoming from the sensors--it graphs at maybe 2 Hz.