Devlog - Tumblr Posts
Sometimes you just accept a flaw and move along
So I am building a robot from scratch. It just needs to be a platform for my other projects. It takes Twist commands (Basically, orders how fast to move in what directions) and return odometry (Basically, where the robot thinks it is), both over wifi via the HTTP protocol. Because the odometry math is a lot easier with stepper motors(motors that moves in tiny discreet steps. Usually several hundreds for a single rotation), these are what I am using: I am using 2 TMC2100 boards to drive them. These have 2 pins that you can set to Ground, supply or let them float, and they are used to configure what amount of micro-stepping you want to do (If a stepper motor have 200 steps for a rotation, micro stepping 4 means it takes 4 smaller steps to do one of those 200 "real" steps, and so takes 800 steps for a full rotation) All great... eeeeexept... for some reason the configuration pins just does... nothing, no matter what I set them to. The boards are just stuck at 16 micro-steps, as if both pins where set to supply. This limits the robots speed to 0.3 meters per second... which is... fine. The amount of work and money it would take to fix this(Likely I would have to buy new boards) is not worth a speed boost that is not needed for the first 2-3 projects I want to test on top of it... so I am just leaving it. "Perfect is the enemy of good" and all that... but it still feels unsatisfying... blaaa
The Universal Serial Bus is often not universal...
So there is this problem you often run into when doing development. You come up with a solution. You research the solution, and find only tiny amounts of people talking about it, and/or they seem to say many different things and disagree. Most of the time, that is for 2 reasons 1: it is a very novel solution, so no one have tried it much, and everyone who have, has made very custom versions of it. 2: There are variables that makes it impossible to do it in one single way. I needed a rechargeable battery system to power my robot. These can get... VERY complicated, and pre-made solutions can quickly be expensive and you might end up with batteries catching fire, or destroying the batteries so they can never be used again. You need protections on them, but which kind depends on a bunch of things. I know electronics, but I am mainly a software guy, and I know when I do not know enough about electronics to do it myself. This being such a case. So, I came up with the idea to use powerbanks. One for each steppermotor, and one for the microcontroller(so the noise fromt he motors could not cause issues).If I use ones that can output enough amperage, they should just work and they are cheap. They are meant to be used by normal costumers, so have all the protection needed, and are quite idiot-proof(Which is a very handy thing when you are an idiot, like me) so should be easy to use. But I could not find much info about doing this... and I did not realize I was looking at reason 2. Basically, BECAUSE powerbanks are idiotproof, they do not want to discharge themselves unless there is a real device at the end of the USB cable. So if they cannot detect one, they turn off after about a second. How do they determine if there is a real device? Depends on the power bank.... No really, there is NO standard way to do it, as far as I can tell. And it does not depend on the power bank MODEL. I have 2 identical power banks, bought at the same time, and they do NOT behave the same. Which means that when I connected the powerbanks to supply my system, they (SOMETIMES) did not supply anything. Some check how much current is being drawn, which can be faked with a resistor wasting some power. 500mA was being quoted a lot, but that is more of a "That is probably enough to get it going". Others check for impedance(Basically, also resistance, but from frequency dependent sources). Those can be "faked" by having a coil or a device that acts like one to the faking resistor. I wanted a tiny 5 volt fan to cool the stepper motor drivers anyway, so I had one power bank also power that. That ensured that it actually stayed on (But if I used the other, (identical!) power bank it just turned off anyway). The other one could be connected up directly. If I used the powerbanks lower amperage socket. If I used the high amperage one, it just turned off. So now it works... I have 2 powerbanks for the motors, each with painters tape marking which powerbank and socket to use for what. Took me a week longer than I had hoped to figure all this out and do all the experiments. Sometimes, things that should be simple are just headaches.
It works!*
So I (FINALLY) put the final touches on the software for my robot PROTO! (Listen, I am a software person, not a coming-up-with-names person)
Basically, it is a ESP32 running him. He takes HTTP messages. Either GET odometry, or PUT twist. Both just being a string containing comma separated numbers
Odometry is the robots best guess based on internal sensors where it is (Since PROTO uses stepper motors, which rotates in tiny tiny steps... it is basically counting the steps each motor takes)
Twist is speed, both in x,y and z directions, and speed in angular directions (pitch, roll and yaw). This is used to tell the robot how to move
Now, since PROTO is a robot on two wheels, with a third free-running ball ahead of him, he cannot slide to the side, or go straight up in the air. You can TRY telling him to do that, but he will not understand what you mean. Same with angular movement. PROTO can turn left or right, but he have no clue what you mean if you tell him to bend forward, or roll over.
The software is layered (Which I use a BDD diagram to plan. I love diagrams!)
Basically PROTO gets a twist command and hands that over to the Differential_Movement_Model layer.
The Differential_Movement_Model layer translate that to linear momentum (how much to move forward and backwards) and angular momentum (how much to turn left or right). combines them, and orders each wheel to move so and so fast via the Stepper_Motors layer.
The Stepper_Motors turns the wanted speed, into how many steps each stepper motor will have to do per second, and makes sure that the wanted speed can be achieved by the motors. It also makes sure that the wheels turn the right way, no matter how they are mounted (In PROTO's case, if both wheels turn clockwise, the right wheel is going forward, and the left backwards.). It then sends this steps per second request down to the Peripheral_Hub layer.
The Peripheral_Hub layer is just a hub... as the name implies, it calls the needed driver functions to turn off/on pins, have timers count steps and run a PWM (Pulse-width modulation. It sends pulses of a particular size at a specific frequency) signal to the driver boards.
Layering it, also means it is a lot easer to test a layer. Basically, if I want to test, I change 1 variable in the build files and a mock layer is build underneath whatever layer I want to test.
So if I want to test the Stepper_Motors layer, I have a mock Peripheral_Hub layer, so if there are errors in the Peripheral_Hub layer, these do not show up when I am testing the stepper motor layer.
The HTTP server part is basically a standard ESP32 example server, where I have removed all the HTTP call handlers, and made my own 2 instead. Done done.
So since the software works... of course I am immediately having hardware problems. The stepper motors are not NEARLY as strong as they need to be... have to figure something out... maybe they are not getting the power they need... or I need smaller wheels... or I will have to buy a gearbox to make them slower but stronger... in which case I should proberbly also fix the freaking cannot-change-the-micro-stepping problem with the driver boards, since otherwise PROTO will go from a max speed of 0.3 meters per second, to most likely 0.06 meters per second which... is... a bit slow...
But software works! And PROTO can happily move his wheels and pretend he is driving somewhere when on his maintenance stand (Yes. it LOOKS like 2 empty cardboard boxes, but I am telling you it is a maintenance stand... since it sounds a lot better :p )
I have gone over everything really quickly in this post... if someone wants me to cover a part of PROTO, just comment which one, and I will most likely do it (I have lost all sense of which parts of this project is interesting to people who are not doing the project)
I have an important announcement to make.
About one year ago, I began coding game mechanics for a JRPG game that I wanted to create called KANDRIA. Until recently, the basic game mechanics have mostly been implemented. I won’t stop until my project is perfect and complete, and I intend to get outside help for Kandria down the line.
Kandria is set in the 26th century, in a rich, vast universe with alien life, and threats to face. If a JRPG with those concepts sound interesting to you, consider giving my devlog page a follow.
This video game is my baby and it would mean everything to me if it could take off one day. I just thought I’d let you know. I don’t have any presentable content at the moment or a website. The game is only in it’s pre-alpha stages. I hope to keep people caught up on the devlog blog.
Kandria Devlog: kandriagame.tumblr.com / @kandriagame
Also, if you have any questions involving Kandria I’d be happy to answer or just talk about them in my direct messages.
Thanks, guys! - Runn
A quick history of "Starship Battle"
Starship Battle (as it is currently called) is a passion project of mine that i've been working on since the start of 2023. yes i do more than just draw silly little pictures.
"Starship Battle is a (F2P) fast pace, 2 player, local multiplayer game (best played with controller), where you duke it out in a small arena with Starships. Each ship has unique abilities and controls differently."
you can get it here: https://videomp4.itch.io/starship-battle
--𝗣𝗿𝗼𝘁𝗼𝘁𝘆𝗽𝗲--
It initially started simple, with nothing more than 2 spaceships that could shoot, move and die - that's about it
After a bit of brainstorming, my dad and i came up with an idea to incorporate healthpacks so you can stay in the fight for longer
--𝗣𝗿𝗲-𝗔𝗹𝗽𝗵𝗮--
Next update i added asteroids that damage whoever flies into them and also included a temporary background
After that i added a main menu, end screen and some foreshadowing
--𝗔𝗹𝗽𝗵𝗮--
Next up was the introduction of ship types/classes - standart (just a regular ship, later fixed to "standard") - interceptor (speedy with less health, later designated "scout") - heavy (slow & bulky)
--𝗕𝗲𝘁𝗮--
One of the most major of updates was this one, which added a very improved title screen with anmiations and an end screen with a scoreboard, things that also got added: - screen transitions (fade to white/black while loading the next screen) - sound effects (button clicks, shots, explosions, etc) - soundtrack (generously provided to me by a close friend) - new backgrounds - options - new textures for the health pick-up - a shield pick-up - rudimentary AI
after that big update, i added unique abilities for every ship type that can be activated every 20 seconds - standard got a "powershot" that makes your next hit deal 5 dmg - scout got an "EMP", which when in range, temporarly removes the enemy's ability to turn - heavy got a mine that deals 7 damage if you fly too close (it can also penetrate shields)
to distinguish the ships even more they all got different shooting patterns - standard remained the same - scout now shoots two bullets in a V shape - heavy now shoots two bullets one straight forward and a slightly inaccurate one backwars This is where the currently playable version on itch lies.
--𝗕𝗲𝘁𝗮 𝟮: 𝘁𝗵𝗲 𝘀𝗲𝗰𝗼𝗻𝗱 𝗼𝗻𝗲--
I decided i want this game to be as polished as it can be so i - added a bootslpash - hide the mouse during gameplay - overhauled most textures to improve visibility/readability - added a moving background - added lighting (aka basically just bloom lmao) - added trails to everything that moves [players and bullets] - added a singleplayer mode (as of writing still in development)
--𝗽𝗹𝗮𝗻𝘀 𝗳𝗼𝗿 𝘁𝗵𝗲 𝗳𝘂𝘁𝘂𝗿𝗲--
- fully finish the singleplayer mode with customisable challanges and a timer - FIND A NEW NAME FOR THE PROJECT!!!!, ↳ i am very bad at coming up with names for stuff and "Starship Battle", not only sounds incredibly generic, it's also already in use by a different game - maybe, some day, add an online multiplayer
Starship Battle - Singleplayer 01
the damage stat didn't reset at the end of a round for some reason, buh yeh, here's a lil preview of the current singleplayer.
Starship Battle - Singleplayer 02
i added an endless mode to the singleplayer. there are still some kinks to work out (specifically again trouble with the damage stat not being tracked right)
Starship Battle - Singleplayer 03
added a timer, wave counter alongside some bugfixes to the singleplayer and stat-tracking in general
Starship Battle Singleplayer release
my game can now be officially played by the sufficiently lonely (like me!)
Working on a crossbow
Check out the first of 8 mini playsets I’m illustrating for my game!
-I made the hard decision to finally leave RPG Maker for Game Maker Studio.
-Oh yeah! The game’s called “Super Psyche Quest” now. 🌈
Some encouraging progress this week making illustrated character sprites! I have yet to see them animated, but I’m hoping the lines will have a sketchy sort of “boil” to them. ✍️
Oh yeah! Happy New Year. 🎊
SO happy after switching to GameMaker. Check out some progress!
The magnet room (and PV Plus)/a Theater of the Mind for my game “Super Psyche Quest.”
For me ADHD feels like my brain’s a TV that’s constantly changing channels. 📺 Combining mismatched fonts speaks to the constant influx of stimuli I feel and the restless nature of my thoughts. 🧠
Finished the character cardbacks design and re-inked Sprout’s card. Can’t wait to show y’all the animation I’ve been working on. 👑
Whew. I learned how to make an animation in clipstudio! ✍️
A video of the first half of a transition animation, and what pixel icons the illustrations will morph into for the second half.
finished a new drawing for my game! 💪 ✍️