[HN Gopher] Interfaces for prototyping hardware
___________________________________________________________________
Interfaces for prototyping hardware
Author : zdw
Score : 42 points
Date : 2023-09-03 13:26 UTC (9 hours ago)
(HTM) web link (kevinlynagh.com)
(TXT) w3m dump (kevinlynagh.com)
| jauntywundrkind wrote:
| The Greybus project around UniPro interconnect has a lot of
| hallmarks of this all. And support is built right into the Linux
| kernel; peripherals just show up right away! You don't need
| libraries at all. https://kernel-recipes.org/en/2015/talks/an-
| introduction-to-...
|
| Mostly died with Google's Area modularized phone. But we see some
| occasional projects float around using the tech. This one just
| uses Greybus for IoT but has a totally different made up
| transport over 6lowpan. https://zephyrproject.org/using-linux-
| zephyr-greybus-for-iot... https://www.zephyrproject.org/blink-an-
| led-using-linux-zephy...
|
| This was the basis for a BeagleConnect product where a uC's
| peripherals like spi/i2c/own/uart/ADC/gpio could just show up on
| your Linux host like regular devices.
| https://docs.beagleboard.org/latest/boards/beagleconnect/tec...
|
| The BeagleConnect docs lightly mention using the _excellent_
| node-red to interface with these devices, as though they were
| just local devices.
|
| It seems like such brilliant technics; I wish I could envision a
| significant mass of people really taking up & adopting something
| like this.
| lockhouse wrote:
| [flagged]
| joshuanapoli wrote:
| Check the FAQ [1]. You can send an email to email
| hn@ycombinator.com asking for deletion.
|
| [1]: https://news.ycombinator.com/newsfaq.html
| lockhouse wrote:
| [flagged]
| couchand wrote:
| An interesting discussion of ideas for prototyping hardware
| interfaces with web UIs. I appreciate the author's discussion of
| the design space.
|
| Given the introduction, I'm suprised the author didn't mention
| another option. They talk about the limits of hand-writing the
| web UI for such prototypes. I wonder if components could be
| extracted from earlier prototypes to save time? Hand-rolling
| everyting would be tedious indeed, but slapping together a
| handful of previously-written controls would make it easier. The
| don't need to be slick or cover every use case, just scrappily
| abstracting the repeated lines of code.
|
| Or maybe the author has already reached the limits of that
| strategy, hence the goal to generate a UI.
| dazhbog wrote:
| Working on a similar project[1] that its similar to a PLC but its
| low power, with a solar panel and it has plug and play modules
| (see link with animation). We are trialling it now with a few
| customers and planning to open-source it. Trying to get the OTA
| working and the manufacturing sorted..
|
| [1]: https://deeporbital.com/iot-gateway
| vvanders wrote:
| If you're going to be installing anything in adverse environments
| or for any period of time PLCs are the go-to for a lot of one-off
| solutions. Some of them get pretty spendy quickly but Automation
| Direct has some reasonable($100-200) PLCs[1]. I ended up
| automating our entire greenhouse with one including a PID based
| water pump to drive a bunch of different downstream outputs that
| worked really well.
|
| [1]
| https://www.automationdirect.com/adc/overview/catalog/progra...
| sheepybloke wrote:
| I found creating a small Python webserver using Starlette plus a
| basic CLI using Click to be great for interacting and testing
| hardware. Python gives you an easy way to integrate with your
| actual code on the hardware using whatever interface you need
| with its wide support of different protocols. Click gives you a
| way to create a robust CLI for interacting with your Python code,
| and Starlette gives you a way to create a really lightweight but
| extensible webserver for both simple and more complex GUIs. Then,
| you can even add pytest on top of that for integration tests.
| Overall, I'd highly recommend this setup for hardware
| prototyping.
| flyingcircus3 wrote:
| I've used click, and I've used argparse. In my view, a
| nonstandard library needs to be vastly superior to its standard
| equivalent to justify adding it as a dependency.
|
| Why is click so much better than argparse?
| [deleted]
| 0x174 wrote:
| I'm curious on what the value of a frontend would actually be on
| this kind of project and where it is in the engineering
| lifecycle. I've worked in the same space on instrument control
| software (microfluidics, synthetic biology) and I feel like what
| you would gain for, as an example, putting a slider on a flow
| rate is of minimal use to the development of the instrument,
| especially in an ad-hoc iterative environment.
|
| The engineer who is writing this software and building the system
| in tandem will be able to express most of their
| experimental/engineering needs via a CLI tool and something that
| visualizes instrument state and sensor readings. For example,
| I've gotten quite a bit of mileage out of throwing Grafana as a
| graphing interface and then using ipython to essentially have a
| REPL to control logical subsystems, such as a pump or a motor.
| This allows you to interrogate the empirical limits of your
| system without having to spend time centering divs or caring
| about button placement.
|
| This is only true if the engineer is the intended end user of the
| system. As you scale out and include other disciplines in the
| project you do have to consider the user interface as the window
| into the instrument.
|
| I've played with the automatic GUI element generation from
| parsing the underlying control code before. I think its a fun bit
| of meta problem solving, but I've always ended up in a corner
| that requires some sort of bespoke tool or widget to solve a
| tricky problem arising from the scientific domain. I think you
| might be fine if all you are doing is controlling a syringe pump
| or similar, but as the experimental needs become complicated
| you'll end up re-writing the control interface as a deliberate
| experience and toolbox.
| snops wrote:
| Some other existing options in this space (not all web based) are
|
| - https://pymeasure.readthedocs.io/en/latest/ python Framework
| for running science experiments, getting hardware to go through a
| set of steps and plot the output. Includes a GUI.
|
| - https://plotjuggler.io/ for really fast live time series
| plotting in C++/OpenGL, very fast and quick to chuck data at
| (just wrap it in JSON and throw over UDP) but lacks any form of
| input. Ideal for systems running at kHz etc, I've used it to tune
| motion control systems.
|
| - https://foxglove.dev/ aimed solidly at robotics (think self
| driving vehicles) renders time series plots, 3D renders and point
| clouds, log statements etc, and supports inputs too. All written
| in HTML and you can write extensions for it. Unlike others, it
| can support a much larger data file on a server and live stream
| the bit you are currently viewing to your browser. Not as fast
| for smaller things though.
| contingencies wrote:
| "Gee - hardware is fragmented, complicated, and quickly gets
| expensive outside of simple scenarios". Yeah, it does.
| the__alchemist wrote:
| They're using Rust, which is a great language for this sort if
| hardware: It can run on hardware itself, and can make responsive,
| PC applications to interface with it. Perfect excuse _not_ to use
| a web UI, but this article is demoing one anyway.
|
| EGUI is ideal for this sort of thing. Can make hardware
| interfaces (eg using USB as a serial port or HID device) into a
| fast GUI program. Add WGPU if you need anything 3d rendered.
| Onavo wrote:
| I am surprised that GP mentioned LabView but not Simulink.
| Simulink is the workhorse of signal processing research.
| binarycoffee wrote:
| While I have frequently seen LabView used for
| instrument/hardware control, I admit I have never seen people
| use Simulink for that purpose. Is there a popular
| Simulink/Matlab add-on for that?
| thomasthorpe wrote:
| It can be indirectly. Addons exist to for instance convert
| the mathematical models described in Simulink to code (C,
| VHDL..) deployable to hardware targets. So, algorithms can be
| developed in simulink and then integrated into an embedded
| application without manual translation.
| donquichotte wrote:
| I have worked with a very similar setup to prototype devices for
| a customer. One of the peripherals controlled was also a pump and
| interestingly, our interface looked almost exactly like what is
| being proposed here.
|
| In terms of hardware, I can highly recommend Tinkerforge [1].
| They support a wide range of sensors and actuators and can be
| controlled either via USB from a computer (all major platforms
| and many programming languages supported) or, for standalone
| devices, with an ESP32-based base-board called ESP32 Brick or
| ESP32 Ethernet Brick.
|
| Since their products are open source (code AND schematics!) a
| design can be easily transferred to a custom PCB once the design
| is working.
|
| Add either a web interface (native on the ESP32 or on your host
| computer if using a USB brick) or slap on a DearImgui frontend,
| and you have very powerful prototyping platform at your hands.
|
| [1] https://www.tinkerforge.com/en/
| picture wrote:
| See iomixer, which seems to cover this niche exactly
|
| https://iomixer.com/overview/
|
| https://iomixer.com/configurator/
| BeefySwain wrote:
| Is this something that is available to purchase?
| picture wrote:
| Not yet
| [deleted]
| varjag wrote:
| _Please convince me not to start this._
|
| OK I'll bite. The project has scope that is too ambitious and is
| in the domain you have poor understanding of. The odds of failure
| are overwhelming.
|
| On the other hand, checking your hubris the hard way is a
| decently reliable method to grow professionally, so...
___________________________________________________________________
(page generated 2023-09-03 23:01 UTC)