
working with freecad and making an AI assistant
it was pretty fun, but it's pretty hard to make lol, for now i can only make basic shapes

it was pretty fun, but it's pretty hard to make lol, for now i can only make basic shapes
It was surreal. The country was. The warmth the country gave me was unexplainable. The nature, the careful urban planning, no spaghetti wires on sight, and the friendly and polite people. It was beauty at its finest.
And I miss Japanese toilets. Wish I could buy one soon lol.
Hello everyone.
I have a problem.
My conversation gets cutoff mid-way in my conversation which results to a new conversation.
I can't access any of my previous conversations and they are constantly loading.
I can't even press the "Stop execution" box button, it says "Failed to stop conversation"
The cutoff conversations are pretty harmless as any scripts it executes midway stops with the cutoff.
But it is so annoying to get cutoff midway.
What I did is that I created a readme file for antigravity to read the previous conversation in the brain folder of antigravity to gain context.
It's mildly infuriating.
Honestly, there's a lot of question banks in Scribd. It took me around 3 days to make this, gathering information, etc.
​
I created this because I want to know my subject weaknesses and strengths.
​
I'm planning to add more features. Please let me know what you think!
​
​
I don't know if my trust issues are too big but I don't really trust AI to do repeating tasks over and over again that it might crash out along the way.
​
To simplify, I want a script that could detect the tool call which AI is using. And the script triggers AI what to do or not.
​
I'm using DeepSeek API btw.
​
Because I want it to read 7218 md files, and extract content from them.
​
The reason for this is I want to control its creative decision to read the file and do something about it, like a filter.
​
DeepSeek (DS) uses view tool -> DS uses write tool -> DS uses view tool (next file) -> DS uses write tool. Good.
​
DS uses view tool -> DS uses view tool -> DS uses view tool -> DS uses write tool -> DS uses write tool -> DS uses write tool. Wrong
​
The reason for this is I don't want AI to take too much content and do something about it. I'd rather it reads the file one-by-one and do something about it, one by one. I want it to crawl to each file piece by piece.
​
I have an idea (and already did) of using async.gather so I can use API tool calls several times all at once. But I want to hear more ideas.
​
​
here's what we found in our study when making this drone
there's a lot of invisible noise inside the drone, signals and whatnot, we dont know those things until we hit hurdles everytime, electrical/electronic engineering was magic in our eyes but we were all just mechanical engineers only, ooga booga waving wrenches instead of sticks like a caveman to fix things that needed wizardry.
so we wrapped some of our wires with aluminum so they dont destroy each others' signals
we didnt use commercial flight controllers, we used teensy 4.0, which is far better than what arduino nano/uno can do. custom built drone brains are better because you put what you want, but the problem is, can you do the "what you want"? well it worked, so there's that
we used mpu 6050, we was about to use mpu 9250, it broke, AHHH, we didnt have time to buy another, gotta make use what we had, luckily an old mpu 6050 worked, good enough, good enough, no accurate yaw though, but i believe the magnetometer get fried with the noise inside though, but we dont really know, so pls check future engineers!
we shouldnt have added a washout, it made the whole airframe cambered which was counterintuitive to the plan of it being purely symmetrical to help with the vertical take off, but what's done was done, at least it still flew lol
and the boxy fuselage, yeah, i mean we did knew in our hearts that there will be flow separation on its edges even if its fillet-ed like a mcdonalds logo, but what's done is done, our motto was "good enough" lol
we used OpenFOAM to simulate the drone and winds, i used python scripts to automate the simulation for each attack of angle, lift/drag ratio etc, the simulations did happen, but i dont really know how they are setup so it is possible so it provided inaccurate results, we really only had like a day or two to learn OpenFOAM so of course my simulations were a wreck
from my simulations, i recently encountered that when we were rotating the wind to simulate the attack of angle, the inlet corner side was red, dont know really what it was but for future simulators, take note of the meshing, the inlet, outlet in your scripts, cuz i sure dont have time to check why it went wrong! but what i found is that openfoam (bluecfd) + python (automation) + windows (and yes openfoam can work in windows without a dual boot, linux virtual machine, whatever, purely running on window's blood) sure works, just didnt know my problem, i only did this in like 2-3 days lol.
so we just asked an Ansys cfd engineer to do the job for us, the difference was like hydrogen bomb (2M+ cells) vs coughing baby (ours is just ~300k cells, my "workstation" is "irish famine crisis", that's why we used openfoam in the first place so that there's no heavy real time 3d rendering, solidworks can work, but our panels wanted me to do OpenFOAM, AHHHHHHHHH, they suggested doing that because they heard about it, not because they used it, lol)
it was pretty hard, but fun to make, i was glad to be invited in this project. after all, we were the only undergraduate filipino mechanical engineers to undertake the hurdles of this emerging technology in just 2 months, i hope this thread will become a fix to someone's problem 5-10 yrs from now, as we also took from 5-10 yrs ago-fixes to fix our drone's problem
here's what we found in our study when making this drone
there's a lot of invisible noise inside the drone, signals and whatnot, we dont know those things until we hit hurdles everytime, electrical/electronic engineering was magic in our eyes but we were all just mechanical engineers only, ooga booga waving wrenches instead of sticks like a caveman to fix things that needed wizardry.
so we wrapped some of our wires with aluminum so they dont destroy each others' signals
we didnt use commercial flight controllers, we used teensy 4.0, which is far better than what arduino nano/uno can do. custom built drone brains are better because you put what you want, but the problem is, can you do the "what you want"? well it worked, so there's that
we used mpu 6050, we was about to use mpu 9250, it broke, AHHH, we didnt have time to buy another, gotta make use what we had, luckily an old mpu 6050 worked, good enough, good enough, no accurate yaw though, but i believe the magnetometer get fried with the noise inside though, but we dont really know, so pls check future engineers!
we shouldnt have added a washout, it made the whole airframe cambered which was counterintuitive to the plan of it being purely symmetrical to help with the vertical take off, but what's done was done, at least it still flew lol
and the boxy fuselage, yeah, i mean we did knew in our hearts that there will be flow separation on its edges even if its fillet-ed like a mcdonalds logo, but what's done is done, our motto was "good enough" lol
we used OpenFOAM to simulate the drone and winds, i used python scripts to automate the simulation for each attack of angle, lift/drag ratio etc, the simulations did happen, but i dont really know how they are setup so it is possible so it provided inaccurate results, we really only had like a day or two to learn OpenFOAM so of course my simulations were a wreck
from my simulations, i recently encountered that when we were rotating the wind to simulate the attack of angle, the inlet corner side was red, dont know really what it was but for future simulators, take note of the meshing, the inlet, outlet in your scripts, cuz i sure dont have time to check why it went wrong! but what i found is that openfoam (bluecfd) + python (automation) + windows (and yes openfoam can work in windows without a dual boot, linux virtual machine, whatever, purely running on window's blood) sure works, just didnt know my problem, i only did this in like 2-3 days lol.
so we just asked an Ansys cfd engineer to do the job for us, the difference was like hydrogen bomb (2M+ cells) vs coughing baby (ours is just ~300k cells, my "workstation" is "irish famine crisis", that's why we used openfoam in the first place so that there's no heavy real time 3d rendering, solidworks can work, but our panels wanted me to do OpenFOAM, AHHHHHHHHH, they suggested doing that because they heard about it, not because they used it, lol)
it was pretty hard, but fun to make, i was glad to be invited in this project. after all, we were the only undergraduate filipino mechanical engineers to undertake the hurdles of this emerging technology in just 2 months, i hope this thread will become a fix to someone's problem 5-10 yrs from now, as we also took from 5-10 yrs ago-fixes to fix our drone's problem