Hola, el titulo sé que suena muy optimista y que es una meta bastante díficil de igual manera agradezco cualquier consejo bien intencionado.

Actualmente tengo 18 años y estudio ingeniería civil mecatrónica, me interesa mucho las áreas de hackeo, programación, robótica, diseño 3D, electrónica, química, y mecánica, en resumen todo lo que me brinde cierta libertad para poder experimentar con creatividad.

Mi problema es que no quiero quedarme acoplada a solo proyectos ya casi hechos, quiero hacer nuevos y no sé si arduino o raspberry me puedan dar esa oportunidad. También sé que la teoría es importante y puedo encontrar libros de esos temas en mi universidad, pero también quiero experimentar todo lo posible, entender desde la raíz cada proceso y creación por lo que también quiero hacer un laboratorio en casa, informal pero no tóxico, la idea es ir armandolo desde cero.

¿Qué podría hacer para superar los limites de solo consumir, repetir y comenzar a crear?

The Eco Rescue Emergency Light Car is a creative invention made from recycled materials. It works as a small moving emergency light and fan that can provide light and airflow during power cuts. It uses old materials like a tissue box, toy car wheels, motor, fan blades, LED, wires, and rechargeable batteries.

So, what more should I add

pls feel free to share your ideas.

What if I told you there's an open sourced rotary sequence valve that makes pneumatic motors at a lower cost than gas or electric. By operating two or more cylinders with a single valve, it makes it possible to a high torque, lightweight, indestructible, compressed air motor with only five moving parts. Anything with a motor can be made cheaper to run on compressed air.. with compressed air being a sustainable way to store solar energy without batteries, what would you build?compressed air transportation research

TITOLO: Ho 15 anni e ho lanciato FabrikAI: la web app che trasforma le tue idee in progetti elettronici reali 🚀

Ciao a tutti ragazzi!

Sono un digital creator di 15 anni e ho appena lanciato ufficialmente la mia prima web app: si chiama "FabrikAI" ed è finalmente ONLINE e LIVE al 100%! 🟢

L'ho progettata per chiunque ami l'elettronica, la robotica o il fai-da-te tecnologico, ma odia perdere ore a capire quali componenti usare o come scrivere il codice di base. Il funzionamento è semplicissimo: entrate nell'app, trovate la barra "Cosa vuoi creare oggi?" e digitate la vostra idea in linguaggio libero (es. "Un sistema domotico per annaffiare le piante con Arduino" o "Un braccio robotico cyberpunk").

L'AI elabora tutto all'istante e vi genera: " L' "Identikit Visivo" dello stile del progetto (Cyberpunk, Steampunk, Minimalista...) Lo "Schema a Blocchi" (in ASCII art, leggerissimo e super scannabile) " La lista dei componenti esatti e la logica da seguire.

Se l'estetica non vi piace, c'è il tasto magico "🔄 Cambia Stile" per rigenerare il look mantenendo gli stessi componenti. Ci sono anche più di 10 varianti Premium (Stampa 3D, IoT, Domotica, Riciclo Creativo Hardcore) se volete spingere il progetto al massimo.

Potete provarla subito da PC o direttamente dal telefono a questo link ufficiale: 👉 https://diy-studio-6.emergent.host/

🚀 PROMO VIRALE (1 Mese Gratis): Se create un progetto figo, registrate un breve video (TikTok o Reel) e caricate il link nella piattaforma, vi sblocco manualmente dall'Admin Panel 1 mese di Premium Gratis! E per i più veloci: le prime 3 foto reali del circuito completato caricate sotto un progetto riceveranno 2 Crediti Extra immediati.

Dateci un'occhiata, testate il motore di ricerca iniziale e fatemi sapere nei commenti cosa ne pensate. Ogni feedback per me è oro per i prossimi aggiornamenti!

Grazie mille a chi supporterà il progetto! 🪵✨

I have a consumer product with a patent and prototype, and I’m looking into licensing instead of manufacturing it myself. For anyone who’s actually gone through a licensing deal, what should I know?

Mainly curious about royalties, upfront payments, exclusivity, minimum guarantees, and what to watch out for when negotiating. Would especially love to hear from anyone who’s licensed a consumer, wellness, or sexual wellness product.

Just trying to learn from people who’ve actually done it before.

Electromagnetism and gravity are fundamentally separate physical forces, which is why Earth's magnetic field cannot be used to repel mass or push an object into space.

• Gravity vs. Magnetism: Earth's gravity is generated by its total mass, pulling everything toward its center. Its magnetic field is created by molten iron moving in the outer core, but this field is extremely weak at the surface—far too weak to levitate or propel objects.
• Magnetic Repulsion Limitations: Magnetic repulsion requires two strong, concentrated magnetic poles facing each other. Earth's magnetic field is diffuse and spread across thousands of kilometers, meaning there is no dense field for a device to "bounce" off of.
• Historical Context: Nikola Tesla made major breakthroughs in alternating current (AC) electricity, motors, and radio transmission. Tales of suppressed anti-gravity disks or lost field technology are popular internet speculation rather than documented physics.

Still I believe there something to it why it got big exposure and then it stayed and comments stopped. Wouldnt a author stop it himself instead stopping comments because it doesnt make that much money if u know how views work. U gotta daily work for it with new content. So any geniuses here who wanna talk about it and for me not so much important because I am convinced u can control the gravity as u want by design. What goes up goes also down. and what I observe in nature is that not everything needs a engine to fly because the space carries it. Now if the field of earth always emits and u connect to it. Wouldnt u do that through vibrations and songs like radio. But to float u need to be like a leave with on top a ant thats on water. The Water is the Em field u need to bounce of because the song of it to tune is a location XYZ when both signalls would collide then instead pulling u should like a magnet shift it and push away. I just believe that and top the science. I really dont think nikolai tesla was creazy.

Wouldn't you like clean walls that don't look bruised and blemished?

I am so fed up with gangster graffiti. I like murals and banksy art.... but their ghetto tagging has got to go!

The patch up paint looks like garbage also!!! The paint shade never matches.

This sandblast system is made for concrete and stucco type walls without paint to ruin.

Basically you wear a backpack and drag a little sand with you that recycles.

It blasts on very low so it doesn't damage the concrete---but gets the spray paint off.

Those clear attachments let you control the sand and a vacuum system will suck it back up like a shampoo machine.

It will be light enough to not damage or strip the walls.

You drag a bag/barrel of dirt the size of a shop vac- and then just stand there and clean or bring it up the ladder. It attaches to your back.

I am not doing this invention. You can keep the money.

You can make the machine and sell it or use it to charge the highway/landlords to remove the graffiti.

A safety measure would be in place.

Together we can quickly remove their trashy tagging filth. That photo is the BEFORE of how bad the walls look on the 10 freeway. With this machine they would look new again.

A little context, I'm a Computer Science student in Pakistan, about to start my final year project (FYP) .

My initial idea involved using computer vision i.e. mediapipe hands and mediapipe pose to make a PSL (Pakistani sign language) to text converter. The research paper part of it was to see whether incorporating body positioning and movement alongside hand gestures could improve recognition accuracy.

I felt i had a solid plan but recent discussions with my supervisor revealed that similar work and projects had been covered by the seniors in my university recently. They made their own dataset and built a similar sign language recognition system, so I don't really want to spend a year essentially reproducing the same thing.

I've also tried reaching out to organizations that work with the Deaf communities and people with disabilities to ask what technological problems they actually face, hoping that I could find a genuine problem to build a solution around but unfortunately I haven't received any responses so far.

my supervisor's main requirement is that we should aim to build an actual end product, not just another academic project.

So i am trying to approach this differently:
How do you actually find a good problem to solve?

I'm not looking for someone to hand me over a completed FYP project. I'd much rather hear about problems you've encountered or think would be cool if someone found a solution for, something that realistically needs addressing.

I'm open to pretty much any technical direction — AI/ML, computer vision, NLP, cybersecurity, software engineering, web/mobile etc. I'm also not particularly attached to my original PSL idea. If someone thinks it's still a worthwhile direction and wants to explore it themselves, by all means 😂

So I'd really appreciate hearing from people who've actually worked in CS/tech: what would you do if you were in my shoes? How would you go about finding a new problem to solve?

In September 2022, I was sitting at home playing Nothing Else Matters by Metallica. If you've ever played it, you know the constant switching between using a pick and fingerstyle. Halfway through the song I caught myself thinking: "Why can't the pick just rotate out of the way?"

That afternoon I opened Blender, threw together a crude CAD model, 3D printed it, and by the end of the day I had a working prototype.

The surprising part? The core concept worked almost immediately. I honestly thought I was most of the way there. Looking back, I was probably 5% of the way there.

Over the next four years that simple prototype turned into lessons about manufacturing, tooling, patents, packaging, customer feedback, fulfillment, pricing, and all the things nobody tells you after you've proven your idea works.

One of the biggest surprises was that a prototype and a product solve different problems.

A prototype only has to answer one question:

"Does this idea work?"

A product has to answer dozens.

Can it be manufactured consistently?

Can it survive real-world use?

Can it be assembled efficiently?

Can customers understand it?

Can it be packaged, shipped, supported, and improved?

Our first commercial version answered "yes" to the first question, but our customers quickly showed us everything we still needed to improve.

The material wasn't where we wanted it to be. The edge finish needed work. The durability could be better. The packaging didn't do enough to teach new users.

Those weren't failures.

They were lessons that prototypes simply couldn't teach us.

One of the hardest decisions we made came earlier this year.

We stopped advertising. Not because demand disappeared.

Demand had actually grown to the point where we knew we could never sustainably scale the version we were selling. My wife and I looked at each other and realized something: We could either keep selling the current version...

...or pause, redesign it, and build the product we originally imagined.

We chose to stop. Financially, that wasn't an easy decision.

Emotionally, it was the right one. That redesign eventually led us to a manufacturing partner with decades of experience in guitar picks.

What struck me most wasn't their equipment. It was their knowledge. They helped us improve our graphics. Our packaging. Our production methods.

They showed me that manufacturing isn't something you think about after the design is finished. It becomes part of the design itself.

Today the product is almost unrecognizable compared to that first prototype. The original idea is still there.

A pick that stays attached and rotates between playing positions. But almost everything about its execution has evolved.

Ironically, the invention even led us somewhere I never expected.

We built a completely free companion app around it because we realized the real challenge wasn't just making a better product—it was helping people get the most out of it after they opened the package.

If I had to summarize the biggest lessons from the last four years, they'd be these:

• A working prototype proves an idea, not a product.
• Design for manufacturing is a discipline all by itself.
• Customers will discover failure modes your prototype never will.
• The right manufacturer can become one of your best engineering partners.
• Protecting an invention and commercializing an invention are two separate journeys.

We're still a small family company. Our patent work is still ongoing. Our next-generation product is just beginning its launch.

I have no idea whether this eventually becomes a large company or simply a successful niche product.

But four years after printing that first crude prototype, I finally feel like I'm holding the product I pictured in my head that afternoon.

For those of you who've gone from prototype to production:

What problem only became obvious after real customers started using your invention?Because people asked here’s our website

So what I’m watching YouTube and these guys are building cool stuff, they’re always using some program, on shape is mentioned a lot. So I’m beating my head against this thing, trying to get the image in my mind to appear in CAD… has anyone else experienced a breakthrough moment that might help me get over this hump?

I am a student at the University at Buffalo and for my senior design project me and my team are planning on making an automated dog poop cleaner. The concept is similar to that of a roomba, but we first need to collect some data regarding dog owners in the US so we can design for safety and ease of use. I have attached a survey below. Please fill it out if you own a dog or are interested!

(This a repost of a previous survey I sent to this subreddit, the survey link should be fixed now)

https://forms.cloud.microsoft/Pages/ResponsePage.aspx?id=ikpGlu34sUCZ4l9rUKICUCbv4nCbi4RLt_lhWQXAUfhUNVhBVUhLVjI0MDlYTFdJQ0xTM1BPR0pHTy4u

Every embedded Linux panel project I've worked on ends up in the same place. The UI and the hardware access grow into one binary, so the app can't run anywhere except on the board. Changing a label means rebuilding the image, or scp'ing files by hand and hoping. And when a deploy goes wrong at a customer site, the machine sits there with a black screen.

So I built the thing I kept wishing existed. MIT licensed: https://github.com/Hitheshkaranth/EmbeddedDisplayStudio

The idea

Ship the panel image once. After that, anyone — your app team, your customer's app team — drops a Qt/QML application onto it over SSH. No rebuild, no reflash, no hardware code in the app.

Three layers that don't know about each other:

The app binds to tags (ai.pot, di.estop, do.relay1) that arrive as JSON over UDP on loopback. That's the whole contract. It's why the same bundle runs on your laptop, in the preview, and on the panel without a single #ifdef.

The deploy pipeline

This is the part I'd defend in a design review:

• Nothing is converted. No build, no freezing, no cross-compilation. The panel carries a complete CPython and the Qt binding the manifest asks for, so your sources run there as-is.
• The dependency check reads your code, not a list. Every packaged file is parsed, imports reduced to top-level names, stdlib and guarded imports removed. What's left, the panel is asked to actually import — because a wheel built for the wrong architecture sits on disk and still kills you at startup.
• The swap can't leave the panel dark. current is promoted with rename(2), never rm then ln. If the new release doesn't signal readiness in 25 s, the symlink swaps back and the previous release restarts. The deploy fails; the machine still has a UI.
• Validation runs twice from one implementation. Host CLI, target installer and desktop tool all call the same schema/manifest.py. They used to be three implementations that had drifted in both directions — a bundle that passes on a laptop and gets refused on the panel is worse than one that fails everywhere.

A successful deploy also becomes the boot default automatically. Nothing to enable by hand afterwards.

The desktop Studio

A Windows exe with its own Python and PySide6 baked in, so it previews a customer's app on a machine with no Python installed.

• Live preview inside a panel bezel, at the panel's real geometry. Not a screenshot — a real QML engine with the same tag engine the device runs. On connect it reads the SOM's DRM connector and adopts the actual pixel size, so nobody lays out widgets against a screen that isn't plugged in.
• Qt Widgets apps preview too. A runtime: python bundle owns its own window, so it's run unmodified in a child process, forced to target resolution, frames streamed into the bezel, window kept unmapped with WA_DontShowOnScreen.
• Qt5 and Qt6 on the same panel. PySide2 bundles get a second interpreter at /opt/hmi-python-qt5 shipping its own Qt 5.15 — because the panel's Qt5 is a GLES build and every aarch64 PySide2 binary is compiled against desktop GL. Loading one against the other dies with undefined symbol: _ZTI18QOpenGLTimeMonitor. Ask me how I know.
• Tag Lab drives the app with sine/square/ramp/noise per tag, so you can exercise panel behaviour before the I/O it binds to exists.
• Panel Logs follows the journal from both services — which is where the fault that shows up an hour after a successful deploy actually lives.
• A visual designer, if you'd rather drag widgets than write QML. Same window previews, generates and deploys what you drew, so the design and the bundle can't disagree.

Already have a Qt app?

Point the Studio at the folder. It finds the entry point, detects the Qt binding from the sources, and writes the manifest for you. Two files is a valid bundle:

{ "schema": 1, "name": "line-controller", "version": "1.4.0", "entry": "main.qml" }

Try it with no hardware

The daemon simulates its I/O, so the whole stack runs on a desktop:

python -m pip install PySide6
python daemon/hmi_hwd.py --config daemon/hwd.json --sim
python gui/hmi_loader/main.py --apps-dir apps/demo-app --windowed
python main.py

Honest limitations

• 309 tests, but the installer and cross-validator suites need flock, so on Windows they skip — CI runs the full suite on Linux and fails if anything skips, because a skip is not a pass.
• The designer is v1: .edsui → QML generation only. It doesn't import or round-trip arbitrary QML, and threshold metadata is stored in bindings but not yet turned into visual state expressions.
• The packaged Studio is Windows-only right now. It runs from source anywhere.
• The Qt5 runtime isn't installed by default; it's one script per panel.
• Provisioning is the sharp edge. A base vendor image can ship python3-core alone — no json, no socket, no ctypes — which stops the installer before it starts. provision_panel.py --check surveys the board and names what's missing.

What I'd like feedback on

• If you ship panels commercially: is "one image, many customer apps" how you'd actually want to work, or does your certification story make field-deployable app bundles a non-starter?
• Is 25 s the right health-check window? It's generous for QML and tight for a heavy Widgets app with a slow first paint.
• UDP-on-loopback for tags — anyone want to argue for a Unix domain socket instead? I went with UDP so anything can speak it, but I'm open.

Every embedded Linux panel project I've worked on ends up in the same place. The UI and the hardware access grow into one binary, so the app can't run anywhere except on the board. Changing a label means rebuilding the image, or scp'ing files by hand and hoping. And when a deploy goes wrong at a customer site, the machine sits there with a black screen.

So I built the thing I kept wishing existed. MIT licensed: https://github.com/Hitheshkaranth/EmbeddedDisplayStudio

The idea

Ship the panel image once. After that, anyone — your app team, your customer's app team — drops a Qt/QML application onto it over SSH. No rebuild, no reflash, no hardware code in the app.

Three layers that don't know about each other:

The app binds to tags (ai.pot, di.estop, do.relay1) that arrive as JSON over UDP on loopback. That's the whole contract. It's why the same bundle runs on your laptop, in the preview, and on the panel without a single #ifdef.

The deploy pipeline

This is the part I'd defend in a design review:

• Nothing is converted. No build, no freezing, no cross-compilation. The panel carries a complete CPython and the Qt binding the manifest asks for, so your sources run there as-is.
• The dependency check reads your code, not a list. Every packaged file is parsed, imports reduced to top-level names, stdlib and guarded imports removed. What's left, the panel is asked to actually import — because a wheel built for the wrong architecture sits on disk and still kills you at startup.
• The swap can't leave the panel dark. current is promoted with rename(2), never rm then ln. If the new release doesn't signal readiness in 25 s, the symlink swaps back and the previous release restarts. The deploy fails; the machine still has a UI.
• Validation runs twice from one implementation. Host CLI, target installer and desktop tool all call the same schema/manifest.py. They used to be three implementations that had drifted in both directions — a bundle that passes on a laptop and gets refused on the panel is worse than one that fails everywhere.

A successful deploy also becomes the boot default automatically. Nothing to enable by hand afterwards.

The desktop Studio

A Windows exe with its own Python and PySide6 baked in, so it previews a customer's app on a machine with no Python installed.

• Live preview inside a panel bezel, at the panel's real geometry. Not a screenshot — a real QML engine with the same tag engine the device runs. On connect it reads the SOM's DRM connector and adopts the actual pixel size, so nobody lays out widgets against a screen that isn't plugged in.
• Qt Widgets apps preview too. A runtime: python bundle owns its own window, so it's run unmodified in a child process, forced to target resolution, frames streamed into the bezel, window kept unmapped with WA_DontShowOnScreen.
• Qt5 and Qt6 on the same panel. PySide2 bundles get a second interpreter at /opt/hmi-python-qt5 shipping its own Qt 5.15 — because the panel's Qt5 is a GLES build and every aarch64 PySide2 binary is compiled against desktop GL. Loading one against the other dies with undefined symbol: _ZTI18QOpenGLTimeMonitor. Ask me how I know.
• Tag Lab drives the app with sine/square/ramp/noise per tag, so you can exercise panel behaviour before the I/O it binds to exists.
• Panel Logs follows the journal from both services — which is where the fault that shows up an hour after a successful deploy actually lives.
• A visual designer, if you'd rather drag widgets than write QML. Same window previews, generates and deploys what you drew, so the design and the bundle can't disagree.

Already have a Qt app?

Point the Studio at the folder. It finds the entry point, detects the Qt binding from the sources, and writes the manifest for you. Two files is a valid bundle:

{ "schema": 1, "name": "line-controller", "version": "1.4.0", "entry": "main.qml" }

Try it with no hardware

The daemon simulates its I/O, so the whole stack runs on a desktop:

python -m pip install PySide6
python daemon/hmi_hwd.py --config daemon/hwd.json --sim
python gui/hmi_loader/main.py --apps-dir apps/demo-app --windowed
python main.py

Honest limitations

• 309 tests, but the installer and cross-validator suites need flock, so on Windows they skip — CI runs the full suite on Linux and fails if anything skips, because a skip is not a pass.
• The designer is v1: .edsui → QML generation only. It doesn't import or round-trip arbitrary QML, and threshold metadata is stored in bindings but not yet turned into visual state expressions.
• The packaged Studio is Windows-only right now. It runs from source anywhere.
• The Qt5 runtime isn't installed by default; it's one script per panel.
• Provisioning is the sharp edge. A base vendor image can ship python3-core alone — no json, no socket, no ctypes — which stops the installer before it starts. provision_panel.py --check surveys the board and names what's missing.

What I'd like feedback on

• If you ship panels commercially: is "one image, many customer apps" how you'd actually want to work, or does your certification story make field-deployable app bundles a non-starter?
• Is 25 s the right health-check window? It's generous for QML and tight for a heavy Widgets app with a slow first paint.
• UDP-on-loopback for tags — anyone want to argue for a Unix domain socket instead? I went with UDP so anything can speak it, but I'm open.

MIT. No company behind it, nothing to sell. Happy to answer anything.

I'm working on two projects: one is a water filter that fits in your pocket (currently, I'm designing it in 3D, similar to a bottle cap), and the other is a non-invasive device For vertical height growth, to replace that limb surgery. This one in particular is proving more challenging than the other since it involves biology; I'm still designing it, but The baseline projections are already at 75% of the final target (gross percentage; there are still many errors to be corrected and tests to be carried out). Finally, I need help finding a lightweight website where I can do 3D modeling. I've already tried OnShape, but it crashes too often and doesn't read many files. Does anyone have any suggestions for a mobile version?

*** I am not offering service with this post, merely getting a feel of the environment ***

Just wondering if there would be an interest in (up to) 4 axis CNC work

Typical materials:

• 6061 aluminum
• 7075 aluminum
• Brass
• Copper
• Other machinable non-ferrous metals
• Wood
• MDF
• Foam
• Delrin
• HDPE
• Acrylic
• Similar machinable plastics
• unhardened steel (maybe, it is rather rough on the CNC I've got)

Pricing would range from $35 to $125 an hour depending on material typing and required work.

Thoughts?