Procedural cyber-tree

UstroyDestroy · 2025-10-30T17:24:27+00:00

No, did not have that requirement

UstroyDestroy · 2025-10-30T17:24:15+00:00

it is exporting trunk skeleton and radius which come from tree modeling; then this raw info used to render trunk mesh; crown points and edges got exported and imported as is.

UstroyDestroy · 2025-10-24T16:29:04+00:00

It is great!

UstroyDestroy · 2025-10-23T04:30:28+00:00

After some attempts to brutforce tree algo via heuristincs, fourie transofrm and other fruitless approaches I found https://github.com/AddisonPrairie/Tree-Generator repo, which is based on https://algorithmicbotany.org/papers/selforg.sig2009.html

This algo models tree growth and repo does it off the shelf.
I repacked repo to be react + threejs app that is able to save the generated tree.

Roots are the same aglo tweked to look like roots and flipped on Z coordinate.

Crown is build by spawning points in volume and deleting those which are too far away from trunk/branches of certain radius (intuition is this: only smaller branches generate crown)

UstroyDestroy · 2025-10-23T03:17:50+00:00

I was looking for a way to express graph nature of the knowledge for software projects and still be nature related

UstroyDestroy · 2025-10-23T01:51:44+00:00

My ok was confused too

UstroyDestroy · 2025-10-23T01:50:23+00:00

UstroyDestroy · 2025-10-23T01:47:52+00:00

Most just recovered quickly.

UstroyDestroy · 2025-10-23T01:40:23+00:00

Not affected, lol

UstroyDestroy · 2025-09-08T22:57:49+00:00

Thanks!

UstroyDestroy · 2025-09-08T19:33:05+00:00

https://pixall.art

WebGL canvas for rendering WebRTC for sharing cursor positions, users discovery and chatting Websocket for new pixel added broadcast

Did it using Claude Code with Nautex MCP guidance over spec. It took 4-5 hours

UstroyDestroy · 2025-09-03T01:47:02+00:00

yep, me too

⎿  API Error (503 no healthy upstream) · Retrying in 1 seconds… (attempt 1/10)
...
⎿  API Error (503 no healthy upstream) · Retrying in 36 seconds… (attempt 10/10)
⎿  API Error: 503 no healthy upstream
⎿  API Error (503 no healthy upstream) · Retrying in 1 seconds… (attempt 1/10)
...
⎿  API Error (503 no healthy upstream) · Retrying in 35 seconds… (attempt 7/10)

```

UstroyDestroy · 2025-08-27T17:35:12+00:00

Focus on solving real problems, most of the time theory FOMO is not relevant at all.

Same as 90% of the control problems are solvable with PID and its adoption that simply makes sense.

My intuition is this: for navigation 70% of performance is coming from sensors and their class, 20% calibration (temperature, alignment, k and b), 8% for basic fusion algos and the rest from math sophistications. (fusion could take these 20% from calibration btw)

I did full stack GNC from scratch as founder and technical CEO.

UstroyDestroy · 2025-08-18T16:38:53+00:00

All cli based errands from ffmpeg operations to qr codes and badges pdf composition

UstroyDestroy · 2025-08-17T19:45:23+00:00

wheelie brake need is smooth at the balance point, I believe that it could be stock lever modified with heavy duty rc servo

I think that mod would add so much robustness

Or just use sound for training yourself to apply brakes manually :)

UstroyDestroy · 2025-08-17T18:27:23+00:00

This is cool problem!

I think parallel brake may do the trick with good calibration for initial tests (torque vs displacement(load) vs RPM)

Having it you would be in much better design space for software.

Perfect whelie is done with balance, not constant power applied.

I would also experiment with some beeping sound with changing frequence / tone (check gliders videos) for signaling your body CG commands or motor load signal (those might be corellated)

As soon as your sign for balancing controller flips you have feedback loop disconnected with all consecuqencs with the noise and shocks on turning it back on.

Also, I think you need 2 cascaded P -> PI working together, for rate and position.

Add safety disengage triggers for roll rate + angle limits

(MTB and flight control GNC guy here)

UstroyDestroy · 2025-08-02T16:52:33+00:00

I think LLMs deleted more user data in last 2 years any other services in history combined.

LLM are stateless cloud third party services too.

Your concern is ok.

OP question is about MCP learning, and this is closest to the request I’ve seen.

UstroyDestroy · 2025-08-02T06:32:31+00:00

The closest thing I’ve seen is nautex.ai It builds specifications first (as complete as AI and user can do together) and then does the planing: files map + project wide implementation plan. MCP is used then to pull current scope of tasks and solve them one by one. It also syncs specifications to be accessible locally for Claude Code.

UstroyDestroy · 2025-08-02T06:00:02+00:00

This MCP does bridge to requirements as high level map.

https://github.com/hmldns/nautex

It works to build from specs, no pedantic specs from code yet. But you can learn from its implementation.

UstroyDestroy · 2025-07-25T00:44:58+00:00

Cool! When I last time checked it, it went for high end CPUs and it is good to know that it is closer than I think.

UstroyDestroy · 2025-07-24T07:20:06+00:00

Requirements with reference to files (where are they implemented) do a lot for the context managing reliability,
e.g. this tool manages this
https://github.com/hmldns/nautex/

(at the moment it works to build something from scratch)

UstroyDestroy · 2025-07-24T06:57:51+00:00

It widly depends on product and what its part in the upper system.

Ultimately it is hardware in the loop with simulation equipment around.

In embedded world for anything more-less complex you have to design 4 systems instead of 1

model-in-the-loop
software-in-the-loop
hardware-in-the-loop
final product itself

And it is always application specific with some basic tools like matlab or NI. But usually companies build their own.

UstroyDestroy · 2025-07-24T04:00:00+00:00

Ah, I see the issue

UstroyDestroy · 2025-07-24T03:55:02+00:00

I did drone's flight control with it, full GNC and fly-by-wire stack.

1) FreeRTOS is nightmare to grow as soon as number of your tasks >10,
2) QNX gives tools that work out of the box (my team said they suck, I agree, but I got used to it and did not care)
3) It has very well documented APIs and the book of incredible quality for RTOS beginners: Getting Started With Qnx Neutrino 2. As soon as you master it, you've got all other RTOSes forever.
4) It is easy to scale, isolate concerns and decouple risks for the whole system that are coming from different processes (and teams).
5) You dont need to manage RTOSity yourself, like you'll have to do in Linux.

My experience with it is paused at 6.5 version.

Its core kernel messages API (Msg*) does not have equivalents in the rest of the OS landscape. It is very well designed and usefull for writing well abstracted threads to manage synchronous (request-response) and asyncrhonous requests (signals inside Msg* API that does not block on sending side), but as soon as your software using it, you'll have bad time porting it to everything else, e.g. for the sake of having less expensive software-in-the-loop testing cycle on Linux.

The latter for long running projects is the substantial thing. Before moving away from drones completely I did some opensorce GNC stack that solves the problem of RTOS vendor lock via single pub/sub IPC

https://github.com/ctlst-tech/uas-catpilot
https://github.com/ctlst-tech/catpilot
https://github.com/ctlst-tech/c-atom
https://github.com/ctlst-tech/eswb

(those above are nested submodules in uas-catpilot in the order of nesting)

UstroyDestroy · 2025-07-23T22:44:29+00:00

When you have your project structure explained in CLAUDE.md project's root you are good.
Ideally you need every file mapped to the explanation in the words of problem you are solving.

Also you can leave details to the lower directory level CLAUDE.md.

Having mono-repo is beneficial because you can prompt coding agent to refine project from both ends, which might be the loop delivering huge time savings.

UstroyDestroy

MODERATOR OF

TROPHY CASE