Devlog 8 (and final) of the Dragonfly Control Software I’m pleased to announce that the Dragonfly Control Software is ready to ship for review! Aside from final touches and adjustments, the last thing I made for the program is a function that triggers an action group set to activate telemetry scans from SCANsat-related parts. The idea for this is to place activation command for these scans in a determined action group triggered by the code itself. This function is called from the Cruise function right after its loop is complete and before the Approach function is called. This way, the telemetry scans are done at Dragonfly’s target altitude. You can see the function in action in the video I left below. Speaking about videos, I should get to editing the Demo video I have to upload. I’m very proud of myself and I hope many KSP players get to use this script since drones are very hard to design and fly in KSP.

Devlog 7 of the Dragonfly Control Software Safety First! This devlog is all about the safety features of Dragonfly’s script. This script has two safety functions that work at certain times of Dragonfly’s flight procedure and for the same idea: NOT CRASHING. The first one is the Landing Abort set of functions (that I have talked about but never shown until today). The main idea of this function is to prevent rolling down a hill or mountain. It works by checking if Dragonfly’s pitch exceeds 45 degrees or if its roll exceeds 30 degrees (each to either side). If so happens, Dragonfly panics, takes off, locks its heading, flies straight for 30 seconds, and attempts to land. Once Dragonfly lands, it re-checks if its pitch or roll exceed the limiters, and takes off again if needed until it finds an adequate landing spot. The second function is a safe altitude maintenance function (something very much like the PULL UP PULL UP or CAUTION, TERRAIN alerts and crash avoidance systems on airplanes). This function constantly executes with every refreshing of the Cruise main UNTIL loop and evaluates the following conditions: if Dragonfly’s altitude over sea level is within a 10-meter margin of error around the target altitude, and if Dragonfly’s altitude over ground level goes below 500 meters. Both conditionals are joined by an AND gate and if both are true, Dragonfly initiates an altitude maintenance mode. It is supposed to maintain a 500 meter distance from the ground until its altitude over ground level is within a 10-meter margin around 500 meters and its altitude over sea level is around the same 10-meter margin around its target altitude. When both conditions are true, Dragonfly understands that it is once again at its target altitude and at a safe distance from the ground, and returns to its normal cruise. This mode is quite useful when flying low to avoid mountains or hills, especially steep ones like the ones in the video. Although this script is very smart are cautious, DO NOT FLY DRAGONFLY TO A MOUNTAIN! During my testing, I have had multiple crashes and errors while attempting to land at the sides or top of mountains. Also, if you fly Dragonfly to a mountain, the landing abort function will go crazy and keep you there for half an hour (or more) trying to land on the mountain. I have given my advice to thee, you shall see if you follow it or reject it.

Devlog 6 of the Dragonfly Control Software I have worked than what should be considered overtime in the project and my effort is giving its fruits! With some help of AI doing a lot of math and calculus, I managed to make an actual approach function. First, Dragonfly calculates the distance to to the target Waypoint as a triangle. This means, in easy words, that the distance to the ground is one side of the triangle, the distance from the current point on the ground that Dragonfly is flying over to the Waypoint is the other side of the triangle, and the distance from the actual craft to the Waypoint is the hypotenuse of the triangle. Therefore, the idea is that Dragonfly follows that hypotenuse (shown in the video) all the way to the waypoint. Then, it levels its nose, activates the landing function, reduces its horizontal velocity to almost 0 by raising its nose (new characteristic), and softly lands. Also, I already wrote the landing abort function I talked about on the last Devlog, however, I had to re-write it since the SCANsat data for slope is apparently not valid or recognized, so, it did not work. What I made instead was a function that evaluates current pitch and roll right at landing, and, if either value crosses a limit, calls another function to make the drone take off, fly in a straight line, and call the landing function to try to land again. If the limit is not crossed, the drone simply activates the scientific analysis sequence. To summarize, this activates a land, check, and abort-or-stay loop of functions. This loop is executed until Dragonfly lands and its limits are not crossed. I will upload a video of it in the next devlog since I need to focus on fine-tuning the main functions first.

Devlog 5 of the Dragonfly Control Software I’m proud to announce that Dragonfly has successfully completed its first trans-oceanic flight! I had previously tested Dragonfly’s cruise altitude range around 5-6 kilometers over sea level, but this time, I decided to go even higher to 10 kilometers. I noticed that, at this altitude, Dragonfly could fly much faster but needed more power to maintain its altitude; just like airplanes do here on Earth. The video below shows Dragonfly exiting one continent and entering another on Tekto. Also, I found out how to make the SCANsat integration work. If you watch the terminal closefully, you can see Dragonfly’s current coordinates changing as it flies, and other telemetry data like current biome, slope, and elevation. Turns out, I had accidentally targeted the side of a mountain as the landing area and Dragonfly almost starts rolling down it, so, that gave me an idea: landing abort. I think the best option to make this work is to use the SCANsat data for slope and, if it is beyond a certain amount, make the drone fly to another area until the slope becomes safe enough to land. I could either make it fly straight until slope decreases to a safe amount, or make the user select an alternative waypoint (preferably flat) to safely land in case Dragonfly cannot. I thought another way to make this work was by detecting if the user presses the abort button on KSP’s UI, but that would ruin the whole point of Dragonfly being completely autonomous. In real space missions there is no abort button (neither is a “revert to assembly” button like in KSP) that works faster than the speed of light, so that is not a viable option. Anyways, I feel this project is getting better and more realistic with every change I make.

Devlog 4 of the Dragonfly Control Software Progress has been made! I have made multiple improvements to the code and its functioning in general. First, I added a telemetry integration function using the SCANsat mod (because what is a drone without telemetry, right?). Second, I wrote the scientific sequence function, but I have not yet integrated it into the drone. I have to assign its scientific devices to the action groups and calibrate their operating times. Third, I upgraded the Approach function and it now makes this butter-smooth leveling maneuver (seen on the video below) while also smoothly controlling its throttle, effectively maintaining its altitude within a 3 meter range. This script still has many improvements to be made, and I will definitely keep working on it.

Devlog 3 of the Dragonfly Control Software After having a break because of medical things, I returned to continue improving my project. I updated the Approach function and now it works better. However, Dragonfly is falling short of its target waypoint so I’ll be fixing that problem. Also, I will leave a video showing the Landing function in action, enjoy it.

Devlog 5: We Got the Energy!!!!⚡️⚡️⚡️

Alr I didnt spend too long but this is kind of a big update visually
After seeing the love from you guys i thought you might wanna see this…

Im writing this so early also because im gonna be gone on a trip for a couple days.

So below in the image as you can see i added kind of a beetle winged solar panel system.

I call it beetle style cause it can like transform into…

1. Big expanded wings like a beetle or…
2. it can also close in to protect it self or to make itself compact

What I did besides that?

Basically i added solar panels (⚡️) and a frame to to hold the solar panels

I also did some reasearch and planning for an assistant drone, kinda like ingenuity helping perserverence out.

Having eyes from above is very usefull in a world like mars

Next?

• We need 3rd person view for Rover X
• Then we can work on the controls for the drivers seat.
• I also have plans for maybe animating it. Mb blender or smth like that
• I might also add a way to compress the rovor so it is easy to send to space and then is decompresses on its own

P.S Comment if i should change the solar panels layout or smth
P.P.S Make sure to check out @sol4r_on_hackclub ’s Pocket city. Its pretty cool
P.P.P.S (idk if P.P.P.S exists) Repost if you want more people to see this
P.P.P.P.S Dont suprise me with a gazillion views and likes after im back

🌌🛰🧑‍🚀🚀🌠

Devlog 2 of the Dragonfly Control Software. After a complete code rewrite from scratch, I finally figured out how to make Dragonfly maneuver correctly. However, I need to calibrate a PID controller that makes the drone’s nose wobble up and down, but that is a minor problem now. I will continue to perfect the code to make it behave without any mayor issue. Anyways, here is a video of the drone taking off and cruising to its ideal altitude.

Devlog 1 of the Dragonfly Control Software. I started this new project inspired by NASA’s Dragonfly mission since I wanted a harder challenge than the rover autopilot. However, I was then surprised by how difficult it was to make kOS control a drone’s angles (pitch, yaw, and roll) alongside with throttle, height control, speed, and who knows what more. So, I came up with PID functions that were built into kOS’s libraries that auto-correct the drone’s control variables mentiones before. After 2+ hours of troubleshooting in Kerbal Space Program (that sadly are not registered in Hackatime) I made the drone fly. Now, I need to debug the script even more to make it correct its pitch, and add altitude controls for adequate ascending, descending, and landing. I have the Outer Planets mod installed (quick context: KSP does not have Saturn, Uranus, and Neptune; this planet pack mod adds them and some moons into the game), so I sent Dragonfly to Tekto (recreation of Titan, the target moon for the real mission) where gravity is low and atmospheric pressure is higher than Kerbin (Earth in KSP). This moon is an absolute paradise for rotorcrafts like this. I’ll leave a video of the craft successfully performing its first takeoff below. Also, I totally did NOT almost crash it after assuming control.

This is Devlog #4 (and possibly final before shipping) of the Rover Autopilot Software… The code is finally on its 1.0 version and ready for shipping. All testing has been concluded, along with the scripts limitations. I need to start writing the final README version (and add some pictures to it), and begin editing the Youtube video for the Demo URL. Here is timelapse video of the Scientific Sequence in action from waypoint arrival to end of script.

This is devlog #3 of the Rover Autopilot Software… I think I could FINALLY figure out how the rover can do efficient, controlled point-turns. The code had a function named setWheelReverse, which I removed because (after 4+ hours of debugging) I found out it was never reversing the assigned wheels. So, I came up with a smart solution: torque vectoring. There is a new function on the code named setWheelPower that sets a drive limiter on certain wheels -25% on the left wheels and 50% on the right wheels. Then, the executePointTurn function enables the drive limiter, sets every motor to 100% (or -100% for turns in the other direction), and rotates almost in place either way until the targeted heading is reached. Then, it stops turning, returns the wheels to normal, and starts driving. I also coded an intelligent slope-awareness function that does the following: maintains cruise speed on flat areas, speeds up on uphills (and recovers with max power if needed), and idles the motors and brakes on downhills. I will leave a video below showing every function in action, except for the science sequence, which I will show on the next devlog.

This is devlog #2.5 of the Rover Autopilot Software… The video from last devlog probably didn’t upload because of its size so I made a better, smaller one. I upgraded the code and fixed some bugs that were messing with the point-turn function. I need to add a slope-awareness function for the rover to maneuver appropriately, since there are too much steep mountains on Duna. I will continue developing this project and make it as similar as possible to a NASA/JPL software.

This is devlog #2 of the Rover Autopilot Software…Update version. I finished writing the code for the rover’s functions. These include the following: turning wheels and making point-turns, moving completely independent of user input (except for waypoint selection), performing scientific analysis, and moving various robotic parts. Update: I will leave in this devlog a video showing a test of the rover. It turns (somewhat; planning to rewrite/edit the function), drives, brakes, and overall, moves just fine. Btw, the rover definitely NOT moves at the speed a real rover does.

This is Devlog #1 of the Rover Autopilot Software… Touchdown confirmed! The test rover has landed successfully in Duna (Mars in KSP) and I already wrote the main control loop for the rover. It still needs a little bit of polishing, but I will be testing the code and adding more functions. Planned functions are the following: rotating certain wheels, and setting them to reverse to activate 360-degree turns; slope-awareness; robotic arm extension, retraction, and sample collection; and automatic data transmission (antennas are power-hungry). The test rover is a (state-of-the-art) replica of Curiosity. I’ll leave some pictures below: