It Works!*

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)

Oh dear god!

I am SO sorry, that must suck so much to lose a drone to!

But that is also the FUNNIEST thing I have heard in a while.

Just because I build robots and it SO a thing I have had happen, but at least mine can only drive away in 2 dimensions!

Note to self:

When building a drone from scratch, make sure you test your code before taking it outside.

RIP Goldie, The drone. We will miss you dearly. Lost because I forgot to tell it when to turn off the launch code and hover if no user input so it just accelerated...upwards 🙃

I really love it here! It is a community that is far more open and comfortable with the truth "Listen, no one knows everything. Not even about their specialization. There are always more tricks, tools, techniques and details to learn." So everyone focuses on helping each other instead of thinking everyone else knows everything, and so spend time pretending that we do too. It is much much nicer than any other code community I have run into (With it being about par for maker spaces. Which are usually awesome communities too)

tech twitter : if u aren't a billionaire by 30 u are not gonna make it, if u aren't working for FAANG by 20 u aren't a real programmer, if u don't know everything that goes on in the computer don't even follow me

tech tumblr : oh u don't understand the "hello world" code? DM me I will personally guide u. yes here are some resources. im not a genius bcs I knew everything when I was 6...... everyone starts somewhere don't worry. 🥰

in conclusion I was shocked when I came here

Cannot code when anxious

Cannot think logical when anxious. Code requires thinking logically So Cannot code when anxious. BUT Brain cannot multi-task some disorders So Cannot be anxious if I focus on massive sensory overload. So Moose is blasting the same song on max volume into his skull via headset so progress can be made Stupid DIY brain I got handed out by mother nature

That is GREAT!

As much as I love developing new things there is something uniquely satisfying about refactoring code or hardware setups.

I tend to make diagrams of the codes architecture after it works, to figure out how to make it work in a maintainable way. It feels like a lovely brainteaser

refactoring

I lied when I said I was going to work next on loading a 3-D model. Sorry, old habit! Actually, I went straight into refactoring. Let me explain...

The English Wikipedia defines refactoring as "the process of restructuring existing computer code . . . without changing its external behavior", which is fairly accurate, though lacking in motivation.

My back-of-mind definition would be "changes to code whose primary purpose is not to add features or solve issues, but to make the codebase easier to maintain".

Back when I worked for corporations, I got in the habit of never mentioning refactoring around anyone who wasn't a software developer. If my boss (or my boss's boss) knew I was making changes (and spending work hours) on something other than approved features or known issues, awkward questions would arise. (Like, do we have a billing code for that?)

Anyone who's worked intimately with a large software project knows that if changes are made only for features and issues, the project will accumulate "technical debt" that makes it difficult to maintain: hard to explain/learn/understand/remember how it works and hard to make changes without introducing bugs.

Both of today's refactorings focussed on the BaseApplication class, which became unwieldy weeks ago. Last night the source file for the class reached 1901 lines of Java code (not counting blanks, comments, and javadoc). I don't place a hard limit on lines of code in a class, but a file containing 1901 LoCs positively screams technical debt. It's especially painful these days, since I'm working on a laptop with a tiny screen and using a track pad instead of a mouse. (I spend lots of time scrolling back and forth, hunting for the lines I need to change.) Cramming as much as possible into a single file makes some sense for a tutorial, but I see the V-Sport project as something I'll be maintaining for many years.

First I split off all the code that deals with physical devices and put that in a new PhysicalDevice class. The change greatly clarified which properties of the physical device matter and how that information is accessed.

Then I split off all the code that deals with texture data into a new Texture class. The new class bundles up 3 related Vulkan resources and provides a clear lifecycle of create/use/destroy. I expect it to minimize duplication of code when the project transitions (sometime in the near future) from a single texture to multiple textures.

I'm subjectively pleased with how smoothly today's refactoring went. One measure of its success is that BaseApplication shrank from 1901 to 1650 lines of code. Still plenty of room for improvement, though!

I am low level engineer. As such I am NEVER let ANYWHERE near a costumer or ANY decision that involves "How do you feel people should use computers?". I am a low level engineer. When you ask us such questions, answers like "Working in the shell is most of the time nicer than a GUI" or "No I DO think forcing the consumer to insert the settings for their automatic curtains in a hex code they generate based on several tables in the manual is a reasonable way for this system to work". So AS a low level engineer, I can only say... yep, put it up to 12. I once used one to melt tin and used it to solder with, and I am sure many users will face simillar needs of their toasters since that is completly reasonable behavior.