|
42116
|
Ile by @Leftie | Stardance
|
Leftie
|
1
|
58.98
|
810
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-08-24T01:50:52Z", "hours": 58.0, "multiplier": 13.97, "payout": 810, "blessing": "neutral", "text": "I made Ile, an embedded scripting language! It uses a recursive descent parser to build an abstract syntax tree and then walks the tree to execute. The hardest part was when I would run into tiny little problems, like Rust giving lifetime errors, and not knowing how to solve them immediately. I’m proudest of the parsing logic. It’s the longest source file I’ve ever written, and it took awhile to figure out. To test Ile, you can download it from the GitHub releases and run some of its example programs.", "repo": "https://github.com/left-alert-chaos/ile", "demo": "https://crates.io/crates/ile"}]...
|
[{"post_id": 57800, "ts": "202 [{"post_id": 57800, "ts": "2026-08-30T03:01:58Z", "hours": 0.9814, "text": "Devlog 14: …oh So I’ve been doing my development on Ubuntu, which, as a Linux distro, is UNIX-based, and uses just \\n for newlines. However, I haven’t done any testing on Windows, and Houston, we have a problem. I still don’t have all my ratings yet, but someone was kind enough to create a github issue saying that Ile doesn’t work on Windows. I hadn’t thought to support it, but Windows uses \\r\\n for newlines! This broke the tokenizer, and caused the language to be unusable on non-UNIX-based systems. It was a one-line fix, but I already have 10 ratings, so I can only hope they aren’t too negative for having bad Windows support.😟 P.S. I guess this means Windows is officially as outdated as a typewriter!"}, {"post_id": 53454, "ts": "2026-08-24T00:51:03Z", "hours": 5.0833, "text": "Devlog 13: Ship time! I’ve been working on getting everything ready to ship, and I think it’s almost time! I’ve fixed some bugs, added more tests, published to crates.io , and created a GitHub release! Now, I’ll make sure I have good instructions in my README, and I’ll be ready to go!"}, {"post_id": 52730, "ts": "2026-08-23T01:49:50Z", "hours": 5.53, "text": "Devlog 12: Scoping is hard I’ve been working on getting Ile ready to ship, and I had a small, significant feature to implement: scoping. This is basically when a function is called and uses the scope that it was a part of when it was created instead of the scope it was called in. This was hard . To implement this, my first thought was write yet another lookup function to find the correct module’s stack and walk the function in the stack. Unfortunately, the compiler didn’t like this. I couldn’t get it done without having 2 different mutable references to the stack at the same time, so it was off the table. What I ended up going for was when a function is called, it clones (memory-efficient, amirite?!) its entire scope and walks inside it. After the function executes, it then sets the value of its module’s scope to the current value of the scope it just walked in, so as to update it with any changes. Makes sense, right? RIGHT?! Anyway, there isn’t really a picture to show, so here’s tests passing."}, {"post_id": 51428, "ts": "2026-08-21T04:01:56Z", "hours": 4.3419, "text": "Devlog 11: I don’t even know I’m hoping to ship tomorrow, so I’m fixing up the language to be usable. I’ve been writing some documentation, so I have a little starter guide now. I also learned that Ile can use as little as one thirtieth the ram of Node.js! That’s definitely going in the features section."}, {"post_id": 50052, "ts": "2026-08-19T02:44:43Z", "hours": 5.3528, "text": "Devlog 10: asdf I’ve been trying to add a GUI system to the standard library. Because I don’t want any dependencies, I came up with the following harebrained scheme: Write a Python script that formats its stdin in a Tkinter window to draw a GUI When the function to create a window is called, spawn Python as a sub-process and send the text to be displayed to its input via a pipe Unfortunately, this doesn’t work. The script works when run on its own, but when run by Ile it just doesn’t launch a window. I couldn’t figure this out, so the GUI system (VeBaGu, or Very Bad GUI) is staying, albeit in an unstable beta state. On a side note, I’ve also decided to ditch the editor idea and just focus on the language; this Stardance project is now just Ile, not Crocodile."}, {"post_id": 49045, "ts": "2026-08-17T17:08:49Z", "hours": 1.5578, "text": "Devlog 9: Hello, world! I didn’t do that much work for this devlog, but I did achieve 2 important things: Added comment support Added bindings to println!() and stdin This means that Ile, as demonstrated below, can now read its stdin and write to stdout !"}, {"post_id": 48620, "ts": "2026-08-17T02:44:43Z", "hours": 5.3911, "text": "Devlog 8: We have language! If you couldn’t tell, that was a play on “we have liftoff!”. I didn’t add a rocket emoji, for obvious reasons. Anyway, I have great news: Ile is almost a usable language! Today, I added loops and operators, so it can iterate and do math now! My for loop is a tad different than other languages, so here’s the gist: every for loop has a condition and a block. Every iteration, the condition runs. If it returns something , the block runs. Otherwise, the loop exits. Because I made let statements return the value they assign, you can have syntax that looks like this : for let x = iterator.next() {} I’m really proud of how my syntax is turning out overall. There’s still not much to screenshot; I haven’t written the logic to interface with Rust, so there’s no println yet. I do have some more test coverage, though. There was some difficulty getting break to work, however. For some reason, the loop it was a part of would always keep going. Eventually, I figured out why: It was being removed from the stack at the end of the code block that generated it. To fix this, I added some logic to re-push it to the stack if it got popped."}, {"post_id": 47258, "ts": "2026-08-15T02:01:37Z", "hours": 4.0222, "text": "Devlog 7: Running before I can run For some reason, I felt like instead of finishing the syntax fundamentals, I would skip directly to object-oriented (ish) patterns. In this case, we have a bunch of attributes that can be accessed and modified. Below is a snippet of some OOP concepts in practice:"}, {"post_id": 46593, "ts": "2026-08-13T22:47:35Z", "hours": 2.6758, "text": "Devlog 6: {insert dark joke about lifetimes} I just spent a frustratingly long amount of time figuring out why Rust didn’t like my lifetimes. I don’t even remember what I did to make it compile. This was fun . However, after figuring that out, I wrote the walk methods for a few NodeType s. Here’s the stack after a simple program finishes, and the program that was run:"}, {"post_id": 45535, "ts": "2026-08-12T02:37:00Z", "hours": 3.505, "text": "Devlog 5: Operators I started work on the AST (abstract syntax tree) walking algorithm today. I didn’t get very far, but one of the things I did do was I fixed operator parsing. Before, if you were to parse something like 15 > 5 && 5 < 10 , it would have been a greater-than operator with a boolean operator as a child, and that doesn’t work. Therefore, I had to write some code to convert that broken operator into a boolean operator with mathematical children. The algorithm didn’t make much sense in my head, so I drew it out on paper and that made it pretty easy to write. Below is the illustration I made and the code it became."}, {"post_id": 44922, "ts": "2026-08-11T00:03:53Z", "hours": 3.7761, "text": "Devlog 4: I finished the parser! I wrote the parser, which takes the tokenized code and converts it into a usable, in-memory representation. After fixing the bugs from yesterday, I wrote some logic to parse a function block and the rest of the syntax was easy. Running main.rs now prints out a representation of a parsed AST. Now all I have to do is: make the AST walkable, so I can actually execute the code write logic to facilitate interop with Rust The first image is some example Ile code, and the second is some of the AST that is generated from it."}, {"post_id": 44391, "ts": "2026-08-10T03:09:12Z", "hours": 7.8347, "text": "Devlog 3: An almost-broken parser! I made a very basic AST parser! The AST (abstract syntax tree) is the in-memory representation of the code as a tree. This took a really long time. My machine froze and my interpreter produced incomprehensible errors about wanting a word token, but in the end cargo test passed, so I’m happy. It also doesn’t support anything other than function calls, but this is a great first step in creating an actually walkable AST."}, {"post_id": 39848, "ts": "2026-08-03T03:22:22Z", "hours": 1.7778, "text": "Devlog 2 I started work on the AST builder. I decided that the algorithm will use delimiters to decide which tokens correspond to which AST node and I’m working on a method for Node that determines how to add a child based on the Node ‘s type and the child’s type. The screenshot is some of the code for Node ."}, {"post_id": 39114, "ts": "2026-08-01T20:28:30Z", "hours": 7.0919, "text": "Devlog 1: Building blocks I’ve been focusing on the scripting language, Ile, because to be honest the editor is the boring part. So far, I have project structure and some fundamentals–I’ve written the tokenizer and some stack-switching logic. For those who don’t know, the tokenizer is responsible for taking a blob of (hopefully) human-readable source code and converting it into tokens , which are used later on to build an abstract syntax tree. For now, all I’m concerned about is that cargo test passes!"}]...
|
Title: Ile by @Leftie | Stardance
Devlogs:
Devlog Title: Ile by @Leftie | Stardance
Devlogs:
Devlog 1: Building blocks I’ve been focusing on the scripting language, Ile, because to be honest the editor is the boring part. So far, I have project structure and some fundamentals–I’ve written the tokenizer and some stack-switching logic. For those who don’t know, the tokenizer is responsible for taking a blob of (hopefully) human-readable source code and converting it into tokens , which are used later on to build an abstract syntax tree. For now, all I’m concerned about is that cargo test passes!
Devlog 2 I started work on the AST builder. I decided that the algorithm will use delimiters to decide which tokens correspond to which AST node and I’m working on a method for Node that determines how to add a child based on the Node ‘s type and the child’s type. The screenshot is some of the code for Node .
Devlog 3: An almost-broken parser! I made a very basic AST parser! The AST (abstract syntax tree) is the in-memory representation of the code as a tree. This took a really long time. My machine froze and my interpreter produced incomprehensible errors about wanting a word token, but in the end cargo test passed, so I’m happy. It also doesn’t support anything other than function calls, but this is a great first step in creating an actually walkable AST.
Devlog 4: I finished the parser! I wrote the parser, which takes the tokenized code and converts it into a usable, in-memory representation. After fixing the bugs from yesterday, I wrote some logic to parse a function block and the rest of the syntax was easy. Running main.rs now prints out a representation of a parsed AST. Now all I have to do is: make the AST walkable, so I can actually execute the code write logic to facilitate interop with Rust The first image is some example Ile code, and the second is some of the AST that is generated from it.
Devlog 5: Operators I started work on the AST (abstract syntax tree) walking algorithm today. I didn’t get very far, but one of the things I did do was I fixed operator parsing. Before, if you were to parse something like 15 > 5 && 5 < 10 , it would have been a greater-than operator with a boolean operator as a child, and that doesn’t work. Therefore, I had to write some code to convert that broken operator into a boolean operator with mathematical children. The algorithm didn’t make much sense in my head, so I drew it out on paper and that made it pretty easy to write. Below is the illustration I made and the code it became.
Devlog 6: {insert dark joke about lifetimes} I just spent a frustratingly long amount of time figuring out why Rust didn’t like my lifetimes. I don’t even remember what I did to make it compile. This was fun . However, after figuring that out, I wrote the walk methods for a few NodeType s. Here’s the stack after a simple program finishes, and the program that was run:
Devlog 7: Running before I can run For some reason, I felt like instead of finishing the syntax fundamentals, I would skip directly to object-oriented (ish) patterns. In this case, we have a bunch of attributes that can be accessed and modified. Below is a snippet of some OOP concepts in practice:
Devlog 8: We have language! If you couldn’t tell, that was a play on “we have liftoff!”. I didn’t add a rocket emoji, for obvious reasons. Anyway, I have great news: Ile is almost a usable language! Today, I added loops and operators, so it can iterate and do math now! My for loop is a tad different than other languages, so here’s the gist: every for loop has a condition and a block. Every iteration, the condition runs. If it returns something , the block runs. Otherwise, the loop exits. Because I made let statements return the value they assign, you can have syntax that looks like this : for let x = iterator.next() {} I’m really proud of how my syntax is turning out overall. There’s still not much to screenshot; I haven’t written the logic to interface with Rust, so there’s no println yet. I do have some more test coverage, though. There was some difficulty getting break to work, however. For some reason, the loop it was a part of would always keep going. Eventually, I figured out why: It was being removed from the stack at the end of the code block that generated it. To fix this, I added some logic to re-push it to the stack if it got popped.
Devlog 9: Hello, world! I didn’t do that much work for this devlog, but I did achieve 2 important things: Added comment support Added bindings to println!() and stdin This means that Ile, as demonstrated below, can now read its stdin and write to stdout !
Devlog 10: asdf I’ve been trying to add a GUI system to the standard library. Because I don’t want any dependencies, I came up with the following harebrained scheme: Write a Python script that formats its stdin in a Tkinter window to draw a GUI When the function to create a window is called, spawn Python as a sub-process and send the text to be displayed to its input via a pipe Unfortunately, this doesn’t work. The script works when run on its own, but when run by Ile it just doesn’t launch a window. I couldn’t figure this out, so the GUI system (VeBaGu, or Very Bad GUI) is staying, albeit in an unstable beta state. On a side note, I’ve also decided to ditch the editor idea and just focus on the language; this Stardance project is now just Ile, not Crocodile.
Devlog 11: I don’t even know I’m hoping to ship tomorrow, so I’m fixing up the language to be usable. I’ve been writing some documentation, so I have a little starter guide now. I also learned that Ile can use as little as one thirtieth the ram of Node.js! That’s definitely going in the features section.
Devlog 12: Scoping is hard I’ve been working on getting Ile ready to ship, and I had a small, significant feature to implement: scoping. This is basically when a function is called and uses the scope that it was a part of when it was created instead of the scope it was called in. This was hard . To implement this, my first thought was write yet another lookup function to find the correct module’s stack and walk the function in the stack. Unfortunately, the compiler didn’t like this. I couldn’t get it done without having 2 different mutable references to the stack at the same time, so it was off the table. What I ended up going for was when a function is called, it clones (memory-efficient, amirite?!) its entire scope and walks inside it. After the function executes, it then sets the value of its module’s scope to the current value of the scope it just walked in, so as to update it with any changes. Makes sense, right? RIGHT?! Anyway, there isn’t really a picture to show, so here’s tests passing.
Devlog 13: Ship time! I’ve been working on getting everything ready to ship, and I think it’s almost time! I’ve fixed some bugs, added more tests, published to crates.io , and created a GitHub release! Now, I’ll make sure I have good instructions in my README, and I’ll be ready to go!
Devlog 14: …oh So I’ve been doing my development on Ubuntu, which, as a Linux distro, is UNIX-based, and uses just \n for newlines. However, I haven’t done any testing on Windows, and Houston, we have a problem. I still don’t have all my ratings yet, but someone was kind enough to create a github issue saying that Ile doesn’t work on Windows. I hadn’t thought to support it, but Windows uses \r\n for newlines! This broke the tokenizer, and caused the language to be unusable on non-UNIX-based systems. It was a one-line fix, but I already have 10 ratings, so I can only hope they aren’t too negative for having bad Windows support.😟 P.S. I guess this means Windows is officially as outdated as a typewriter!
Ships:
I made Ile, an embedded scripting language! It uses a recursive descent parser to build an abstract syntax tree and then walks the tree to execute. The hardest part was when I would run into tiny little problems, like Rust giving lifetime errors, and not knowing how to solve them immediately. I’m proudest of the parsing logic. It’s the longest source file I’ve ever written, and it took awhile to figure out. To test Ile, you can download it from the GitHub releases and run some of its example programs....
|
1793933255.6338208
|
1794019655.6338208
|
|
18491
|
My first slack bot! by @marcipan | Stardance
|
marcipan
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @marcipan | Stardanc Title: My first slack bot! by @marcipan | Stardance...
|
1793414854.6801405
|
1794019654.6801405
|
|
12162
|
Stonks by @bchoi1267 | Stardance
|
bchoi1267
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Stonks by @bchoi1267 | Stardance
|
1793414853.7120996
|
1794019653.7120996
|
|
14046
|
My very own WebOS by @ROBOCHESSATHLETICCODERKID | My very own WebOS by @ROBOCHESSATHLETICCODERKID | Stardance...
|
ROBOCHESSATHLETICCODERKID
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @ROBOCHESSATHLETICCODE Title: My very own WebOS by @ROBOCHESSATHLETICCODERKID | Stardance...
|
1793414852.740934
|
1794019652.740934
|
|
45083
|
Breakitt by @akshara | Stardance
|
akshara
|
1
|
3.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-08-24T16:15:40Z", "hours": 3.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made a dumb site where you just smash plates, cups, etc. I made it with the idea of a stress-relief website in mind. I built it as an experiment to learn about Matter.js — it’s not up to the mark, but I learned a lot while building it. The hardest part was definitely creating the shard shapes, and also lining up the objects to the shelf. The thing I’m most proud of is the sound — it’s completely generated live with the Web Audio API and sounds pretty realistic. To test it, just swipe or drag through any item.", "repo": "https://github.com/akshara200829-lgtm/Breakitt", "demo": "https://akshara200829-lgtm.github.io/Breakitt/"}]...
|
[{"post_id": 53876, "ts": "202 [{"post_id": 53876, "ts": "2026-08-24T16:08:15Z", "hours": 0.4339, "text": "Finally completed building Breakitt!!I made it to learn Matter.js and mess around with physics — it was so much fun to build. It’s not up to the mark, but I learned a lot doing it"}, {"post_id": 43430, "ts": "2026-08-08T17:47:36Z", "hours": 2.7619, "text": "Started building a plate-breaking simulation. This is my first time trying Matter.js, so I’ve been experimenting with physics, collisions, and procedural shattering. Till now , I’ve set up the physics using Matter.js, added a plate that stays in place until it’s hit, responsive canvas resizing, a simple sound using the Web Audio API, and a procedural shatter system that breaks the plate into random shards with physics. I’ve also added screen shake and drag-based interactions to make the impact feel more satisfying. I plan on improving the plate shading and shatter visuals to make the breaking look more realistic, along with adding a few more features. Would love some suggestions or tips!!"}]...
|
Title: Breakitt by @akshara | Stardance
Devlogs:
Title: Breakitt by @akshara | Stardance
Devlogs:
Started building a plate-breaking simulation. This is my first time trying Matter.js, so I’ve been experimenting with physics, collisions, and procedural shattering. Till now , I’ve set up the physics using Matter.js, added a plate that stays in place until it’s hit, responsive canvas resizing, a simple sound using the Web Audio API, and a procedural shatter system that breaks the plate into random shards with physics. I’ve also added screen shake and drag-based interactions to make the impact feel more satisfying. I plan on improving the plate shading and shatter visuals to make the breaking look more realistic, along with adding a few more features. Would love some suggestions or tips!!
Finally completed building Breakitt!!I made it to learn Matter.js and mess around with physics — it was so much fun to build. It’s not up to the mark, but I learned a lot doing it
Ships:
I made a dumb site where you just smash plates, cups, etc. I made it with the idea of a stress-relief website in mind. I built it as an experiment to learn about Matter.js — it’s not up to the mark, but I learned a lot while building it. The hardest part was definitely creating the shard shapes, and also lining up the objects to the shelf. The thing I’m most proud of is the sound — it’s completely generated live with the Web Audio API and sounds pretty realistic. To test it, just swipe or drag through any item....
|
1793933250.5678315
|
1794019650.5678315
|
|
33310
|
Project Aether by @angkon777 | Stardance
|
angkon777
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Project Aether by @angkon777 | Stardance
|
1793414850.5677278
|
1794019650.5677278
|
|
1329
|
My first slack bot! by @AwesomeEyeball | Stardance
|
AwesomeEyeball
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @AwesomeEyeball | St Title: My first slack bot! by @AwesomeEyeball | Stardance...
|
1793414849.6242504
|
1794019649.6242504
|
|
52918
|
ONEGLASS UNIVERSE by @Devadutt | Stardance
|
Devadutt
|
1
|
2.74
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-08-22T18:16:29Z", "hours": 2.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made a website that shows my stardance journey so far. The challenging part was to build the courage after my first project was flagged due to overuse of AI. Now I am proud of the fact that this one is entirely written by me. I hope you like it. I know it looks ugly but this my first time using visual studio", "repo": "https://github.com/Devadutt-11/ONEGLASS-UNIVERSE", "demo": "https://devadutt-11.github.io/ONEGLASS-UNIVERSE/"}]...
|
[{"post_id": 52824, "ts": "202 [{"post_id": 52824, "ts": "2026-08-23T05:36:49Z", "hours": 0.7417, "text": "Added about me as per the feedback"}, {"post_id": 52518, "ts": "2026-08-22T17:43:16Z", "hours": 1.6903, "text": "created my first website. I know it looks ugly but it is my first time building one!."}]...
|
Title: ONEGLASS UNIVERSE by @Devadutt | Stardance
Title: ONEGLASS UNIVERSE by @Devadutt | Stardance
Devlogs:
created my first website. I know it looks ugly but it is my first time building one!.
Added about me as per the feedback
Ships:
I made a website that shows my stardance journey so far. The challenging part was to build the courage after my first project was flagged due to overuse of AI. Now I am proud of the fact that this one is entirely written by me. I hope you like it. I know it looks ugly but this my first time using visual studio...
|
1793933247.803573
|
1794019647.803573
|
|
1978
|
Belote by @Martin | Stardance
|
Martin
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Belote by @Martin | Stardance
|
1793414847.4598615
|
1794019647.4598615
|
|
31707
|
My very own WebOS by @Nik_k | Stardance
|
Nik_k
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @Nik_k | Stardance
|
1793414846.5066988
|
1794019646.5066988
|
|
3526
|
My first slack bot! by @riyashreenavin | Stardance
|
riyashreenavin
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @riyashreenavin | St Title: My first slack bot! by @riyashreenavin | Stardance...
|
1793414845.6013145
|
1794019645.6013145
|
|
21972
|
F1Legends by @avycado13 | Stardance
|
avycado13
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: F1Legends by @avycado13 | Stardance
|
1793414841.850917
|
1794019641.850917
|
|
25617
|
TrinTrinCaptcha by @meowmeowellie | Stardance
|
meowmeowellie
|
0
|
4.18
|
0
|
[]
|
[{"post_id": 15614, "ts": "202 [{"post_id": 15614, "ts": "2026-06-25T12:11:41Z", "hours": 4.1761, "text": "I’ve been through hell. Currently, when I first originated to build this project. I usually thought it would be pretty simple. Just use some crappy libraries, write some OCR libraries. Most captchas are really annoying to get pass through and are just time consuming to bypass. I was able to create a Altcha solver and Cap.js solver (also bypassing instrumental!). Most of the time I’ve spent was just focusing on this project. I love bypassing captchas"}]...
|
Title: TrinTrinCaptcha by @meowmeowellie | Stardan Title: TrinTrinCaptcha by @meowmeowellie | Stardance
Devlogs:
I’ve been through hell. Currently, when I first originated to build this project. I usually thought it would be pretty simple. Just use some crappy libraries, write some OCR libraries. Most captchas are really annoying to get pass through and are just time consuming to bypass. I was able to create a Altcha solver and Cap.js solver (also bypassing instrumental!). Most of the time I’ve spent was just focusing on this project. I love bypassing captchas...
|
1793414840.9230313
|
1794019640.9230313
|
|
21925
|
My first slack bot! by @ataaguesmi | Stardance
|
ataaguesmi
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @ataaguesmi | Starda Title: My first slack bot! by @ataaguesmi | Stardance...
|
1793414840.0294027
|
1794019640.0294027
|
|
12133
|
Alpha Mk.1 by @Elias9761 | Stardance
|
Elias9761
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Alpha Mk.1 by @Elias9761 | Stardance
|
1793414839.082557
|
1794019639.082557
|
|
29397
|
A Brainfuck Interpreter Written in Brainfuck by @R A Brainfuck Interpreter Written in Brainfuck by @Ryzex | Stardance...
|
Ryzex
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: A Brainfuck Interpreter Written in Brainfuc Title: A Brainfuck Interpreter Written in Brainfuck by @Ryzex | Stardance...
|
1793414838.1568258
|
1794019638.1568258
|
|
24977
|
Modded Ender 3 Max by @brundoge | Stardance
|
brundoge
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Modded Ender 3 Max by @brundoge | Stardance
|
1793414837.2506478
|
1794019637.2506478
|
|
72210
|
playground by @synameta | Stardance
|
synameta
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: playground by @synameta | Stardance
|
1793414835.8279824
|
1794019635.8279824
|
|
72209
|
Semafor0-1 by @Matt_Luna | Stardance
|
Matt_Luna
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Semafor0-1 by @Matt_Luna | Stardance
|
1793414834.9374695
|
1794019634.9374695
|
|
72208
|
My awesome macropad! by @hylton | Stardance
|
hylton
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @hylton | Stardance
|
1793414833.9870725
|
1794019633.9870725
|
|
72207
|
PadofallPads by @adrishg74 | Stardance
|
adrishg74
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: PadofallPads by @adrishg74 | Stardance
|
1793414832.977941
|
1794019632.977941
|
|
72206
|
My own site! by @hamzamulla | Stardance
|
hamzamulla
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My own site! by @hamzamulla | Stardance
|
1793414832.0529413
|
1794019632.0529413
|
|
72205
|
Blog by @synameta | Stardance
|
synameta
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Blog by @synameta | Stardance
|
1793414830.628951
|
1794019630.628951
|
|
72204
|
Blog by @synameta | Stardance
|
synameta
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Blog by @synameta | Stardance
|
1793414829.7035124
|
1794019629.7035124
|
|
72203
|
SlackBot by @synameta | Stardance
|
synameta
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: SlackBot by @synameta | Stardance
|
1793414828.7584352
|
1794019628.7584352
|
|
72202
|
An app for trading card collectors by @dino_dino | An app for trading card collectors by @dino_dino | Stardance...
|
dino_dino
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: An app for trading card collectors by @dino Title: An app for trading card collectors by @dino_dino | Stardance...
|
1793414827.3554237
|
1794019627.3554237
|
|
33594
|
Autonomous Trash Drone by @randymo | Stardance
|
randymo
|
0
|
26.73
|
0
|
[]
|
[{"post_id": 71403, "ts": "202 [{"post_id": 71403, "ts": "2026-09-20T19:14:18Z", "hours": 1.6564, "text": "SO MUCH CODING DONE - did not get to record this sadly and took a long break but me and my friend are back at it now and we’re almost completely done with everything on his side(the 3d modeling) and my side(the coding). Below are 4/8 of the scripts that i’ve made so far."}, {"post_id": 32774, "ts": "2026-07-22T04:41:10Z", "hours": 6.6297, "text": "Devlog 4: Worked on actually coding the logic i explained in the previous devlog, coding went smooth with minimal issues. Only issue is if this will actually work when i am able to get funding for the actual hardware, I adjusted and researched a lot to make sure the code I’m creating would be compatible with the hardware I get. I also was able to create some extra logic ideas to patch up issues such as a system where it remembers areas it has already scanned and can use them to readjust and drifting that may have occurred with the data. Also was able to make it make decisions on where to fly and its overall flight direction although it still needs some adjusting for an accurate and efficient flight path. -Next time I work I’ll have to connect it to the flight script so It can actually command the flight controller to do stuff as well as finalize the flight paths. P.S. I also need to fix the drift correct system."}, {"post_id": 32584, "ts": "2026-07-21T21:08:01Z", "hours": 11.575, "text": "Devlog 3: We started working on our own custom SLAM from scratch for a roomba styled tracking system where the autonomous drone already knows where it has already searched The actual coding wasn’t completed very much but we fully understand how the whole system logic will work and what we have to code. To summarize it uses the flight controllers outputs like its yaw, position, and velocity to calculate an initial pose, then creates creates a grid of boxes that contain data to hold status like free, unknown, and blocked based off of the coordinates from our lidar data we converted. It then compares the map of lidar scans that moves based off the pose to the current scan, slowly making slight adjustments to find how much the drone actually moved in real life. This data is then used and converted into another grid that stores only where the drone has been and is used for the whole logic of not checking the same place over and over again."}, {"post_id": 29918, "ts": "2026-07-17T03:00:14Z", "hours": 5.0744, "text": "Devlog #2: Today focused on advancing both the software and mechanical portions of the autonomous trash collection drone. On the software side, the LiDAR subsystem was completed. The Python script for the RPLIDAR C1 was finalized, including initialization, communication with the sensor, and collection of scan data. The script now reads distance measurements and angles from the LiDAR, providing the foundation for future obstacle detection and avoidance logic. Time was also spent organizing the software architecture and researching the required Python libraries for each subsystem of the drone. The project dependencies were separated into categories for computer vision, sensor processing, flight control, and networking, and virtual development environments were configured and tested to prepare for future development. On the mechanical side, significant progress was made on the robotic gripper assembly. Most of the CAD modeling for the gripper arm was completed, including the overall geometry, servo mounting, gear layout, and finger mechanism. Existing component dimensions were reviewed to ensure compatibility with the DS3218 servo, bearings, and planned fasteners. The gripper design is now largely complete and serves as the primary end effector for the drone’s trash collection system. Overall, today’s work established a solid foundation for both the software and hardware systems. The LiDAR subsystem is now operational at the software level, the project’s development environments are organized for continued programming, and the gripper assembly has reached an advanced stage of mechanical design. These milestones prepare the project for integration of obstacle avoidance, object detection, and physical manipulation in future development sessions."}, {"post_id": 28502, "ts": "2026-07-14T19:54:24Z", "hours": 1.7919, "text": "Dev Log #1 – Today I continued working on the mechanical design of the autonomous trash-collecting drone, focusing on the robotic arm and gripper assembly. The main objective was to determine the overall dimensions of the arm, select appropriate hardware, and make design decisions before continuing the CAD model. During today’s work, I finalized the decision to use three DS3218 high-torque servos throughout the robotic arm, including the gripper. Although a smaller servo was considered for the claw, I decided to use the same servo for all three joints to simplify the design, reduce the number of different components, and make future maintenance easier. I also continued determining the dimensions of the upper arm, forearm, and gripper based on the expected payload and overall size of the drone. The arm will be constructed from CF PETG using a lightweight truss-style structure to maximize rigidity while minimizing weight. I researched the DS3218 servo output shaft and confirmed that it uses a 25T spline, which will be used for the servo-driven joints. I also standardized the hardware by selecting M3 machine screws for servo mounting and the majority of the structural connections throughout the arm. A large portion of today’s work focused on the gripper mechanism. After evaluating several concepts, I decided to use a three-gear synchronized design consisting of one servo-driven center gear and two mirrored gears connected to each finger so that both fingers open and close together. I also selected a 1:1 gear ratio and began determining appropriate gear sizes and the overall dimensions of the gripper housing to fit the DS3218 servo. In addition to the mechanical design, I estimated the overall weight of the drone using the currently selected components to ensure the chosen propulsion system should be capable of lifting both the aircraft and its expected payload. This estimate will continue to be refined as the CAD model progresses and additional components are finalized. The next stage of development will focus on continuing the CAD model of the gripper, finalizing the gear layout, finger dimensions, and mounting points, and completing the remaining mechanical details of the robotic arm before beginning assembly of the full system."}]...
|
Title: Autonomous Trash Drone by @randymo | Starda Title: Autonomous Trash Drone by @randymo | Stardance
Devlogs:
Dev Log #1 – Today I continued working on the mechanical design of the autonomous trash-collecting drone, focusing on the robotic arm and gripper assembly. The main objective was to determine the overall dimensions of the arm, select appropriate hardware, and make design decisions before continuing the CAD model. During today’s work, I finalized the decision to use three DS3218 high-torque servos throughout the robotic arm, including the gripper. Although a smaller servo was considered for the claw, I decided to use the same servo for all three joints to simplify the design, reduce the number of different components, and make future maintenance easier. I also continued determining the dimensions of the upper arm, forearm, and gripper based on the expected payload and overall size of the drone. The arm will be constructed from CF PETG using a lightweight truss-style structure to maximize rigidity while minimizing weight. I researched the DS3218 servo output shaft and confirmed that it uses a 25T spline, which will be used for the servo-driven joints. I also standardized the hardware by selecting M3 machine screws for servo mounting and the majority of the structural connections throughout the arm. A large portion of today’s work focused on the gripper mechanism. After evaluating several concepts, I decided to use a three-gear synchronized design consisting of one servo-driven center gear and two mirrored gears connected to each finger so that both fingers open and close together. I also selected a 1:1 gear ratio and began determining appropriate gear sizes and the overall dimensions of the gripper housing to fit the DS3218 servo. In addition to the mechanical design, I estimated the overall weight of the drone using the currently selected components to ensure the chosen propulsion system should be capable of lifting both the aircraft and its expected payload. This estimate will continue to be refined as the CAD model progresses and additional components are finalized. The next stage of development will focus on continuing the CAD model of the gripper, finalizing the gear layout, finger dimensions, and mounting points, and completing the remaining mechanical details of the robotic arm before beginning assembly of the full system.
Devlog #2: Today focused on advancing both the software and mechanical portions of the autonomous trash collection drone. On the software side, the LiDAR subsystem was completed. The Python script for the RPLIDAR C1 was finalized, including initialization, communication with the sensor, and collection of scan data. The script now reads distance measurements and angles from the LiDAR, providing the foundation for future obstacle detection and avoidance logic. Time was also spent organizing the software architecture and researching the required Python libraries for each subsystem of the drone. The project dependencies were separated into categories for computer vision, sensor processing, flight control, and networking, and virtual development environments were configured and tested to prepare for future development. On the mechanical side, significant progress was made on the robotic gripper assembly. Most of the CAD modeling for the gripper arm was completed, including the overall geometry, servo mounting, gear layout, and finger mechanism. Existing component dimensions were reviewed to ensure compatibility with the DS3218 servo, bearings, and planned fasteners. The gripper design is now largely complete and serves as the primary end effector for the drone’s trash collection system. Overall, today’s work established a solid foundation for both the software and hardware systems. The LiDAR subsystem is now operational at the software level, the project’s development environments are organized for continued programming, and the gripper assembly has reached an advanced stage of mechanical design. These milestones prepare the project for integration of obstacle avoidance, object detection, and physical manipulation in future development sessions.
Devlog 3: We started working on our own custom SLAM from scratch for a roomba styled tracking system where the autonomous drone already knows where it has already searched The actual coding wasn’t completed very much but we fully understand how the whole system logic will work and what we have to code. To summarize it uses the flight controllers outputs like its yaw, position, and velocity to calculate an initial pose, then creates creates a grid of boxes that contain data to hold status like free, unknown, and blocked based off of the coordinates from our lidar data we converted. It then compares the map of lidar scans that moves based off the pose to the current scan, slowly making slight adjustments to find how much the drone actually moved in real life. This data is then used and converted into another grid that stores only where the drone has been and is used for the whole logic of not checking the same place over and over again.
Devlog 4: Worked on actually coding the logic i explained in the previous devlog, coding went smooth with minimal issues. Only issue is if this will actually work when i am able to get funding for the actual hardware, I adjusted and researched a lot to make sure the code I’m creating would be compatible with the hardware I get. I also was able to create some extra logic ideas to patch up issues such as a system where it remembers areas it has already scanned and can use them to readjust and drifting that may have occurred with the data. Also was able to make it make decisions on where to fly and its overall flight direction although it still needs some adjusting for an accurate and efficient flight path. -Next time I work I’ll have to connect it to the flight script so It can actually command the flight controller to do stuff as well as finalize the flight paths. P.S. I also need to fix the drift correct system.
SO MUCH CODING DONE - did not get to record this sadly and took a long break but me and my friend are back at it now and we’re almost completely done with everything on his side(the 3d modeling) and my side(the coding). Below are 4/8 of the scripts that i’ve made so far....
|
1793411841.4469116
|
1794016641.4469116
|
|
9549
|
My first slack bot! by @Itz- | Stardance
|
Itz-
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @Itz- | Stardance
|
1793411840.5525632
|
1794016640.5525632
|
|
17772
|
Robot Desk Assistant by @Yasser | Stardance
|
Yasser
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Robot Desk Assistant by @Yasser | Stardance
|
1793411839.612973
|
1794016639.612973
|
|
19374
|
My very own WebOS by @vivid | Stardance
|
vivid
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @vivid | Stardance
|
1793411838.6670768
|
1794016638.6670768
|
|
30126
|
ide by @venk | Stardance
|
venk
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: ide by @venk | Stardance
|
1793411837.7487063
|
1794016637.7487063
|
|
1080
|
AshBorn by @jean | Stardance
|
jean
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: AshBorn by @jean | Stardance
|
1793411836.816103
|
1794016636.816103
|
|
10346
|
My first slack bot! by @augusto | Stardance
|
augusto
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My first slack bot! by @augusto | Stardance
|
1793411832.865824
|
1794016632.865824
|
|
21137
|
Colosseus by @gauss | Stardance
|
gauss
|
0
|
75.71
|
0
|
[]
|
[{"post_id": 84725, "ts": "202 [{"post_id": 84725, "ts": "2026-10-30T04:44:09Z", "hours": 3.2642, "text": "Debugging the Adapters and RPM I had noticed that one of the motor’s LED’s kept flickering on and off, and decided to remove the part to isolate the issue. I found that one of the cables was loose, and there wasn’t an easy way for me to fix this without risking melting the plastic off. So, I placed an order for new cables. I also started working on RPM calculations because Colosseus needs to know how fast it’s going. I’m using a timer that repeatedly calculates the displacement in rotation, which is needed to calculate rotational speed. So far, I just have a small demo of this working, but I plan to use this later in a feedback loop to regulate the robot’s speed."}, {"post_id": 84580, "ts": "2026-10-29T21:35:04Z", "hours": 1.5083, "text": "Fixed the Encoders I was previously stuck on the encoders for a long time, so I created a script in MicroPython to debug the issue. I found that it worked perfectly fine when I isolated everything on a breadboard, and then realized that in my PCB I had flipped the orientation of the 6-pin connectors. I ended up having to de- and re-solder the connectors with a hot air gun, but the C code still didn’t work. After a quick Google search, I found that you could only use one callback method for an IRQ on each core. I was using two: one for each encoder. I fixed this by making a larger callback function that invoked the individual callbacks depending on the GPIO pin. Long story short: it works!"}, {"post_id": 84064, "ts": "2026-10-29T02:36:57Z", "hours": 1.7522, "text": "Started the Firmware I wrote some code to test the motors and the encoders. So far, the motors spin as they should, but I’m having some difficulty with the encoders. The encoders are needed for a PID loop, which is crucial for the robot as it needs to follow a straight path. Next steps Debug the code for the encoders and add UART input."}, {"post_id": 78908, "ts": "2026-10-12T00:22:17Z", "hours": 5.0608, "text": "IT WORKSSSSS ok sit tight brodini cuz i got a lot of stuff to tell you I burned another PCB! yea, u sure heard that right. I found out what the issue with the PCB was: the motor driver was in the wrong orientation, which connected the +12V rail itself to a gpio pin, frying the rp2040 entirely. Instead of using my hot air station to de-solder and rotate the driver, I decided to just make another board because I was lazy. The second board ended up not working either, and when I pressed down on one of the legs of the buck converter with a multimeter, the IC caught on fire and started smoking. I ended up needing to use a hot air station to replace the buck converter on that board, so I used it to heat up and fix the driver on my previous board while I was at it. I now have two working boards but does it really work? yup. how do you know? because I’m built like that I dont think so stfu ANYWAY…FIRMWARE TIMEEEE The best way to verify the board works is to test out its main feature: controlling Colosseus’ motors (goddamn I’ve spent so much time on the pcb that I’m still not comfortable with the actual name of the robot). I wrote some code in C to blink the KineticBoard’s onboard led, built and flashed the .uf2 to the pico, connected it to the board, andd… … … … IT DIDN’T CATCH ON FIRE! (that’s a first) it actually blinked the LED like it was supposed to. wow. With that boost in confidence, I was more inclined to write code for the robot itself. I started scaffolding a library for the robot, which I’m calling KineticLib . So far, I’ve written code to simplify PWM channels because the TB6612FNG motor driver relies on two of them. I tested my library by adding a demo project that makes the robot incrementally increase in speed, and then come back in the same manner. It worked too! things I HAVEN’T tested yet connecting the Pico to USB while it’s attached to the hat using the usb-c rececptacle to power other stuff (like a regular rpi) observing the effect of forcing the motors to spin while they are connected to the KineticBoard (I tried this briefly and I smelled some type of smoke, but I could very well just be paranoid) but yea all in all 11/10 experience i would highly recommend trying to make one of these on your own. if you happen to be brave enough to test these before I do, lmk what happens on slack (if you survive)."}, {"post_id": 77207, "ts": "2026-10-06T03:02:31Z", "hours": 0.9836, "text": "THE BOARD IS ON FIRE Not really, but it kinda is. After soldering all of the components on with an iron and hot plate, I connected the Pi Pico to the HAT via the female header sockets. I wrote a simple blinky script and verified that it worked when powered by my regular laptop. However, when I powered the KineticBoard HAT with the Pico, the RP2040 chip started smoking and I was able to capture a brief orange glow on camera. What now?? I’ll have to carefully look at what could have gone wrong. I tested the voltage readings from the multimeter and found that VSYS reads +5.1V when switched on, which makes sense because the Pico can accept that much. I did notice a constant 0.5V on the +3V3 pin for whatever reason (before attaching the pico). I’ll isolate the Pico on a breadboard and attach jumper wires only where needed, and gradually close in on the part that caused the failure. On a side note, I figured out why one of the LEDs isn’t working. It happens to not be connected to GND; however, everything else seems to be connected just fine."}, {"post_id": 74265, "ts": "2026-09-27T03:10:38Z", "hours": 4.0342, "text": "Custom Enclosure for the PCB After the board had travelled across the Pacific Ocean and the United States, it finally reached its destination at the core of Colosseus. UPDATE: THE PCB AND THE LCSC PARTS HAVE ARRIVED!!!! Whadidyado? I started creating a case for the KineticBoard. So far, I copied the layout of the board from KiCAD and added cutouts for parts that were meant to have user interaction. I tested out three prototypes before settling on one that actually fit (a lot of issues were solved by adding extra clearance and gaps). Potential Issues I’m 70% certain that the case won’t fit the bottom floor of the chassis, but that’s a problem for later. For now, I’m just designing the most badass case I can."}, {"post_id": 67863, "ts": "2026-09-14T04:29:30Z", "hours": 0.8228, "text": "Sent out the order! After finalizing the last parts of the extension board, I used my hardware grant to send the PCB over to JLC for fabrication. I separately purchased parts from LCSC."}, {"post_id": 63987, "ts": "2026-09-08T02:41:10Z", "hours": 2.2825, "text": "Finished the PCB The final coat of copper pavement was carefully laid out as the green city was unified at last. Changes I routed the motor driver’s pins to the two 6-pin adapters on the bottom right of the board. I connected the last pads, and added some finishing touches such as screw holes for a 3D-printed enclosure and some custom silkscreen cuz why not. I also filleted the edges as I read that it was a good practice online. What’s Next? All of the GND pads are isolated, so I need to make a copper fill zone or something to link all of them. I also plan on adding a little silkscreen on the back, and then we should be good to go!"}, {"post_id": 62644, "ts": "2026-09-06T03:28:09Z", "hours": 3.9669, "text": "Almost Done with the Layout With the components oriented in their city-like pattern, all that was left to do was to pave the final roads through the green adhesive base, connecting the motor driver to the 6-pin adapters. Changes? I decided to drop the 12V to 3.3V buck because the Pico has one internally, and I could just keep my 5V buck and feed its output into VSYS and extract 3.3V from the Pico’s +3V3 pin. I also ended up changing the orientation of some adapters because I couldn’t comprehend the fact that the PCB exists in 3 dimensions? Lastly, I greedily extended the bottom of the PCB so that both partitions could access one large +12V trace (the GPIO sockets were interfering). What next? All I have to do is wire up the connections to the motor driver and adapters, and we should be good to manufacture ts."}, {"post_id": 57735, "ts": "2026-08-30T00:13:42Z", "hours": 3.4392, "text": "Finished KineticBoard HAT Schematic I spent a few hours finishing the schematic for the KineticBoard HAT, an extension board that allows the Pi Pico to control motors. Additions Rather than using a standard Li-Ion to power the Pico and a really small power bank to power the Pi, I decided to just use one: the Li-Ion. For this to happen, the PCB would need to convert 12V to 5V and expose this voltage through a USB-C connector. I decided to copy & paste my old buck converter schematic, but I had to pick different resistance values such that this formula V = 0.925 * (1 + R1/R2) yielded ~5.1V. This seems easy, but I wanted to use some resistors that I already had. I decided to make a C program that picked the most optimal values for this voltage divider. The program works by following a 2 pointer algorithm which adjusts the numerator and the denominator by shuffling through a sorted list of the resistance values, and finding the ones that are closest to the target voltage. I also expanded on my old buck converter by making the +3V3 net controlled by a switch, just so that no weird stuff happens if I connect both the PC and battery to the board at the same time. Lastly, I added the 6-pin JST connectors, the motor driver, and a few status LEDs. I put everything in the PCB editor in the end, and I’m honestly terrified of routing this thing, but that’s a problem for later lol."}, {"post_id": 52037, "ts": "2026-08-22T02:18:59Z", "hours": 2.0181, "text": "Another PCB????? I’m creating a second motor driver board, but this time instead of being a standalone devboard, it is only a hat. Schematic Stuff I added symbols for header sockets, the barrel jacks, a buck converter, and the usual dozens of resistors and caps. The pinout for the buck converter was so annoying and something about putting non-connecting wires on top of each other pissed me off a lot. It’s an eyesore, and I can already tell that I have to use a billion vias to get everything working once I’ll hit the layout stage."}, {"post_id": 41542, "ts": "2026-08-05T20:17:20Z", "hours": 1.6042, "text": "So I Almost Burned My Finger I was trying to get the encoders to work, but in the process of reading data through USB serial, I got a mild shock How Did This Happen? To configure hall effect encoders, you need to give each wheel a good spin to determine how many “pulses” are detected by the Pico. The detection part is quite simple: whenever the wheel turns a certain amount, motor encoders A and B change state. This can be detected through an interrupt and then printed out (in the main loop, not the callback). However, in the process of printing it out, I touched the USB-C receptacle and felt it get extremely hot, and later realized that something got shorted somewhere. Any Guesses Where? Looking back at the situation, I had connected the battery and USB power from my laptop to the board at the same time, so something might have gone wrong there. Another thing that was going wrong was that the receptacle itself was coming off, so it could be that one of the pads, say +5V for instance, came in contact with like GND or smth, inducing shock if someone were to touch it. Here’s an image from the timelapse right before I plugged the board into my laptop and fried it:"}, {"post_id": 41002, "ts": "2026-08-04T21:46:57Z", "hours": 0.25, "text": "Soldered the GPIO pins Yea idk why I didn’t do this earlier but I needed the GPIO pins to read data from the motor encoders."}, {"post_id": 37990, "ts": "2026-07-31T02:44:53Z", "hours": 2.0092, "text": "First Drive I checked the devboard for any last errors and connected it to the motors on the robot! Final checks I verified that the KineticBoard Leaf works when it’s powered by USB and by the 5000mAh Li-Ion battery. I did this by writing a simple program that toggles a GPIO pin, and used a multimeter to read the oscillating voltages. It worked!! Test Drive! I already had firmware from the design stage, but it was written for a different motor driver so I decided to start from scratch. I created a basic motor drive “class” (structs/functions to go with the struct) in C and set up my CMake project in a way that I could add a demos folder later. Now that I had custom firmware for the TB6612FNG, I wired up each screw terminal pair to the M1 and M2 pins on each motor, and flipped the switch to see it drive perfectly! It was really relieving to see everything work on first try, and I gained a huge confidence boost in my embedded programming skills. Future Enhancements The motors came with 6-pin connectors, and I should have included appropriate receivers for these connectors on the KineticBoard Leaf rather than just generic screw terminals. Currently, I have to connect the 6-pin connector to 6 jumper wires, which is quite the eyesore."}, {"post_id": 37353, "ts": "2026-07-30T00:32:38Z", "hours": 0.35, "text": "Lab Visit + THE DEVBOARD WORKS NOW WOHOOO After inhaling a mole of lead-based solder fumes, I finally got the devboard to work!!! It’s my first ever PCB so I’m really stoked!! I visited my friend’s lab at the university where he works and we were able to debug and fix the devboard in a few hours. Unfortunately, I remembered that I had to record the whole thing in lapse in the last 20 minutes, but I guess that’s just karma for taking 9 hours ( ) to hand solder/debug a PCB in my last devlog (yes ik i suck). Issues My previous attempt at soldering failed because I set the temperature of my hot air gun too low, and I overestimated surface tension’s effect on my hot plate. I used a high-res microscope at the lab and saw that most of the QFN components were only partially soldered. I could quite literally see a tiny gap between the two pads. Another thing I saw was some obvious bridging, which I quickly fixed with a soldering iron. One of my biggest takeaways from the lab was that THE TYPE OF SOLDER FLUX MATTERS!!! I previously used some generic $14 flux from Amazon, but it was so bad that even some of the most powerful ultrasonic flux cleaners couldn’t get it off easily. It was also so thick that even the infrared lamp couldn’t get the RP2040 to stick down. My friend used (and recommended) water-soluble flux, which makes it easy to clean off without messy isopropyl alcohol. I ended up salvaging the parts from my old PCB to build a new one from scratch. I learned how to solder QFP packages, 0603s, and even 0402s with an iron. In the end, a soldering iron is THE BEST way to guarantee that your components are soldered down, especially when verified with a microscope. I also learned how to solder using an infrared lamp and hot air (properly, this time). Results??? Right as I finished soldering the last component, I connected it to my computer and held down bootselect….and IT WAS DETECTED AS A MASS STORAGE DEVICE!!! I was so excited at this time that I finally rekindled my motivation to keep building more of these PCBs (I was pretty close to giving up on PCB-related projects ngl). Anyway, right before leaving, I put it in the ultrasonic washer they have for PCBs (which is just a tiny container with water and ultrasonic waves being fired it at from all directions to take the flux off. I’m currently waiting until tomorrow for it to air dry, and then I’ll incorporate it in the robot!"}, {"post_id": 32135, "ts": "2026-07-21T02:56:44Z", "hours": 9.7003, "text": "Broken Devboard So this was my first time ever soldering a PCB, and I didn’t go easy on myself especially considering I used 0402 footprints on a 4-layer double-sided layout. I had hoped that it would work after soldering all the parts but unfortunately, it did not. Areas of Error The front portion was soldered using a hot plate, and the back was soldered with a hot air gun. This was my first time using a hot air gun, so I had my dad (a former electronics hobbyist) help me out a little. Turns out we both couldn’t fix it. One potential error is that the back side wasn’t properly soldered because we ran the air gun at 220 degrees fahrenheit, wihch could have meant that the core of the gun was that hot but outside it could be 150 or something. Another thing that could have gone wrong is the ICs could have been overheated and cooked, or a tiny bridge on the RP2040 could have shorted the whole thing. Next Steps and Debug I asked a friend (a guy who has a PhD in computer/rf engineering) to help me debug the board, and he said he’ll be more than happy to in a few weeks. In the meantime, I guess I’ll just make a bunch of more projects!"}, {"post_id": 28924, "ts": "2026-07-15T15:07:31Z", "hours": 3.2167, "text": "SMD Soldering Attempt The parts from LCSC and JLCPCB had arrived! This meant that I could finally build the final part of the robot: the KineticBoard controller (yk, the devboard with a motor driver on it?). It’s gonna be difficult because I have to solder both sides of the PCB, but so far I only soldered the first side. Some parts were misaligned but it looks mostly ok."}, {"post_id": 27967, "ts": "2026-07-13T22:31:13Z", "hours": 2.4608, "text": "Rebuilt the Robot The new standoffs had finished 3D printing, so I could finally replace the faulty old ones. Since I had to tear the robot down anyway, I decided to fix the motor slant problem as well. The solution to the motor slant problem was relatively simple: some foam padding to lift the motors up to the horizontal. This solution not only worked perfectly, but also gave the robot a little bit of shock absorbance. After that, all I had to do was build the robot with the new standoffs, which was actually quite a chore because it’s hard to use a screwdriver at an angle."}, {"post_id": 26870, "ts": "2026-07-11T22:02:49Z", "hours": 0.9167, "text": "Standoff Redesign The old standoffs had an issue because they weren’t properly threaded, which meant that there really wasn’t much aside from minimal friction that was holding the screws in place. The Fix I redesigned the standoffs by making them wider, thoroughly hollow, and exposed on one half. This allowed me to slide nuts and screws inside the standoffs, which will guarantee a perfect lock. Another issue that this redesign fixed was the blocked hole problem. Essentially, when I put a screw in a hole on the middle chassis, I couldn’t then use that same hole for another standoff to connect the other side. This solves that issue since a single screw on the middle chassis can now go through two standoffs at once, allowing me to connect both sides."}, {"post_id": 24486, "ts": "2026-07-08T01:50:07Z", "hours": 2.2497, "text": "Assembly Time! Alas, the fun part officially begins! At the time of writing this, most of the parts I ordered online have arrived, with the exception of the custom PCB from JLC. The parts for the chassis just came out of the 3D printer an hour before I started my session, so I had enough parts to finally build the robot! Challenges Building the actual robot brought tiny errors that I had previously overlooked to light. For starters, the 2.5mm trough, while looking very aesthetic, caused the motors to tilt slightly upwards. Additionally, the custom 3D-printed standoffs didn’t really hold on to the M3 screws, so I’m just hoping gravity does its thing. I might have to hot glue them later if more issues arise out of this. Lastly, the motors come with female-to-female cables, but my KineticBoard Leaf expects female-to-male. I might add male headers to the next iteration of the KineticBoard Leaf."}, {"post_id": 23890, "ts": "2026-07-07T03:00:11Z", "hours": 2.5553, "text": "Quality-of-life Updates for the Chassis I had used horseshoe-type straps previously in an RC Car design but those had a tendency to slide horizontally. With that in mind, I decided to use the motor’s 2 M3 screws to build a strap on each side of the chassis to lock the motors in place. I’ll still keep one horseshoe clamp for each motor in addition to this for stability purposes."}, {"post_id": 15868, "ts": "2026-06-25T19:55:35Z", "hours": 3.5669, "text": "Fixing the KineticBoard Did you know that something as simple as a double-sided version of a Pi Pico can cost around $150 to manufacture from JLC? Yea, I didn’t either. Silkscreen Redesigns! I made some newer art to put as a silkscreen. I think what I had before was okay, but it seemed a bit sloppy. GitHub submodule stuff I updated the KineticBoard Repo and added it as a submodule to my main repository. Capacitor Fix From my last session, I ended with picking a capacitor that had a higher voltage rating since passing 12V through a 6.3V capacitor will definitely cause dielectric breakdown. My solution last time was to use an 25V electrolytic aluminum capacitor, which ended up being too big. To resolve the overlap, I just chose a different SMD Capacitor footprint—this time for a tantalum capacitor since they’re much smaller. Inverted Screw Terminals Apparently the screw terminals were inverted this whole time. I realized this since the arrows were pointing toward the terminals from the center of the board, rather from the outside (the arrows indicate the direction that the wire will enter). I fixed this by rotating each screw terminal by 180 but this just caused 19 DRC violations. Of course, I had to reroute all of the traces that were flipped, and of course I had made it so that fixing one trace blocks the other trace from passing through. I ended up solving this problem by dropping a via and routing the board through one of the 2 middle layers. And it costs WHAT??? Yup. The board itself costs $7, but then JLCPCBA decided to ramp up the cost to $150 with a $50 setup fee, $30 “loading into the feeder” fee, and so on. I’m thinking of buying a hot plate to “solder” all of the SMD parts on the board at home, but some of my caps are 0402 and those things are genuinely microscopic."}, {"post_id": 15472, "ts": "2026-06-25T04:59:34Z", "hours": 4.2003, "text": "CAD Touch-ups I had previously built a chassis for this robot before in Stasis, but I had never shipped it. Today, I looked at the BOM for the assembly and saw that the metal standoffs that hold the layers together cost more than $2 per piece. I avoided this fee by modeling my own plastic standoffs that had M3 holes on both ends. I also updated the wheels to fit better with the chassis and use less filament. Unfortunately, this increased the mass moment of inertia of the wheels so stopping them and getting them to start might be a future issue? (I hope not tho plsplspls). You have a devboard too? Whatttt Yep! At Stasis, I also made a devboard known as the KineticBoard for this robot. This wasn’t shipped either. Since the devboard was almost complete, I decided to start looking up how to use JLCPCB and realized that I had yet another BOM to fill. Yayyyy🫠. I spent a solid hour figuring JLC out and also saw that one of my capacitor footprints needs to be updated because they don’t make 100uF capacitors in a size that’s expected of the 22pF ones (oopsie). Unfortunately, doing so resulted in another issue which is that the new capacitor is colliding with the motor driver, so fixing that is gonna be a lot of fun 🫠🫠🫠🫠. Anyway that’s a task for tomorrow."}, {"post_id": 14801, "ts": "2026-06-24T01:22:15Z", "hours": 1.2106, "text": "Dual-motor…drive? I added a second motor and added support for turning in the Pico’s firmware. The main challenge in this session was figuring out how the robot will turn. Since the entire purpose of the Pico is to be the Pi’s personal uber driver, it should have the ability to process almost every command on its own without reliance on the Pi. To put it simply, the Pi won’t say “hey, turn one motor this way and the other one in the opposite direction to create a torque to make the robot spin,”; instead, it will simply say something like “turn this way!” and the Pi will figure out the angle in which it should turn and it will internally compute how it should control the motors. The new command structure is now 2 bits for direction + 2 dummy bits + 4 control bits . Having the 2 bits for direction allows for 4 possible outputs. Since my histogram from the algorithm used intervals of 45 degrees, having 4 of those 45 degree chunks is enough to cover a 180 degree arc. With turning support in both the left and right direction using the command nibbles 0xD and 0xE , respectively, it is possible to complete a full rotation. INFINITE RECURSIONNNNNN Since the robot is supposed to only rotate for a little bit and then resume moving in whatever direction it was going in, I implemented this by using a recursive call to the control function itself and passing in the value of the old command as the new command to execute. This recursive behavior was only meant for turns, not straight movement. As you could guess from the header, this resulted in the program calling itself over and over if I did two turns (since the last command was a turn and it’s last command, by my stupid function call, is also a turn). I patched this by making the program only recall straight moves and not turns, that way it would never have a old_cmd encoding for another turn."}, {"post_id": 13518, "ts": "2026-06-22T03:51:37Z", "hours": 0.4742, "text": "It’s running on the Pi! I used a docker container to allow the web app to be easily hosted on a Raspberry Pi 4. Docker provided a somewhat seamless transition from my local linux environment to the Pi, but I still had to cross compile it for the ARM64 architecture and had to modify a few things Andddd of course I got stuck somewhere in the middle So web apps in docker apparently dont use localhost , instead, they use 0.0.0.0 and expose their port at runtime. This made it quite complicated, because the JavaScript needed to call its websocket from…itself (but on the browser end aka localhost), whereas the Python server would serve 0.0.0.0, which would be then connected to localhost by the daemon. This took me some time to realize, and it was more annoying to recompile the image every time I wanted to make a subtle change."}, {"post_id": 13303, "ts": "2026-06-21T19:42:03Z", "hours": 3.5881, "text": "Hardware Setup + Communication Interfaces drive me crazy Before you look at the time and freak out, I ran into like a dozen errors and each could have been caused by at least ten different independent variables 😭. What did you do? Anyway, I set up a Raspberry Pi 4 (the thing I’m also currently using for my website, www.StatixLabs.org ) and a Pi Pico. I soldered the pins on a DRV8833 motor driver module and connected it to the Pico. I then created 2 UART lines from the Pi to the Pi Pico, allowing them to communicate serially. I then attached a mini N20 motor (with encoders) to the Pico’s motor driver, but this will change when I get the funding to buy motors that can actually sustain the weight of the robot. I then created a command structure in which the Pi transmits a single byte of data to control the motor. The structure of the packet (well, at least I think it’s a packet?) is 4 bits for speed + 4 bits for command . On the regular Pi, I created a script that accepted user input in the form command,speed in which speed was a normalized float, being optional for the command stop which assumes a speed of 0. Commands like forward and backward transmit 0x?A and 0x?B , respectively, and the ? is just a placeholder for the speed nibble. Sooooo, why three and a half hours? Great question! It took me a solid hour to figure out how to use the motors with the Pi Pico. This is because I initially had one of the Undercity themed Pico Devboards, and I thought they were really cool so I didn’t wanna mistakenly ruin the design because of my lousy soldering. So, I just decided to use header pins and sandwiched the devboard in between the header pins and the breadboard. It partially worked, but it was unreliable for the entire right half of the board. I ended up having to use one of my Pico 2’s that I had already soldered, and I also had to change the CMake to account for this. I was extra confused because UART communication worked perfectly fine with my previous sandwich approach, but simple PWM motor control didn’t. Oh well, at least everything worked out in the end after the switch 🫠."}, {"post_id": 12819, "ts": "2026-06-20T23:57:18Z", "hours": 2.4442, "text": "Added Web UI Since the robot is targeted towards a more non-technical audience, I decided that a web interface is much better than a pygame window. This will also be a key part in a “ship” since it’s meant to be “published” and you can’t really publish a pygame script that first of all isn’t even a game lol. I learned how WebSockets work and I made a copy of the graphing script but stripped away the pygame API and added a web server to it. Some challenges I ran into were synchronization, so I solved it by creating a different thread in which the LiDAR runs and sends its data to a buffer, while the main thread runs the web server and sends the buffered data."}, {"post_id": 12150, "ts": "2026-06-19T21:00:23Z", "hours": 2.5475, "text": "Rework + Better Navigation I decided to rewrite the entire pygame display since whoever wrote it before did it totally backwards and it had caused my algorithms to break and a bunch of other problems. So after that pygame refresher, I also reworked my algorithm because tuning the linear max offset seemed to be too unreliable for a broad range of environments and using something like a reciprocal function would make the algorithm amplify noise because my lidar often picks up random particles that are super close to it’s surface (I tried wiping it with a dry cloth; it didn’t work). Anyway, the new algorithm turns the unit circle into a histogram of angles and then calculates the average distance in each interval to determine which direction is the furthest away. The algorithm then picks that direction since it is the best direction that the robot can move in for autonomous navigation (you know, finding new areas?). Anyway, this algorithm is still pretty elementary but it worked first try (well, technically second because of an optimization)."}, {"post_id": 11670, "ts": "2026-06-19T00:41:24Z", "hours": 1.6672, "text": "Basic Navigation Algorithm I implemented a naive navigation algorithm for the robot. the algorithm uses an obstacle avoidance strategy. So far, it uses a linear transform that pushes the robot away from nearby items. However, I noticed that IRL, the LiDAR doesn’t feel the push in the opposite direction until the obstacle gets too close. I’m planning on fixing this later by using an inversion function or something rather than just subtraction."}, {"post_id": 10941, "ts": "2026-06-17T22:49:12Z", "hours": 1.565, "text": "I created a basic scanner by using an RPLiDAR library from a YouTube Video . I adjusted the script for my LiDAR type and fixed a few bugs in the code such as angular positioning inversions. I also started working on the readjustment logic in which the frame is held still when the robot turns by rotating every point on the frame in the opposite direction that it is turning in. I also improved the color logic by using an actual gradient-based shader."}]...
|
Title: Colosseus by @gauss | Stardance
Devlogs:
I Title: Colosseus by @gauss | Stardance
Devlogs:
I created a basic scanner by using an RPLiDAR library from a YouTube Video . I adjusted the script for my LiDAR type and fixed a few bugs in the code such as angular positioning inversions. I also started working on the readjustment logic in which the frame is held still when the robot turns by rotating every point on the frame in the opposite direction that it is turning in. I also improved the color logic by using an actual gradient-based shader.
Basic Navigation Algorithm I implemented a naive navigation algorithm for the robot. the algorithm uses an obstacle avoidance strategy. So far, it uses a linear transform that pushes the robot away from nearby items. However, I noticed that IRL, the LiDAR doesn’t feel the push in the opposite direction until the obstacle gets too close. I’m planning on fixing this later by using an inversion function or something rather than just subtraction.
Rework + Better Navigation I decided to rewrite the entire pygame display since whoever wrote it before did it totally backwards and it had caused my algorithms to break and a bunch of other problems. So after that pygame refresher, I also reworked my algorithm because tuning the linear max offset seemed to be too unreliable for a broad range of environments and using something like a reciprocal function would make the algorithm amplify noise because my lidar often picks up random particles that are super close to it’s surface (I tried wiping it with a dry cloth; it didn’t work). Anyway, the new algorithm turns the unit circle into a histogram of angles and then calculates the average distance in each interval to determine which direction is the furthest away. The algorithm then picks that direction since it is the best direction that the robot can move in for autonomous navigation (you know, finding new areas?). Anyway, this algorithm is still pretty elementary but it worked first try (well, technically second because of an optimization).
Added Web UI Since the robot is targeted towards a more non-technical audience, I decided that a web interface is much better than a pygame window. This will also be a key part in a “ship” since it’s meant to be “published” and you can’t really publish a pygame script that first of all isn’t even a game lol. I learned how WebSockets work and I made a copy of the graphing script but stripped away the pygame API and added a web server to it. Some challenges I ran into were synchronization, so I solved it by creating a different thread in which the LiDAR runs and sends its data to a buffer, while the main thread runs the web server and sends the buffered data.
Hardware Setup + Communication Interfaces drive me crazy Before you look at the time and freak out, I ran into like a dozen errors and each could have been caused by at least ten different independent variables 😭. What did you do? Anyway, I set up a Raspberry Pi 4 (the thing I’m also currently using for my website, www.StatixLabs.org ) and a Pi Pico. I soldered the pins on a DRV8833 motor driver module and connected it to the Pico. I then created 2 UART lines from the Pi to the Pi Pico, allowing them to communicate serially. I then attached a mini N20 motor (with encoders) to the Pico’s motor driver, but this will change when I get the funding to buy motors that can actually sustain the weight of the robot. I then created a command structure in which the Pi transmits a single byte of data to control the motor. The structure of the packet (well, at least I think it’s a packet?) is 4 bits for speed + 4 bits for command . On the regular Pi, I created a script that accepted user input in the form command,speed in which speed was a normalized float, being optional for the command stop which assumes a speed of 0. Commands like forward and backward transmit 0x?A and 0x?B , respectively, and the ? is just a placeholder for the speed nibble. Sooooo, why three and a half hours? Great question! It took me a solid hour to figure out how to use the motors with the Pi Pico. This is because I initially had one of the Undercity themed Pico Devboards, and I thought they were really cool so I didn’t wanna mistakenly ruin the design because of my lousy soldering. So, I just decided to use header pins and sandwiched the devboard in between the header pins and the breadboard. It partially worked, but it was unreliable for the entire right half of the board. I ended up having to use one of my Pico 2’s that I had already soldered, and I also had to change the CMake to account for this. I was extra confused because UART communication worked perfectly fine with my previous sandwich approach, but simple PWM motor control didn’t. Oh well, at least everything worked out in the end after the switch 🫠.
It’s running on the Pi! I used a docker container to allow the web app to be easily hosted on a Raspberry Pi 4. Docker provided a somewhat seamless transition from my local linux environment to the Pi, but I still had to cross compile it for the ARM64 architecture and had to modify a few things Andddd of course I got stuck somewhere in the middle So web apps in docker apparently dont use localhost , instead, they use 0.0.0.0 and expose their port at runtime. This made it quite complicated, because the JavaScript needed to call its websocket from…itself (but on the browser end aka localhost), whereas the Python server would serve 0.0.0.0, which would be then connected to localhost by the daemon. This took me some time to realize, and it was more annoying to recompile the image every time I wanted to make a subtle change.
Dual-motor…drive? I added a second motor and added support for turning in the Pico’s firmware. The main challenge in this session was figuring out how the robot will turn. Since the entire purpose of the Pico is to be the Pi’s personal uber driver, it should have the ability to process almost every command on its own without reliance on the Pi. To put it simply, the Pi won’t say “hey, turn one motor this way and the other one in the opposite direction to create a torque to make the robot spin,”; instead, it will simply say something like “turn this way!” and the Pi will figure out the angle in which it should turn and it will internally compute how it should control the motors. The new command structure is now 2 bits for direction + 2 dummy bits + 4 control bits . Having the 2 bits for direction allows for 4 possible outputs. Since my histogram from the algorithm used intervals of 45 degrees, having 4 of those 45 degree chunks is enough to cover a 180 degree arc. With turning support in both the left and right direction using the command nibbles 0xD and 0xE , respectively, it is possible to complete a full rotation. INFINITE RECURSIONNNNNN Since the robot is supposed to only rotate for a little bit and then resume moving in whatever direction it was going in, I implemented this by using a recursive call to the control function itself and passing in the value of the old command as the new command to execute. This recursive behavior was only meant for turns, not straight movement. As you could guess from the header, this resulted in the program calling itself over and over if I did two turns (since the last command was a turn and it’s last command, by my stupid function call, is also a turn). I patched this by making the program only recall straight moves and not turns, that way it would never have a old_cmd encoding for another turn.
CAD Touch-ups I had previously built a chassis for this robot before in Stasis, but I had never shipped it. Today, I looked at the BOM for the assembly and saw that the metal standoffs that hold the layers together cost more than $2 per piece. I avoided this fee by modeling my own plastic standoffs that had M3 holes on both ends. I also updated the wheels to fit better with the chassis and use less filament. Unfortunately, this increased the mass moment of inertia of the wheels so stopping them and getting them to start might be a future issue? (I hope not tho plsplspls). You have a devboard too? Whatttt Yep! At Stasis, I also made a devboard known as the KineticBoard for this robot. This wasn’t shipped either. Since the devboard was almost complete, I decided to start looking up how to use JLCPCB and realized that I had yet another BOM to fill. Yayyyy🫠. I spent a solid hour figuring JLC out and also saw that one of my capacitor footprints needs to be updated because they don’t make 100uF capacitors in a size that’s expected of the 22pF ones (oopsie). Unfortunately, doing so resulted in another issue which is that the new capacitor is colliding with the motor driver, so fixing that is gonna be a lot of fun 🫠🫠🫠🫠. Anyway that’s a task for tomorrow.
Fixing the KineticBoard Did you know that something as simple as a double-sided version of a Pi Pico can cost around $150 to manufacture from JLC? Yea, I didn’t either. Silkscreen Redesigns! I made some newer art to put as a silkscreen. I think what I had before was okay, but it seemed a bit sloppy. GitHub submodule stuff I updated the KineticBoard Repo and added it as a submodule to my main repository. Capacitor Fix From my last session, I ended with picking a capacitor that had a higher voltage rating since passing 12V through a 6.3V capacitor will definitely cause dielectric breakdown. My solution last time was to use an 25V electrolytic aluminum capacitor, which ended up being too big. To resolve the overlap, I just chose a different SMD Capacitor footprint—this time for a tantalum capacitor since they’re much smaller. Inverted Screw Terminals Apparently the screw terminals were inverted this whole time. I realized this since the arrows were pointing toward the terminals from the center of the board, rather from the outside (the arrows indicate the direction that the wire will enter). I fixed this by rotating each screw terminal by 180 but this just caused 19 DRC violations. Of course, I had to reroute all of the traces that were flipped, and of course I had made it so that fixing one trace blocks the other trace from passing through. I ended up solving this problem by dropping a via and routing the board through one of the 2 middle layers. And it costs WHAT??? Yup. The board itself costs $7, but then JLCPCBA decided to ramp up the cost to $150 with a $50 setup fee, $30 “loading into the feeder” fee, and so on. I’m thinking of buying a hot plate to “solder” all of the SMD parts on the board at home, but some of my caps are 0402 and those things are genuinely microscopic.
Quality-of-life Updates for the Chassis I had used horseshoe-type straps previously in an RC Car design but those had a tendency to slide horizontally. With that in mind, I decided to use the motor’s 2 M3 screws to build a strap on each side of the chassis to lock the motors in place. I’ll still keep one horseshoe clamp for each motor in addition to this for stability purposes.
Assembly Time! Alas, the fun part officially begins! At the time of writing this, most of the parts I ordered online have arrived, with the exception of the custom PCB from JLC. The parts for the chassis just came out of the 3D printer an hour before I started my session, so I had enough parts to finally build the robot! Challenges Building the actual robot brought tiny errors that I had previously overlooked to light. For starters, the 2.5mm trough, while looking very aesthetic, caused the motors to tilt slightly upwards. Additionally, the custom 3D-printed standoffs didn’t really hold on to the M3 screws, so I’m just hoping gravity does its thing. I might have to hot glue them later if more issues arise out of this. Lastly, the motors come with female-to-female cables, but my KineticBoard Leaf expects female-to-male. I might add male headers to the next iteration of the KineticBoard Leaf.
Standoff Redesign The old standoffs had an issue because they weren’t properly threaded, which meant that there really wasn’t much aside from minimal friction that was holding the screws in place. The Fix I redesigned the standoffs by making them wider, thoroughly hollow, and exposed on one half. This allowed me to slide nuts and screws inside the standoffs, which will guarantee a perfect lock. Another issue that this redesign fixed was the blocked hole problem. Essentially, when I put a screw in a hole on the middle chassis, I couldn’t then use that same hole for another standoff to connect the other side. This solves that issue since a single screw on the middle chassis can now go through two standoffs at once, allowing me to connect both sides.
Rebuilt the Robot The new standoffs had finished 3D printing, so I could finally replace the faulty old ones. Since I had to tear the robot down anyway, I decided to fix the motor slant problem as well. The solution to the motor slant problem was relatively simple: some foam padding to lift the motors up to the horizontal. This solution not only worked perfectly, but also gave the robot a little bit of shock absorbance. After that, all I had to do was build the robot with the new standoffs, which was actually quite a chore because it’s hard to use a screwdriver at an angle.
SMD Soldering Attempt The parts from LCSC and JLCPCB had arrived! This meant that I could finally build the final part of the robot: the KineticBoard controller (yk, the devboard with a motor driver on it?). It’s gonna be difficult because I have to solder both sides of the PCB, but so far I only soldered the first side. Some parts were misaligned but it looks mostly ok.
Broken Devboard So this was my first time ever soldering a PCB, and I didn’t go easy on myself especially considering I used 0402 footprints on a 4-layer double-sided layout. I had hoped that it would work after soldering all the parts but unfortunately, it did not. Areas of Error The front portion was soldered using a hot plate, and the back was soldered with a hot air gun. This was my first time using a hot air gun, so I had my dad (a former electronics hobbyist) help me out a little. Turns out we both couldn’t fix it. One potential error is that the back side wasn’t properly soldered because we ran the air gun at 220 degrees fahrenheit, wihch could have meant that the core of the gun was that hot but outside it could be 150 or something. Another thing that could have gone wrong is the ICs could have been overheated and cooked, or a tiny bridge on the RP2040 could have shorted the whole thing. Next Steps and Debug I asked a friend (a guy who has a PhD in computer/rf engineering) to help me debug the board, and he said he’ll be more than happy to in a few weeks. In the meantime, I guess I’ll just make a bunch of more projects!
Lab Visit + THE DEVBOARD WORKS NOW WOHOOO After inhaling a mole of lead-based solder fumes, I finally got the devboard to work!!! It’s my first ever PCB so I’m really stoked!! I visited my friend’s lab at the university where he works and we were able to debug and fix the devboard in a few hours. Unfortunately, I remembered that I had to record the whole thing in lapse in the last 20 minutes, but I guess that’s just karma for taking 9 hours ( ) to hand solder/debug a PCB in my last devlog (yes ik i suck). Issues My previous attempt at soldering failed because I set the temperature of my hot air gun too low, and I overestimated surface tension’s effect on my hot plate. I used a high-res microscope at the lab and saw that most of the QFN components were only partially soldered. I could quite literally see a tiny gap between the two pads. Another thing I saw was some obvious bridging, which I quickly fixed with a soldering iron. One of my biggest takeaways from the lab was that THE TYPE OF SOLDER FLUX MATTERS!!! I previously used some generic $14 flux from Amazon, but it was so bad that even some of the most powerful ultrasonic flux cleaners couldn’t get it off easily. It was also so thick that even the infrared lamp couldn’t get the RP2040 to stick down. My friend used (and recommended) water-soluble flux, which makes it easy to clean off without messy isopropyl alcohol. I ended up salvaging the parts from my old PCB to build a new one from scratch. I learned how to solder QFP packages, 0603s, and even 0402s with an iron. In the end, a soldering iron is THE BEST way to guarantee that your components are soldered down, especially when verified with a microscope. I also learned how to solder using an infrared lamp and hot air (properly, this time). Results??? Right as I finished soldering the last component, I connected it to my computer and held down bootselect….and IT WAS DETECTED AS A MASS STORAGE DEVICE!!! I was so excited at this time that I finally rekindled my motivation to keep building more of these PCBs (I was pretty close to giving up on PCB-related projects ngl). Anyway, right before leaving, I put it in the ultrasonic washer they have for PCBs (which is just a tiny container with water and ultrasonic waves being fired it at from all directions to take the flux off. I’m currently waiting until tomorrow for it to air dry, and then I’ll incorporate it in the robot!
First Drive I checked the devboard for any last errors and connected it to the motors on the robot! Final checks I verified that the KineticBoard Leaf works when it’s powered by USB and by the 5000mAh Li-Ion battery. I did this by writing a simple program that toggles a GPIO pin, and used a multimeter to read the oscillating voltages. It worked!! Test Drive! I already had firmware from the design stage, but it was written for a different motor driver so I decided to start from scratch. I created a basic motor drive “class” (structs/functions to go with the struct) in C and set up my CMake project in a way that I could add a demos folder later. Now that I had custom firmware for the TB6612FNG, I wired up each screw terminal pair to the M1 and M2 pins on each motor, and flipped the switch to see it drive perfectly! It was really relieving to see everything work on first try, and I gained a huge confidence boost in my embedded programming skills. Future Enhancements The motors came with 6-pin connectors, and I should have included appropriate receivers for these connectors on the KineticBoard Leaf rather than just generic screw terminals. Currently, I have to connect the 6-pin connector to 6 jumper wires, which is quite the eyesore.
Soldered the GPIO pins Yea idk why I didn’t do this earlier but I needed the GPIO pins to read data from the motor encoders.
So I Almost Burned My Finger I was trying to get the encoders to work, but in the process of reading data through USB serial, I got a mild shock How Did This Happen? To configure hall effect encoders, you need to give each wheel a good spin to determine how many “pulses” are detected by the Pico. The detection part is quite simple: whenever the wheel turns a certain amount, motor encoders A and B change state. This can be detected through an interrupt and then printed out (in the main loop, not the callback). However, in the process of printing it out, I touched the USB-C receptacle and felt it get extremely hot, and later realized that something got shorted somewhere. Any Guesses Where? Looking back at the situation, I had connected the battery and USB power from my laptop to the board at the same time, so something might have gone wrong there. Another thing that was going wrong was that the receptacle itself was coming off, so it could be that one of the pads, say +5V for instance, came in contact with like GND or smth, inducing shock if someone were to touch it. Here’s an image from the timelapse right before I plugged the board into my laptop and fried it:
Another PCB????? I’m creating a second motor driver board, but this time instead of being a standalone devboard, it is only a hat. Schematic Stuff I added symbols for header sockets, the barrel jacks, a buck converter, and the usual dozens of resistors and caps. The pinout for the buck converter was so annoying and something about putting non-connecting wires on top of each other pissed me off a lot. It’s an eyesore, and I can already tell that I have to use a billion vias to get everything working once I’ll hit the layout stage.
Finished KineticBoard HAT Schematic I spent a few hours finishing the schematic for the KineticBoard HAT, an extension board that allows the Pi Pico to control motors. Additions Rather than using a standard Li-Ion to power the Pico and a really small power bank to power the Pi, I decided to just use one: the Li-Ion. For this to happen, the PCB would need to convert 12V to 5V and expose this voltage through a USB-C connector. I decided to copy & paste my old buck converter schematic, but I had to pick different resistance values such that this formula V = 0.925 * (1 + R1/R2) yielded ~5.1V. This seems easy, but I wanted to use some resistors that I already had. I decided to make a C program that picked the most optimal values for this voltage divider. The program works by following a 2 pointer algorithm which adjusts the numerator and the denominator by shuffling through a sorted list of the resistance values, and finding the ones that are closest to the target voltage. I also expanded on my old buck converter by making the +3V3 net controlled by a switch, just so that no weird stuff happens if I connect both the PC and battery to the board at the same time. Lastly, I added the 6-pin JST connectors, the motor driver, and a few status LEDs. I put everything in the PCB editor in the end, and I’m honestly terrified of routing this thing, but that’s a problem for later lol.
Almost Done with the Layout With the components oriented in their city-like pattern, all that was left to do was to pave the final roads through the green adhesive base, connecting the motor driver to the 6-pin adapters. Changes? I decided to drop the 12V to 3.3V buck because the Pico has one internally, and I could just keep my 5V buck and feed its output into VSYS and extract 3.3V from the Pico’s +3V3 pin. I also ended up changing the orientation of some adapters because I couldn’t comprehend the fact that the PCB exists in 3 dimensions? Lastly, I greedily extended the bottom of the PCB so that both partitions could access one large +12V trace (the GPIO sockets were interfering). What next? All I have to do is wire up the connections to the motor driver and adapters, and we should be good to manufacture ts.
Finished the PCB The final coat of copper pavement was carefully laid out as the green city was unified at last. Changes I routed the motor driver’s pins to the two 6-pin adapters on the bottom right of the board. I connected the last pads, and added some finishing touches such as screw holes for a 3D-printed enclosure and some custom silkscreen cuz why not. I also filleted the edges as I read that it was a good practice online. What’s Next? All of the GND pads are isolated, so I need to make a copper fill zone or something to link all of them. I also plan on adding a little silkscreen on the back, and then we should be good to go!
Sent out the order! After finalizing the last parts of the extension board, I used my hardware grant to send the PCB over to JLC for fabrication. I separately purchased parts from LCSC.
Custom Enclosure for the PCB After the board had travelled across the Pacific Ocean and the United States, it finally reached its destination at the core of Colosseus. UPDATE: THE PCB AND THE LCSC PARTS HAVE ARRIVED!!!! Whadidyado? I started creating a case for the KineticBoard. So far, I copied the layout of the board from KiCAD and added cutouts for parts that were meant to have user interaction. I tested out three prototypes before settling on one that actually fit (a lot of issues were solved by adding extra clearance and gaps). Potential Issues I’m 70% certain that the case won’t fit the bottom floor of the chassis, but that’s a problem for later. For now, I’m just designing the most badass case I can.
THE BOARD IS ON FIRE Not really, but it kinda is. After soldering all of the components on with an iron and hot plate, I connected the Pi Pico to the HAT via the female header sockets. I wrote a simple blinky script and verified that it worked when powered by my regular laptop. However, when I powered the KineticBoard HAT with the Pico, the RP2040 chip started smoking and I was able to capture a brief orange glow on camera. What now?? I’ll have to carefully look at what could have gone wrong. I tested the voltage readings from the multimeter and found that VSYS reads +5.1V when switched on, which makes sense because the Pico can accept that much. I did notice a constant 0.5V on the +3V3 pin for whatever reason (before attaching the pico). I’ll isolate the Pico on a breadboard and attach jumper wires only where needed, and gradually close in on the part that caused the failure. On a side note, I figured out why one of the LEDs isn’t working. It happens to not be connected to GND; however, everything else seems to be connected just fine.
IT WORKSSSSS ok sit tight brodini cuz i got a lot of stuff to tell you I burned another PCB! yea, u sure heard that right. I found out what the issue with the PCB was: the motor driver was in the wrong orientation, which connected the +12V rail itself to a gpio pin, frying the rp2040 entirely. Instead of using my hot air station to de-solder and rotate the driver, I decided to just make another board because I was lazy. The second board ended up not working either, and when I pressed down on one of the legs of the buck converter with a multimeter, the IC caught on fire and started smoking. I ended up needing to use a hot air station to replace the buck converter on that board, so I used it to heat up and fix the driver on my previous board while I was at it. I now have two working boards but does it really work? yup. how do you know? because I’m built like that I dont think so stfu ANYWAY…FIRMWARE TIMEEEE The best way to verify the board works is to test out its main feature: controlling Colosseus’ motors (goddamn I’ve spent so much time on the pcb that I’m still not comfortable with the actual name of the robot). I wrote some code in C to blink the KineticBoard’s onboard led, built and flashed the .uf2 to the pico, connected it to the board, andd… … … … IT DIDN’T CATCH ON FIRE! (that’s a first) it actually blinked the LED like it was supposed to. wow. With that boost in confidence, I was more inclined to write code for the robot itself. I started scaffolding a library for the robot, which I’m calling KineticLib . So far, I’ve written code to simplify PWM channels because the TB6612FNG motor driver relies on two of them. I tested my library by adding a demo project that makes the robot incrementally increase in speed, and then come back in the same manner. It worked too! things I HAVEN’T tested yet connecting the Pico to USB while it’s attached to the hat using the usb-c rececptacle to power other stuff (like a regular rpi) observing the effect of forcing the motors to spin while they are connected to the KineticBoard (I tried this briefly and I smelled some type of smoke, but I could very well just be paranoid) but yea all in all 11/10 experience i would highly recommend trying to make one of these on your own. if you happen to be brave enough to test these before I do, lmk what happens on slack (if you survive).
Started the Firmware I wrote some code to test the motors and the encoders. So far, the motors spin as they should, but I’m having some difficulty with the encoders. The encoders are needed for a PID loop, which is crucial for the robot as it needs to follow a straight path. Next steps Debug the code for the encoders and add UART input.
Fixed the Encoders I was previously stuck on the encoders for a long time, so I created a script in MicroPython to debug the issue. I found that it worked perfectly fine when I isolated everything on a breadboard, and then realized that in my PCB I had flipped the orientation of the 6-pin connectors. I ended up having to de- and re-solder the connectors with a hot air gun, but the C code still didn’t work. After a quick Google search, I found that you could only use one callback method for an IRQ on each core. I was using two: one for each encoder. I fixed this by making a larger callback function that invoked the individual callbacks depending on the GPIO pin. Long story short: it works!
Debugging the Adapters and RPM I had noticed that one of the motor’s LED’s kept flickering on and off, and decided to remove the part to isolate the issue. I found that one of the cables was loose, and there wasn’t an easy way for me to fix this without risking melting the plastic off. So, I placed an order for new cables. I also started working on RPM calculations because Colosseus needs to know how fast it’s going. I’m using a timer that repeatedly calculates the displacement in rotation, which is needed to calculate rotational speed. So far, I just have a small demo of this working, but I plan to use this later in a feedback loop to regulate the robot’s speed....
|
1793411830.2722025
|
1794016630.2722025
|
|
39766
|
Astro Lens by @abdu11ah_aidev | Stardance
|
abdu11ah_aidev
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Astro Lens by @abdu11ah_aidev | Stardance
|
1793411828.4093149
|
1794016628.4093149
|
|
23855
|
My very own WebOS by @rangetrooper22 | Stardance
|
rangetrooper22
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My very own WebOS by @rangetrooper22 | Star Title: My very own WebOS by @rangetrooper22 | Stardance...
|
1793411827.4992464
|
1794016627.4992464
|
|
38291
|
my APOD site by @infiloo | Stardance
|
infiloo
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: my APOD site by @infiloo | Stardance
|
1793411825.720299
|
1794016625.720299
|
|
8204
|
Tek Note by @alexandre_ngo | Stardance
|
alexandre_ngo
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Tek Note by @alexandre_ngo | Stardance
|
1793411824.4346654
|
1794016624.4346654
|
|
2168
|
Phoenix 1 - Prototype by @Yagna | Stardance
|
Yagna
|
0
|
18.75
|
0
|
[]
|
[{"post_id": 30073, "ts": "202 [{"post_id": 30073, "ts": "2026-07-17T11:20:36Z", "hours": 9.6183, "text": "Progress Devlog 2 - Phoenix 1: So basically, YOLO didn’t really work out, so I had to delete it because I didn’t have enough RAM on my Raspberry Pi. Instead, I got ROS 2(Specifically ROS 2 Jazzy, an older version released for Ubuntu 24.04.02). For my original version of main.py, which is a system that launches 4 separate files(Ultrasonics and Motors, both arduino and python). Now using ROS 2 I built a separate mapping system called Rviz2, which is a very versatile mapping system that can spawn things like walls and stuff, and its pretty cool. But then I had to create a bunch of new files, like “phoenix_config.rviz” and I needed to create a new launching system called ./launch.sh, which booted the necessary rviz terminal commands and my main.py simultaneously. I also made something called an RF Model, also known as Random Forest. What’s Random Forest? It’s basically a module that you can import via python that uses ultrasonic readings and turns them into basic YOLO detection: Like “Corner” or “Left Wall” and that RF communicates to my Rviz2 display, telling it to snap walls or stuff like that when it detects “Corner” or “T-Junction”. For my RF Model, I used a CSV file which uses my binary encodings(1 for blocked ultrasonic and 0 for not blocked ultrasonic). It was pretty simple, and with my 4 ultrasonic sensors I was able to create 16 total types of obstacles through my RF: 0,0,0,0,Path Clear 1,1,0,0,Left Corner Trap 1,0,1,0,Right Corner Trap 1,1,1,0,Dead End 1,1,1,1,Total Box Trap 0,1,1,0,Narrow Choke Point 0,0,0,1,Back Blocked 0,1,0,0,Left Wall 0,0,1,0,Right Wall 1,0,0,0,Front Wall 1,1,0,1,T-Junction Right Open 1,0,1,1,T-Junction Left Open 1,0,0,1,Fork 0,1,1,1,U-Tunnel Forward Open 0,1,0,1,Left Lane Guard 0,0,1,1,Right Lane Guard I also created a few JSON files with timestamps and stuff to log where the walls were created in Rviz2 and when and stuff like that: [ { \"label\": \"Front wall\", \"timestamp\": \"Jul 16 15:49\", \"coordinates\": [ 3.0, 0.0 ] }, { \"label\": \"Front wall\", \"timestamp\": \"Jul 16 15:49\", \"coordinates\": [ 3.0, -0.25 ] } ] So that’s basically what I spent my 9 hours of precious time on. It was Lwk such a pain but it was worth it."}, {"post_id": 23768, "ts": "2026-07-06T21:58:27Z", "hours": 1.2544, "text": "Progress Devlog 1 - Phoenix 1: If you saw my previous devlog, you should know what Phoenix 1 is. However, if you didn’t read it(Which you probably should :) ) you’re probably wondering: What is Phoenix 1? Well, it’s an obstacle avoidance robot that is known as an SAR(Search & Rescue). It uses sensor pads featuring thermal and ultrasonic sensors to navigate its way through tough terrain. It also uses things like a servo to drive its way through rubble and save lives! Today(Or maybe another day when you read this) I worked on my motor drivers and motors, and implemented a smart-driving system that utilizes specific readings that it is trained to recognize to understand how to maneuver itself through those places. I used Binary Code for this to implement a less than, and more than {distance} system. Here’s basically what I did in python: def process_distances_to_flags(front, left, right, back): # 1 if less than threshold (blocked), 0 if clear f_blocked = 1 if front < 150 else 0 l_blocked = 1 if left < 150 else 0 r_blocked = 1 if right < 145 else 0 b_blocked = 1 if back < 150 else 0 return [f_blocked, l_blocked, r_blocked, b_blocked] # Example: If your live readings are [400, 120, 80, 400] processed_data = process_distances_to_flags(400, 120, 80, 400) print(processed_data) # Output will be: [0, 1, 1, 0] I still have a way to go before I finish, but I feel like I have good progress. Also, if you can, please try to explain why a 12 V DC Motor doesn’t work, even though I have the right wirings with my L298N motor drivers(Lwk stuck here). This is still what I have on my checklist though to complete for my SAR: Implementing Smart-Terrain Driving - Partial Fix the Motors - Partial Get a Ras Pi Camera, as well as a Hailo 10h(Separate VRAM hardware) for YOLO(See my What’s YOLO devlog for more!) Get a Power module & Thermal sensors Design Sensor Pads and Test PCBs(KiCad is what I use)"}, {"post_id": 22587, "ts": "2026-07-05T03:38:03Z", "hours": 0.6039, "text": "Have you ever heard of YOLO? If you’re a normal person, you may have heard of it as the saying: “You only live once :)” But, if you’re a computer-geek or a hack clubber, you may have also heard it as “You Only Look Once” However, what’s the difference? Well, YOLO is an AI Software that is a real-time image detection algorithm. It’s kind of like a Mock-LiDAR in a sense. If you have a regular camera, it generally isn’t possible to have a sense of perception, unlike LiDAR, which fires lasers to have depth. Below is how I used YOLO in my project! My project uses a Raspberry Pi camera from Waveshare, and a few ultrasonic(HC_SR04) sensors for distance detection. I used YOLO nano to take the readings from my dist. sensors and camera and know what exactly is in front of me, not just a “thing”."}, {"post_id": 21539, "ts": "2026-07-03T15:44:46Z", "hours": 7.2725, "text": "What’s Phoenix 1? Started on my very cool robot, which uses different sensors like ultrasonic sensors and heat sensors, to detect its surroundings. To be more specific, it is an SAR(Search and Rescue) Robot, which rescues people in different terrains by using sensor pads as well as LiDAR(A thing that uses 3D Scanning to acknowledge the environment around them.) I just finished coding my ultrasonic sensors(Sensors that record distance: if you’re like ‘IDK what that is’) and tested them. They are good to go! My next goals: That will hopefully be done :) Motors and Motor Drivers PCB Design using KiCAD(More on that in my later posts) Camera AI Module + Servos Below is my code that I used for the ultrasonic sensors, I just used an arduino nano as an extension to manage the sensors, and python as a translator and stuff, in VSCode. You can see the rest of my code in my git repo(Which i will be posting soon)"}]...
|
Title: Phoenix 1 - Prototype by @Yagna | Stardance Title: Phoenix 1 - Prototype by @Yagna | Stardance
Devlogs:
What’s Phoenix 1? Started on my very cool robot, which uses different sensors like ultrasonic sensors and heat sensors, to detect its surroundings. To be more specific, it is an SAR(Search and Rescue) Robot, which rescues people in different terrains by using sensor pads as well as LiDAR(A thing that uses 3D Scanning to acknowledge the environment around them.) I just finished coding my ultrasonic sensors(Sensors that record distance: if you’re like ‘IDK what that is’) and tested them. They are good to go! My next goals: That will hopefully be done :) Motors and Motor Drivers PCB Design using KiCAD(More on that in my later posts) Camera AI Module + Servos Below is my code that I used for the ultrasonic sensors, I just used an arduino nano as an extension to manage the sensors, and python as a translator and stuff, in VSCode. You can see the rest of my code in my git repo(Which i will be posting soon)
Have you ever heard of YOLO? If you’re a normal person, you may have heard of it as the saying: “You only live once :)” But, if you’re a computer-geek or a hack clubber, you may have also heard it as “You Only Look Once” However, what’s the difference? Well, YOLO is an AI Software that is a real-time image detection algorithm. It’s kind of like a Mock-LiDAR in a sense. If you have a regular camera, it generally isn’t possible to have a sense of perception, unlike LiDAR, which fires lasers to have depth. Below is how I used YOLO in my project! My project uses a Raspberry Pi camera from Waveshare, and a few ultrasonic(HC_SR04) sensors for distance detection. I used YOLO nano to take the readings from my dist. sensors and camera and know what exactly is in front of me, not just a “thing”.
Progress Devlog 1 - Phoenix 1: If you saw my previous devlog, you should know what Phoenix 1 is. However, if you didn’t read it(Which you probably should :) ) you’re probably wondering: What is Phoenix 1? Well, it’s an obstacle avoidance robot that is known as an SAR(Search & Rescue). It uses sensor pads featuring thermal and ultrasonic sensors to navigate its way through tough terrain. It also uses things like a servo to drive its way through rubble and save lives! Today(Or maybe another day when you read this) I worked on my motor drivers and motors, and implemented a smart-driving system that utilizes specific readings that it is trained to recognize to understand how to maneuver itself through those places. I used Binary Code for this to implement a less than, and more than {distance} system. Here’s basically what I did in python: def process_distances_to_flags(front, left, right, back): # 1 if less than threshold (blocked), 0 if clear f_blocked = 1 if front < 150 else 0 l_blocked = 1 if left < 150 else 0 r_blocked = 1 if right < 145 else 0 b_blocked = 1 if back < 150 else 0 return [f_blocked, l_blocked, r_blocked, b_blocked] # Example: If your live readings are [400, 120, 80, 400] processed_data = process_distances_to_flags(400, 120, 80, 400) print(processed_data) # Output will be: [0, 1, 1, 0] I still have a way to go before I finish, but I feel like I have good progress. Also, if you can, please try to explain why a 12 V DC Motor doesn’t work, even though I have the right wirings with my L298N motor drivers(Lwk stuck here). This is still what I have on my checklist though to complete for my SAR: Implementing Smart-Terrain Driving - Partial Fix the Motors - Partial Get a Ras Pi Camera, as well as a Hailo 10h(Separate VRAM hardware) for YOLO(See my What’s YOLO devlog for more!) Get a Power module & Thermal sensors Design Sensor Pads and Test PCBs(KiCad is what I use)
Progress Devlog 2 - Phoenix 1: So basically, YOLO didn’t really work out, so I had to delete it because I didn’t have enough RAM on my Raspberry Pi. Instead, I got ROS 2(Specifically ROS 2 Jazzy, an older version released for Ubuntu 24.04.02). For my original version of main.py, which is a system that launches 4 separate files(Ultrasonics and Motors, both arduino and python). Now using ROS 2 I built a separate mapping system called Rviz2, which is a very versatile mapping system that can spawn things like walls and stuff, and its pretty cool. But then I had to create a bunch of new files, like “phoenix_config.rviz” and I needed to create a new launching system called ./launch.sh, which booted the necessary rviz terminal commands and my main.py simultaneously. I also made something called an RF Model, also known as Random Forest. What’s Random Forest? It’s basically a module that you can import via python that uses ultrasonic readings and turns them into basic YOLO detection: Like “Corner” or “Left Wall” and that RF communicates to my Rviz2 display, telling it to snap walls or stuff like that when it detects “Corner” or “T-Junction”. For my RF Model, I used a CSV file which uses my binary encodings(1 for blocked ultrasonic and 0 for not blocked ultrasonic). It was pretty simple, and with my 4 ultrasonic sensors I was able to create 16 total types of obstacles through my RF: 0,0,0,0,Path Clear 1,1,0,0,Left Corner Trap 1,0,1,0,Right Corner Trap 1,1,1,0,Dead End 1,1,1,1,Total Box Trap 0,1,1,0,Narrow Choke Point 0,0,0,1,Back Blocked 0,1,0,0,Left Wall 0,0,1,0,Right Wall 1,0,0,0,Front Wall 1,1,0,1,T-Junction Right Open 1,0,1,1,T-Junction Left Open 1,0,0,1,Fork 0,1,1,1,U-Tunnel Forward Open 0,1,0,1,Left Lane Guard 0,0,1,1,Right Lane Guard I also created a few JSON files with timestamps and stuff to log where the walls were created in Rviz2 and when and stuff like that: [ { "label": "Front wall", "timestamp": "Jul 16 15:49", "coordinates": [ 3.0, 0.0 ] }, { "label": "Front wall", "timestamp": "Jul 16 15:49", "coordinates": [ 3.0, -0.25 ] } ] So that’s basically what I spent my 9 hours of precious time on. It was Lwk such a pain but it was worth it....
|
1793411823.2912312
|
1794016623.2912312
|
|
21501
|
Nicholas' OS by @nicholas1023 | Stardance
|
nicholas1023
|
1
|
7.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-06-23T03:52:32Z", "hours": 7.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "I made a web-based OS that includes a panel with a clock and power off button, a file viewer, a terminal version of my personal website, and a web app installer that allows you to install websites that are not web app as well. The most challenging part was the web app installer as I needed to develop the logic to integrate the website as an app and allow them to have a top bar as well. I was quite surprised with the result, as it was able to make a website look like a native app (In fact, the terminal is a web app!) and the power off button made it really look like a real low level OS running on a computer. One thing to note is that the installer is not able to launch sites that disallow 3rd party embedding.", "repo": "https://github.com/Nicholas1023/Nicholas-OS", "demo": "https://nicholas1023.github.io/Nicholas-OS/"}]...
|
[{"post_id": 14133, "ts": "202 [{"post_id": 14133, "ts": "2026-06-23T03:35:05Z", "hours": 2.4094, "text": "New app installer for my OS! In this devlog, I have created an app installer that installs a website as an app, much like how a web app works. However, this function only works for URLs that allow embedding. I have also solved a bug where apps dragged past the viewport creates a scrollable viewport by adding this: overflow-y : hidden ; overflow-x : hidden ; I’ll be shipping it soon! Try my OS out at https://nicholas1023.github.io/Nicholas-OS/ ! Here’s a demo video of the installer installing hackclub.com as an app!"}, {"post_id": 13649, "ts": "2026-06-22T12:24:39Z", "hours": 2.3744, "text": "Added new apps to my OS! I’ve added a file viewer and terminal app to my operating system! What’s new? Window dragging finally works! Windows are able to move to the front! Problems I’ve faced I had issues making a window come to the front when clicked or move. Initially, I was using .style.zIndex++ , but it did not seem to work when a window was clicked multiple times. To solve this, I changed all the z-index of all windows when one is clicked, to ensure all of the values sync. The buttons on the top bar are currently text-based, so I’ll be creating icons for them, and to declutter the buttons top bar on apps."}, {"post_id": 13528, "ts": "2026-06-22T04:24:03Z", "hours": 2.0283, "text": "Finished the windowing system and a bottom panel! What’s new Loading screen Windows with maximise, minimise and close buttons Bottom panel with time and power off button What I’ll be working on next Next, I will be making the windows draggable, and creating icons for the apps. I’ll also be improving the loading screen, which currently only consists of the following code. <div id= \"boot\" > <div style= \"text-align: center;\" > <h1> Nicholas' Operating System </h1> <p id= \"loading\" > Loading... </p> </div> </div> Problems I faced When creating the window functions, which manages maximise, minimise and close buttons, it did not seem to work. I realised later that the function name was actually overwriting a built-in function as it was initially named close() ! In the end I renamed it to closeW() , where W stands for window. I also faced issues with the height of the <main> . Initially, the height of main was set to 100% , which failed to work. After some searches online, I tried replacing 100% with 100dvh , which worked perfectly!"}]...
|
Title: Nicholas' OS by @nicholas1023 | Stardan Title: Nicholas' OS by @nicholas1023 | Stardance
Devlogs:
Finished the windowing system and a bottom panel! What’s new Loading screen Windows with maximise, minimise and close buttons Bottom panel with time and power off button What I’ll be working on next Next, I will be making the windows draggable, and creating icons for the apps. I’ll also be improving the loading screen, which currently only consists of the following code. <div id= "boot" > <div style= "text-align: center;" > <h1> Nicholas' Operating System </h1> <p id= "loading" > Loading... </p> </div> </div> Problems I faced When creating the window functions, which manages maximise, minimise and close buttons, it did not seem to work. I realised later that the function name was actually overwriting a built-in function as it was initially named close() ! In the end I renamed it to closeW() , where W stands for window. I also faced issues with the height of the <main> . Initially, the height of main was set to 100% , which failed to work. After some searches online, I tried replacing 100% with 100dvh , which worked perfectly!
Added new apps to my OS! I’ve added a file viewer and terminal app to my operating system! What’s new? Window dragging finally works! Windows are able to move to the front! Problems I’ve faced I had issues making a window come to the front when clicked or move. Initially, I was using .style.zIndex++ , but it did not seem to work when a window was clicked multiple times. To solve this, I changed all the z-index of all windows when one is clicked, to ensure all of the values sync. The buttons on the top bar are currently text-based, so I’ll be creating icons for them, and to declutter the buttons top bar on apps.
New app installer for my OS! In this devlog, I have created an app installer that installs a website as an app, much like how a web app works. However, this function only works for URLs that allow embedding. I have also solved a bug where apps dragged past the viewport creates a scrollable viewport by adding this: overflow-y : hidden ; overflow-x : hidden ; I’ll be shipping it soon! Try my OS out at https://nicholas1023.github.io/Nicholas-OS/ ! Here’s a demo video of the installer installing hackclub.com as an app!
Ships:
I made a web-based OS that includes a panel with a clock and power off button, a file viewer, a terminal version of my personal website, and a web app installer that allows you to install websites that are not web app as well. The most challenging part was the web app installer as I needed to develop the logic to integrate the website as an app and allow them to have a top bar as well. I was quite surprised with the result, as it was able to make a website look like a native app (In fact, the terminal is a web app!) and the power off button made it really look like a real low level OS running on a computer. One thing to note is that the installer is not able to launch sites that disallow 3rd party embedding....
|
1793930221.7149591
|
1794016621.7149591
|
|
25878
|
My awesome macropad! by @ngokhongyeuduongtang | St My awesome macropad! by @ngokhongyeuduongtang | Stardance...
|
ngokhongyeuduongtang
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @ngokhongyeuduongta Title: My awesome macropad! by @ngokhongyeuduongtang | Stardance...
|
1793411821.130093
|
1794016621.130093
|
|
23948
|
Animatronic Head by @phyroxyn | Stardance
|
phyroxyn
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Animatronic Head by @phyroxyn | Stardance
|
1793411820.2654848
|
1794016620.2654848
|
|
40009
|
My own site! by @chetankenchgoudar35 | Stardance
|
chetankenchgoudar35
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My own site! by @chetankenchgoudar35 | Star Title: My own site! by @chetankenchgoudar35 | Stardance...
|
1793411819.3685894
|
1794016619.3685894
|
|
19459
|
BLarm by @mygulash | Stardance
|
mygulash
|
0
|
7.78
|
0
|
[]
|
[{"post_id": 81537, "ts": "202 [{"post_id": 81537, "ts": "2026-10-21T16:44:43Z", "hours": 7.7839, "text": "Blarm aka Bee alarm 🐝🐝🐝 I have built the schematic and the case now my goal is to ship it to receive the parts so i can actually build it irl!"}]...
|
Title: BLarm by @mygulash | Stardance
Devlogs:
Bl Title: BLarm by @mygulash | Stardance
Devlogs:
Blarm aka Bee alarm 🐝🐝🐝 I have built the schematic and the case now my goal is to ship it to receive the parts so i can actually build it irl!...
|
1793411818.433652
|
1794016618.433652
|
|
6585
|
My awesome macropad! by @kevinisslashed | Stardanc My awesome macropad! by @kevinisslashed | Stardance...
|
kevinisslashed
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My awesome macropad! by @kevinisslashed | S Title: My awesome macropad! by @kevinisslashed | Stardance...
|
1793411817.5407944
|
1794016617.5407944
|
|
1125
|
LEGO walker by @Jacktheengineer | Stardance
|
Jacktheengineer
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: LEGO walker by @Jacktheengineer | Stardance
|
1793411816.6217163
|
1794016616.6217163
|
|
33161
|
Untitled project by @FloraFox | Stardance
|
FloraFox
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled project by @FloraFox | Stardance
|
1793411815.7397726
|
1794016615.7397726
|
|
20723
|
Untitled by @matthiaslubbertsen | Stardance
|
matthiaslubbertsen
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: Untitled by @matthiaslubbertsen | Stardance
|
1793411814.8583665
|
1794016614.8583665
|
|
24938
|
My first slack bot! by @AwesomeFreshDay | Stardanc My first slack bot! by @AwesomeFreshDay | Stardance...
|
AwesomeFreshDay
|
1
|
1.0
|
0
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-07-02T21:51:57Z", "hours": 1.0, "multiplier": null, "payout": 0, "blessing": "neutral", "text": "Simple Slack bot running on Nest server 24/7 with 6 different commands Name Description /adam-ping Pings the bot /adam-help Provides help /adam-catfact Provides cat fact /adam-joke Provides a joke /adam-color Porivde’s Adam’s favorite color /adam-sport Provides Adam’s favorite sport", "repo": "https://github.com/AdamT2529/Build-a-Slack-Bot", "demo": "https://app.slack.com/client/E09V59WQY1E/C0P5NE354?skip_today=1"}]...
|
[{"post_id": 21094, "ts": "202 [{"post_id": 21094, "ts": "2026-07-02T21:48:53Z", "hours": 0.8267, "text": "Finished creating the slack bot with different commands"}]...
|
Title: My first slack bot! by @AwesomeFreshDay | S Title: My first slack bot! by @AwesomeFreshDay | Stardance
Devlogs:
Finished creating the slack bot with different commands
Ships:
Simple Slack bot running on Nest server 24/7 with 6 different commands Name Description /adam-ping Pings the bot /adam-help Provides help /adam-catfact Provides cat fact /adam-joke Provides a joke /adam-color Porivde’s Adam’s favorite color /adam-sport Provides Adam’s favorite sport...
|
1793930214.7092419
|
1794016614.7092419
|
|
39710
|
My own site! by @Oddish | Stardance
|
Oddish
|
0
|
0.0
|
0
|
[]
|
[]
|
Title: My own site! by @Oddish | Stardance
|
1793411813.9351933
|
1794016613.9351933
|