Devlog 6

Hello everyone, I’m back after a very long break because of school. This is gonna be my last devlog.

I found a quick gap in my schedule and fixed some of the problems in my design. I started by making the holes for the keys one big hole as recommended by my reviewer so that all the keys seat perfectly now. Next I went into the code and added some basic functionality such as setting the alarm time, making the keys work, and setting the current time, once again as recommended by my reviewer. I wasn’t full certain about how to do this so I used AI to come up with some ideas and learn before attempting.

Anyways, I’m gonna keep this brief. I really enjoyed this program, thanks HackClub for running it.

Devlog 5

Finally, all done. I found a small break in my routine and put in some work on the alarm clock and ended up finishing.

I cleaned up the CAD by filleting most of the edges and adding holes for the sound and power cable. I also changed the colour to black. I then went back to KiCad and flipped the MCU, buzzer, and pin header.

Finally, I followed the guide for the firmware, which was very easy to follow along with and finished everything up. Now I just need to commit everything to GitHub and submit my design for funding.

Devlog 4

I found a lot of errors with my previous design. A lot of things just wouldn’t fit together if I went with the flat design and I just couldn’t figure out a clean way to make it work.

So, I pivoted. I looked online for some cool alarm clock designs and found one I liked. It was kinda pyramid shaped and I hadn’t seen an alarm clock like it. More importantly, it worked with what I already had and didn’t require to many changed to the PCB.

So I started CADing, but ran into another issue. In F360 the shell tool makes a cavity inside a shape that mirrors its outside. So a pyramid shaped hole in a pyramid. But this means that my screws would have to follow the tilt of the pyramid. I tried making it work, but failed. So I restarted and found a way to make just the corners straight (see pictures if this doesn’t make sense) so my screws could go straight in.

Overall, I ran into a bunch of small issues that caused the two CAD restarts, but we got through it. I also added the supports for the PCB but was limited to only 3 so that the display pins still had room.

My next steps are some more design work to make it look nicer, and I need to flip my MCU and buzzer in KiCad, but then I’m done. This honestly took longer than I expected. The CAD took soooo long this time because of tiny mistakes or oversights I made in the past.

Devlog 3

After completing my schematic and PCB design I moved onto the case. Just like last time I’m expecting this to take the longest as with my hackpad I noticed problems while making my case that required me to go back and edit my PCB and in some cases my schematics.

I’ve already run into issues like that and what makes it a bit more difficult is that I’m using F360 while the tutorial is using OnShape, thought seeing as my design is different from that in the tutorial I doubt how helpful it would’ve been to begin with.

I’ve already had to restart once, but I’ve made some solid progress.

Devlog 2

The design phase went pretty well. It helped that I had a design almost immediately when I saw the parts.

Moving on to the next part of design, the schematic phase also went by quickly now that I had the hackpad to reference. I started working on my PCB and ran into the first small roadblock. Where do I put the microcontroller? I don’t want to have an awkward empty space at the top of my case, but I still need room for it. I thought I’d just deal with the problem later and eventually settled on putting it on the side of the key matrix.

Then KiCad decided to crash without saving my PCB.
About 45mins of work just gone. So I had to restart the PCB design. But it wasn’t entirely bad. I realized the empty space that the microcontroller took up could be where the screen went. This would also allow me to make my alarm clock thinner as well.

So I guess thanks, KiCad, for crashing. Please never do that again.

PS. Why was the microcontroller on the schematic different from the one in the PCB? I triple checked and made sure I chose the same options as they did.

Devlog 1

Another build! After my hackpad project got accepted, I saw this pop up but didn’t really have the time to start on it till now. However, as soon as I saw it (esp the parts), I knew exactly what I was gonna build. I have this alarm clock app that requires me to play a game where I memorize a sequence of squares and tap them in order. Seeing as I was getting keys as part of the kit, my mind instantly went towards building a physical version of that. Unlike with the hackpad project, I had some experience to work off, so this time I didn’t make the mistake of overcomplicating things. The “squares” will be a 2x3 matrix of keys. I also know how to use the tools (KiCad, Fusion360) a lot better, so I’m already seeing things going way faster.

Next steps are routing the PCB and designing the case.

Devlog 5

The physics is completely broken 😭😭😭😭. I’ve spent many hours trying to fix this but every problem I solve leads to 10 more (quite litterally). I’ve realized that I’ve been mixing real units (ms^-1/2, s, N, J) with pixels which broke everything. I fixed it but now I have other problems that I have no idea how to solve at this point.

My biggest problem right now is that no matter which direction I turn the rocket it only ever moves stright up. This has quickly become the most complex project I’ve ever made and I’m honestly starting to forget what some of the functions and files I’ve made even do.

This also means that every time I try to solve a problem I run into 10 more. As of now my thinking is that the velocity vector isn’t turning, but this is exaclty what I was thinking 4 hours ago.

My rocket also bounces now, for some reason 💀💀.

Devlog 4

I’ve just about finished the build menu and now I’ve completely revamped the physics. This took way longer than I imagined and it still somehow doesn’t work.

In this session I added:

• a camera system to follow the rocket
• a way for the rocket to fly
• a gravity system
• a way to rotate the rocket
• more parts (engines, fuel tanks, etc.)
• Inertia, center of mass, moment of inertia (a bunch of physics stuff)

I’ve reached a point where my knowledge of high school physics isn’t enough, so now I’m having code and research. I plan of using AI to learn some of the more advanced concepts and help me with the integration with my code.

My next steps include making the physics system way better as it still is very unrealistic. I also want to add in a crash mechanic, space, the moon, a landing mechanic, and a trip screen where the user can view their whole trajectory on a map of space.

Overall, I’ve got lots of work to still do.

Devlog 3

As I did before, I’ve gone over my code and changed a whole bunch of things. This time it’s mainly UI and UX upgrades like:

• Nicer colours
• Build area background
• Scrollable parts list
• Revamped part sprites
• New part sizing system
• More reliable part connections

There is some other minor stuff, such as internal methods to find what parts are connected to what and other stuff like that I intend to use later during the rocket launch phase. There are a lot more coming, mainly the whole launch phase and a few more builder menu upgrades. If you guys have any improvement ideas please lmk.

Devlog 2

Hello people, after having already restarted once, I’ve finally made some progress. Right now I’m going back and forth a lot as I’m learning new things while coding.

One example of this is the way I was storing position data. Initially, I was just storing x and y variables, but I later found out that Pygame has a vector class built in (pygame.Vector2()) that makes storing values such as position, velocity, and acceleration much easier. But of course, I only found this out after I had spent an hour using the first method. Even still, it wasn’t too much of a pain to overhaul, as the code didn’t change much structurally.

Aside from that, I’ve spent much of the 4 hours I coded today working on the page where the user builds their rocket. So far, I was able to make an inventory, stats, and drag n drop feature. I also became overly obsessed with the idea of the parts snapping together and spent 2 hours repeatedly failing to implement that before eventually getting there.

My next steps are finishing up the physics system that I started today and making the drag n drop system smarter so that you can’t just connect random parts together.

PS. Graphics overhaul is coming I just hate that part, so I’m leaving it to the end. dw, it’s not gonna be ugly forever.

Devlog 1

Okay, I’m starting this new project, taking with me a lot of what I’ve learned from my previous project, the Gravity Simulator. That served as a way for me to take my knowledge of CS and physics and learn how to cleanly integrate the two. This new project is based heavily on the game (Spaceflight Simulator)[https://store.steampowered.com/app/1718870/Spaceflight_Simulator/] and is my take on it, with hopefully some of my own features if I’m able to get to that point. So far, I’ve already had to restart once after 2.5 hours of work. My current structuring of the project just wasn’t working out well, but I’ll be able to use a lot of what I’ve already coded.

This is my first hackclub project, so I wanted to challenge myself a little bit by combining aspects from two of my high school classes, physics, and compsci. I made this whole thing in 2 sessions, so it’s a little rough around the edges.

Finally after a marathon session of work, I’m all done. It took me a while to figure out what layout I wanted to go with, as there were 3 key things I wanted to balance, functionality, “coolness”, and dynamism. I wanted something that had a lot of inputs so I decided to go with a 3x3 matrix of buttons and a rotary encoder with pushdown enabled. By having a large number of inputs I have lots of freedom and don’t feel as constrained about what I chose to use the inputs for. I also decided to have LEDs under each of the keys, this served two purposes. Firstly, the LEDs add to the “coolness” factor of the macropad, this is also by I tried to create a sleek and minimalist design. Secondly, they can be independently controlled and will light up in different colors depending on what the key does. This adds to the dynamism as I plan on making the macro pad aware of what’s on my screen and able to adapt its actions based on that. The LEDs will also change color to adapt to the new set of actions. I’m also thinking of making the colors semantic, so certain types of actions across apps can be the same color, but this idea still needs some thought. In terms of hardware, I am now all done, and I just need to submit my project for funding. As of now I’m going to use the QMK firmware once I’m done building and then start building either a custom firmware or a software layer above QMK to add in the adaptive feature.

After looking at the parts list again, I’ve just been going back and forth about what design I’m going to choose. At first I thought of just piling together everything and making the most kitted out macropad possible but quickly ran into the problem of not having enough GPIO slots. I know I want a lot of functionality out of this, but I also want it to look cool. I’ve also been thinking about having LEDs underneath the keys that change color to dynamically convey what they do, but no I’m stuck between keeping the OLED for coolness or 3 more keys for functionality.

So I’ve decided to make a bunch of changed to my design. Through the tutorial page, I know have a fair grasp of KiCad which was my biggest issue up to this point. More importantly I now have a full list of parts that I can request. I’m still working out exactly how big I want to make my hackpad. I’m thinking 9 keys and 2 rotary encoders for now, this means I can have enough inputs for any situation. This leads to my next point, I previously discussed the idea of making my hackpad adapt to what I’m currently doing. After some thinking and research I plan on doing this by having it talk via serial with my laptop and having some kind of interpretation layer (likely in python) to check what I’m currently doing and then carry out the intended action. I’ve also seen some others add backlighting to their hackpads and it looks like a good idea so I’ll probably try and implement that as well.

This is something that looked really cool to me, so I started building. In practice, however, it’s a little more difficult than anticipated. Of course, I’m still gonna keep trying. Right now, I’ve pretty much followed the tutorial perfectly to get a hang of things like KiCad and the whole PCB process, but now i want to move forward and experiment a little bit by customizing my macro pad. I’m gonna add some more buttons and a rotary encoder for sure, but I also intent on looking at others projects and actual products for inspiration. The end goal is to have a variety of inputs, and a smart software layer that can change the actions of each input depending on what app or program I’m using.

This is my first hackclub project, so I wanted to challenge myself a little bit by combining aspects from two of my high school classes, physics, and compsci. I made this whole thing in 2 sessions, so it’s a little rough around the edges.