Debugging and Fixing Is Killing Me and the Mainboard Exploded :(

I have spent SO many hours trying to get this to work. It’s so annoying. This isn’t near how many hours I spent, I’ve been too frustrated to log it.

The case is incredibly annoying. Getting the initial case works fine. Doing all of this stuff makes it complicated and break and jam up.

The RS485 busses just randomly stop working.

The servo output is wiggly and not stable.

A PCB header snapped and I didn’t have replacements so I had to bodge solder it back on.

The mainboard voltage regulator literally exploded. It was a cheap part but yeah that literally just broke stuff.

Fixes to everything. CAD. Firmware. bruh

MG996Rs Finally Working

The servos finally work. I don’t even think this amount of hours logged is equal to how long this took, because I just got tired of it.

I think I printed like 20 new revisions of the case and servo mount. It was just so so annoying. While the general case worked, getting a reliable magnet output shaft was impossible. From tolerances, to my own errors to binding to hot glue getting everywhere, or superglue binding random gears, or my getting my fingers stuck to the actual case from superglue (was not fun and hurt)

The case finally works.

And the prototype code somewhat works too. It basically rotates until the sensor hits zero, it resets the “ticks”. A tick is a raw output from the AS5600. Because this magnet shaft spins faster than the output shaft, like 10x faster, the MCU needs to poll the sensor super quickly, which also needed some optimizations to clear the blocking bus communication wait that would let the magnet skip multiple full turns. The sensor doesn’t internally count turns so we just need to count manually and detect when it jumps from 4096-0 or the other way around.
It then spins around until the sensor is hit AGAIN to calculate tick to degrees, assuming the sensor was zeroed before, and then the current ticks would equal 360 degrees.

Another problem was the servo needs a PWM signal to move. The threshold from stop to go is pretty garbage on these cheap servos, leading it to spin quite fast already when at the lowest PWM value. Instead when far from the value it increases the PWM signal, closer it brings to minimum and starts linearly flickering the PWM signal from 0 to the speed, with the closer it is the more ratio of time stopped to inch it closer to the target.

It actually surprisingly works. It’s very fragile though, any skipped reads, from potentially slow bus transfers would completely throw it off, so all the code running locally on the weak 8 bit MCU needs to be extremely lightweight.

Yeah this was super super painful. I’ve been sitting here redoing superglue and code for hours.

Servo Code

I did some slight refining to the servo case again, making the tolerances tighter to keep the gears from wobbling. It’s still sort of loose, so I need to just keep trying over and over again.

I’m also still writing the servo code. It’s already much more organized than before. I’m also learning Vim keybinds and stuff to try and code faster.

The RS485 bus communication works now, and it’s just sending dummy telemetry data back right now. It can also control the servo fine. I’ve just been doing like the lower level architecting I guess, or not really I’m not sure. Before everything was crammed into a single file and now there’s actually header files and multiple source files and it’s actually somewhat readable. I had an issue with LED control for a second but that’s fixed now :)

V2 Servo Case Working; Servo Code Revamp WIP

After around 10 more revisions, the new servo case is fully working with the magnetic extender. The V2 is significantly better designed and higher efficiency than the last, more guess and check result.

I’ve also started to rewrite the servo code. Right now, its really messy and just kind of snowballed over time as I’ve slapped on patches and features to a fundamentally weak base. I’m in the progress of writing that now, hopefully it will be done soon. It will also include the new auto calibration and encoder usage and PID (and potentially advanced auto tuned curve to combat motor acceleration overshoot and backlash)

Working on IK System & Resoldered Joints Again

Bruh so my robot arm after finally being assembled by the way exceeded it’s limits and tore its wires out. I had to take apart the mainboard assembly again, which just is SO TEDIOUS. I just dumped solder and hot glue again and fixed a short caused from another wire being sheared off.

Also I’m working on the IK system, but it’s not really going well right now. I need to add offsets and config to each of the motors to get them to work correctly. The motors hooked up right now started crashing into my table sadly. Hopefully it will work soon.

I also continued working on the servo case. I still haven’t added the code to calibrate and get closed loop control on the MG996R servos. The DS5180 encoders should be easier though.

Reprinted Arm Segments; Added Segment Cover; Servo Mount Working; Working on Web UI

I reprinted the arm segments, hopefully for one of the last times, I’ve went through so much filament already. It now allows the mainboard to be neatly packed inside, hiding most of it while still allowing wires to come out. Due to the design of the mainboard, the wires do have to stick out the front like that sadly.

To avoid crushing wires, the servo mount has been expanded to allow more clearance for wires and general electronics.

The servo mount works now with a new design. I remeasured and adjusted the sketches and added proper hole sizes and a little chamfer to allow the insert to slot in before using a soldering iron to melt it in to help align much better than before.

The web UI now shows a representation of the arm. It’s not tuned yet, so the angles are wrong but I’ll fix it soon. I had to move everything from Fusion to Onshape to create the assemblies, and then use a Python library to convert the Onshape assembly into a URDF file that can be rendered with the correct joints inside ThreeJS.

Next, I’ll be adding IK and general arm control.

Heatset Inserts Working; Fixing Faulty Motor Power Connections; Internal Fan Power Connectors

I verified that the servo cover works, and it’s much much better than the last version. The tolerances are much better this time, leading to less stress on the gears. The same amount of turning uses around 100mA compared to 300mA before, almost reaching it’s limit without any load.

Some motor power connectors disconnected, so I found it with a multimeter and added hot glue to some connectors to secure them.

I soldered the fan power things inside the PCB, but realized that the JST connectors I’m using are different from the fans. I might have to make a sort of adapter or something by crimping more wires.

And the heatset inserts finally work after some tweaking, before the inserts would get misaligned when put in, now with a aligning lip thing it can be slotted in and melted in more accurately.

New Mainboard Cover, Wiring, Bearing Revamp, Heatset Inserts, Servo Cover

I added space for the mainboard segment, now it has clearance to actually fit, I redid the cover for this segment, and now it can allow the wires to come out

The servo mount now has heatset inserts, because the previous screw in print kept slipping out, but this time the screws just would not go into the inserts through the mount for some reason? The screws went in normally, but with the tolerances, when multiple screws go in they just fight and push against the edge of the insert instead of going in.

The MG996R servo housing now has been redesigned, based off of picture references and calipers to attempt to be more accurate than the last one to try and reduce the amount of bad tolerances affecting the gears and making them misaligned, reducing torque output.

And just general wiring and CAD work.

Assembled Basic Arm Parts and Packaged Main Board Assembly; Reprogrammed servo MCUs & worked on web UI

I redid some soldering on the mainboard PCB, secured connections, and secured everything with tape for now. I’ll likely have to reprint the first arm segment to fit everything in flush because as you can see there are wires and things bulging out of the segment itself right now.

I also redesigned the CAD to include heat set inserts.

I did programming and a bunch of bug testing and fixing too. An hour of time was lost because Lapse errored out :((((( very sad about that :(

I also had an issue with data corruption on the RS485 bus but that is fixed now, and it works like it should.

Mainboard Stack Redo & Firmware Updates and Test Web UI

I had to take the electronics out, and redo some of the wiring. The screw terminals are pretty cheap and suck, which makes it incredibly annoying to use as it’s impossible to fit these thicker AWG wires in and they sometimes slide out of the terminals. When I’m done I’m probably going to hot glue the wires. The incredibly fragile flexible extension jumpers for data transfer between the stack is also super fragile, and especially doesn’t grip. Sometimes the data wires just slip out.

I took apart the arm, as during testing the motor stripped some screws. I’ve ordered some heat set inserts to prevent that from happening again, which will require me to reprint all the arm segments again.

I also added a simple web UI for moving the joints. There is an empty ThreeJS sidebar and the right has some graphs (real data) from the mainboard sensors. The smaller MG996R servos haven’t been mounted yet due to a power delivery issue from the mainboard but hopefully that will be fixed soon.

Scope Leaking Bug Fixed, Mouse Input, Scripting Improvements, ECS & Events Scripting Improvements and Fixes, Cameras

There was an issue where I used a single variable to hold the last used scope before and forgot to change it to support multiple scripts. That is fixed now and scopes aren’t mixed weirdly anymore.

There is now mouse functions and events

Events can be called like part.physics:on("touched") instead of part:on("Physics.touched") for clarity

Cameras are added, game wide function to change active camera, and camera system that updates the camera things bidirectionally supporting multiple camera types.

Script Scheduling Engine Revamp

The entire scripting engine has been redone. It was a lot of cascading changes again, with now each “Scope” having it’s own scheduler. A “scope” is a single logic component that gets attached to entities.

How it works now

The scheduler handles the Lua engine stuff. It wraps the main script around into a coroutine automatically now, and extracts the coroutine into a thread. It then creates a scheduler job object, pending into the queue. The scheduler then gets stepped, and initializes the jobs into the main queue and steps them. By stepping them, it resumes the coroutine until the script either ends or manually pauses the coroutine itself (usually done with a predefined “wait” function). I think this is very similar to how Roblox handles it’s script scheduler, although Roblox’s is of course much more complicated. Handling the events and callbacks was much more difficult though. Each of those ALSO need it’s own thread to run to access coroutine related functions and to access data (otherwise very weird errors will happen, like calling code over a boundary or something). This all gets added as a scheduler job, and that allows us to record telemetry data. Eventually, threads can be assigned a “budget”, where they can be stalled if they consume more than the allotted time or even do things like infinite loop detection, etc. There was just generally tedious work that was annoying.

Added CSG Operations

I added CSG operations, using the Manifold library. It makes it a bit simpler, making watertight meshes and giving back the geometry for me to make a custom mesh in ThreeJS. The reason it took so long was because I had to add cascading changes to a lot of the data structures to support this custom geometry. I also added a little loading thing at the bottom right for CSG operations. As of right now Union and Subtract are supported. Materials are not preserved as of right now, due to the simplistic way I’m handling materials but when I finish building out the materials system I basically just need to get the triangle references out of Manifold and relink them to the correct materials.

Engine Events System & Starting Significant Scheduler Engine Revamp

So I made the events system. It works by a class on the JavaScript (engine) layer, and is attached to all entities. There are a couple of functions:

• on: fires on event
• once: fires on event only once
• off: clears event callback
• clear: clears all callbacks

Other entities are allowed to access another entitys events, being able to listen or even emit. A game architecture could work like having “manager” entities at the top level of the game which hold different events. For example, an “InventoryManager” entity could have an event for when an item is picked up, it itself can listen to it, as well as any other things that may find it useful.

I’ve also cleaned up the code, and now there is a “game” reference. Eventually, it will have access to more things but as of right now you can access an “inputManager” which holds functions and events for user inputs. It works by attaching a metatable to it and exposing global hidden functions to call to my JavaScript engine code.

But a huge problem showed up, the way I was running scripts. Before I thought just a simple coroutine running with a timeout for delays was just fine, but I was super wrong. If a callback from an event is fired and the function wants to do something, like call an external function or wait, it completely breaks. Why? I didn’t know and it took me a lot of time to find out. It’s because the callbacks aren’t a coroutine too. This is when I realized why something like Roblox has a full blown scheduler.

So I’ve been planning and starting on the scheduler engine. It has to handle a lot of stuff, including managing when scripts run, including WHEN they want to run (next frame, in 3 seconds, etc) and track if they are causing issues by keeping track of their budget. Everything will need to be in a coroutine coordinated by the scheduler. Including callbacks from events too. It’s going to be pretty complicated I think, requiring a rewrite of the entire scripting system.

I also just encountered a lot of bugs. And I fixed the errors from Wasmoon including the entire JS stacktrace for no reason too.

Scripting System Affecting the Game

Scripts now can change parts. There are getEntityById and getEntityByName functions now, and a bunch of metatables and stuff to get it working. Now you can query for an entity, and then modify it’s component data with metatables. For example to access or set the position of a part, you can do part.transform.position. The transform finds the transform component and position finds the data entry of position inside the component. This is all done on runtime, with component queries happening dynamically so no manual programming for new components is required. This may affect performance a little bit though. There is a custom Vector3 object now too.

Error messages are also now a little less vague but still pretty confusing. I don’t know how to solve that.

Logic & Scripting Prototype Working

this was so difficult

basically a TON of things needed to be changed for this to work. i had to rework the entire scripting system. i had to also think about how the system is going to work

the system i landed on, basically is you can create nodes in the state machine editor, and attach scripts on those states. instead of scripts, im calling the whole package of state machine + scripts a “Logic”. i havent reflected the name everywhere else yet though, and that is probably going to take a really long time as its a major architectural shift that i didn’t plan for beforehand.

i made custom nodes in the editor as you can see, a start, end and the script node. there is now a nice dropdown to select the script (a searchbar will be added later) and you can create new scripts. i fixed the code editor to actually load/save code properly.

i had to redo how it saved data, so i could communicate the scripts, nodes, connections, etc all to the ScriptingSystem, which starts off at the “Start” node and steps the state once, going into the first node. This part of the code is an absolute MESS.

i had a ton of bugs to fix, including state and Svelte firing state over and over again for some reason, Lua issues, dealing with coroutines, dealing with external functions which would change the state and exit the code, etc

To add the script, there is now a “Add component” button which you can select the script and select the logic.

The state machine handles direct to end, looping nodes, multiple handles, infinite loops going into other nodes, etc.

At the end of the video, you can see that i created two states and the second state had two outputs, and the path is a 50/50 random decided by the Lua code to loop back into the first state or exit.

Overall, this was really tiring and I’m glad it’s done. The amount of time thinking and debugging isn’t included in the time tracked so yeah :(

Scripting System

I added Svelte Flow and the Monaco editor
Basically, I think that the system will work mainly off of state machines. Each state will have an attached script. The scripts can decide when to change states.

For example, the scripting for a bee in a game could have states for wandering, eating, etc and the scripts handle only it’s own state which could make the code a little cleaner.

I also tried making the script editor to look really good. I spent a bunch of time trying to add LSPs and intellisense/autocomplete and syntax and formatting but honestly I give up for now.

Fixed Constraints

Getting constraints working was super annoying. Basically, there is a problem where the engine is built around models, and you can spawn in multiple models. When models are spawned in, the parts inside are cloned including their IDs to not lose reference, but this comes with the huge issue as in the backend, the engine actually flattens this structure for more efficient processing of entities, meaning that there will be multiple entities sharing IDs, which is really bad.

But creating new IDs is also a huge problem because when we reference it, the ID is not final and changes all the time on load. So instead it does <model_id>:<entity_id>, for targeting.

The constraint creator lets you select two points (snapping will be added in the future) and it creates a constraint. This is later processed by the PhysicsSystem detecting the ConstraintComponent. Later there will be debug viewer for constraints.

Anyway it was just a lot of annoying work.

Opening Tabs Working

There is now a flow for opening and creating tabs, now new tabs can be created and new models in the same way. Opening a tab that is already open just switches to it.

Runtime working

This took so long

There was just so many things that just weren’t working well together. Especially the data loading code. I initially just made the code use and modify the gameData directly, meaning that if I stop and play again the game would not reset and would probably completely break. But cloning is so difficult. Since the gameData is pretty complicated with nested classes and data, simply JSON.stringify and parse, and even structuredClone didn’t work. I had to use a function to manually copy a lot of things which was really annoying.

Another thing that was weird was that parts would only have physics if it was dictated by the parent model, which wasn’t what I wanted. Now there is a function to flatten models, since I want them to kind of just be fancy folders at the end of the day anyway.

There was just generally a lot of rework to get everything working, with systems and components working now with a setup phase, and a general frame tick function for systems to process. I also had to add dirty flags to all ComponentDataEntries so other components actually notice changes by OTHER components which was so annoying :((