@chrisyue321

Designed the torque output measurement system, which is essentially using the body of the output motor to measure the torque. By allowing the body to roll freely with a printed mount with slots for small metal balls the only resistive force to the rotation of the shaft is the internal friction of the gears and the rotational inertia of all of the parts; therefore if the shaft is moving at constant rotational speed the only torque that it is overcoming is the torque applied by the stator (outer body) of the output motor. Thus I can attach a torque-arm to the free-rolling motor body and use a load cell to measure torque. I wrote firmware to calculate the torque output based on the load cell reading; this has not been tested yet as I need to find a weight to calibrate the load cell with. I just realized there is a record feature that I was not aware of, so I may record some of my work. The issue is that I frequently leave my desk with Onshape and VSCode open which makes it weird to record as I usually do not sit for long stretches of time. I have the physical stuff all in the garage and my laptop and electronics stay upstairs usually unless I am preparing to mount the electronics. I have encountered a few issues relating to 3D printing tolerances and reliability; I had to reprint the gear coupler for the output motor twice as it had too much wiggle room. I also am planning out the sensor array layout and the full measurement pipeline.

I finished drilling all of the holes in the aluminum plate, sanded everything down a bit, and mounted all of the parts. I wired up the motor controller & all of the peripherals I currently have (ADXL345 accelerometer, current sensor) and added a potentiometer for motor control. After running the motor a few times I encountered an issue where the high EMI being generated by the motor power lines was interfering with the ESP32 and the other peripherals; I still have not yet found a good solution for electromagnetic isolation. The issue took so much time to resolve. My new worst nightmare is reading the serial output of the ESP32 and seeing “i2c hardware timeout” or “i2c software timeout” or “gpio _ is not usable; maybe conflict with others”. I may just use a separate ESP32 for the peripherals (one ESP for motor one for sensors) to isolate the sensitive power lines from any motor disturbance. I accidentally ran the motor at full power (~13V) and I think it must have hit like 12000 RPM, which instantly generated an extremely high-pitched noise from the gearbox. My dad was watching and got scared ;). Some of the teeth on the sun gear got a bit scratched up from that. I used a box knife to shave some of the teeth down a little and it runs smoother now with less noise; I may apply some grease later when I actually go to run the rig for a long period of time (probably 5-6 hours) to stress-test the gearbox.

I have been simultaneously working on the physical side of the project while also working on the electronics & firmware. I borrowed an ESP32 from the place where I work (very nice) and bought the motor controller, current sensor, hall sensor (for RPM), aluminum shell resistors to apply braking torque, the load & measuring motor, and the accelerometers. I have finished printing all of the parts I need, however I encountered a slight issue with alignment and spent some time fixing that. I made a drawing of my full assembly to place all of the holes properly on the aluminum plate I plan to use. I may add a little bit of extra space between the gearbox and the motor just so that the sun gear has no chance of rubbing up against the carrier; the printed-out drawing will definitely help me though (I can just tape it to the plate and make markings through the paper or just drill straight through).

Designed a few parts. The holder with 4 flanges is for the ADXL345 accelerometer to measure vibrations. The cylindrical part width the mounting face in the middle is for coupling the steel output shaft with the planetary carrier (I may end up getting it machined as I’m not sure what the strength capabilities of PLA are). The model with the two vertical plates is in progress but it is for the shaft (I did not extrude out the spaces where the bearings would go yet). I am also working on outlining a schematic of the electronics and thinking about starting firmware to gather data. I have a non-assembled devboard lying around that I got a few days ago (from a different project) that I may as well use as the central microcontroller for this project; it should have enough IO pins (if not, no big deal; I have a few IO expanders lying around).

After printing and checking the meshing of the gears, I decided to swap to helical gears as they are more reliable and produce less friction than a herringbone setup despite being slightly weaker and also prone to having the gears slide out of the planetary assembly. I redesigned the shaft clamp design to fit in a smaller size so that I can fit it onto the small shaft of the RS550 DC motor and also changed the gear ratio of the planetary gearbox to be 6. I finished the designs of all of the major motor mounting parts, and printed/verified their functionality with the motor (which just arrived). I have printed the ring gear, the planetary carrier, the 3 planet gears, and the sun gear; however the bearings are yet to arrive so I will not be able to test yet. I also realized that I will need a way to reduce contact surface area of the plastic so as to stop heat from building up, so I will have to reprint the planet gears to have a small notch in the middle that I can glue a small rubber spacer or a nut into.

I conducted some research and eventually decided to implement a planetary gear system to reduce the input RPM for gear testing, as it provides greater strength. I also designed a gear clamp system which allows me to clamp the gears onto the drive shaft reliably with a hex keyway. Below are a few screenshots of the hex keyway system and of the planetary gear system. I am going to conduct a preliminary test print to make sure the gears mesh well, they should mesh fine as my assembly indicates but the tolerances may not work out, or the gears may be too weak, etc.

Built a feature script to auto generate gears which will also be massively helpful in the future during experimentation. Also added some fillets to the front motor mount and two extra front-side mounting holes in case I need extra stability.

I found a motor to use (RS-550, most likely will use th e 18V variant) and designed a mount for the motor which I will most likely 3D print. I also quickly modeled a shaft coupler which I am planning to use

Built a feature script to auto generate gears which will also be massively helpful in the future during experimentation. Also added some fillets to the front motor mount and two extra front-side mounting holes in case I need extra stability.

I built a basic propulsion module but I haven’t gotten around to really implementing it yet I just put in some code to add it into some of the modules but I have not tested it. I’ve mainly been focusing on debugging the dynamics modules as I ran some tests with verbose logging and it appears that there is either something wrong with the calculation of the aerodynamic coefficients or there is something fundamentally wrong with the equations of motion. Here is a screenshot of the erratic behavior (pitch oscillating wildly, roll switching oddly between 0 and 180 degrees, velocity oscillating, altitude behaving weirdly, and all manner of weird stuff.

After starting a new project, I finished implementing V2 of the core data structures, 6DOF equations of motion, and aerodynamic model. I built some unit tests to make sure everything is working properly. Below is an attached screenshot of the test working (I think I may have forgotten to push the testing file to GitHub and only pushed the test functions instead of the file w/ the code that logs the runs)

I found a motor to use (RS-550, most likely will use th e 18V variant) and designed a mount for the motor which I will most likely 3D print. I also quickly modeled a shaft coupler which I am planning to use

I have forgotten to write devlogs on Stardance, I started the project but completely forgot to link my Hackatime. I have been working on the engine on and off for around 3 weeks now. The first version was intended to have a aerodynamic model class with all of the parameters such as coefficient of lift (and its derivatives with respect to variables like angle of attack) among others. However, the dynamics and math appeared to be extremely inconsistent and the simulation as a whole had poor stability. Tweaking the parameters (wingspan, chord, etc) of the wing just slightly caused large fluctuations. I was only able to achieve the stability demonstrated in the screenshots below with an essentially perfectly tuned NACA airfoil. It still does dive a bit more than I was expecting (aka what ChatGPT and Gemini were both expecting since I do not have a lot of extensive experience in aeronautics).

Due to these unresolved issues I have started a new version of the engine which I plan to add a bunch of unit tests to to ensure every module is working as intended, I accidentally overwrote GitHub commit history in the process rip :(.