/random/ - random

you do know the second one is prettier and has a magician tophat that eats my soul

Any word from Ron on his Project Odin or whatever he termed it? He seemed intent on bringing back 8chan, not this pale copy.

>>158368

nobody attempts to possess content which is illegal.....only an idiot would attempt to collect content which is against the law.....

only an idiot gets caught

>>158408

only an idiot attempts to access illegal content.....

One can only hope

Coomer

I got Monke too. Not a very good test. Everyone just gets Monke.

>>158374

i mean it makes sense that most people in this site would get monke

>>158399

just a stupid try, but we have billions of stupid yellow poeple, it'll work.

>>158319

It looks like someone has inserted a nail or a screw into the tip of his penis.

FUCK, mods delete this shit Now!!

>>158371

There is a niche sexual fetish where men like to do this.

They often end up with urinary tract infections or having to go to the emergency room to remove the object.

It is called "urethral sounding", and there is a wikipedia page about it! https://en.wikipedia.org/wiki/Urethral_sounding

>>158381

that could be the case. also no one gets graphenos unless they're a criminal

>>158382

full disk encryption is 100% suspicious.....nobody uses it to hide loli and shota hentai since that sort of content does not result in a search warrant from the police. Nobody uses full disk encryption for protecting their data from theft......a log-in password is more than sufficient for protecting your data from theft.....literally nobody is capable of by-passing a log in password in case if you lose your computer......only the police can by-pass a log in password.....using a log-in password is more than sufficient for protecting your data

>>158301

does that mean you're a pedo if you watch anime?

>>158309

i think anime girls have boobs that are too big.....i prefer girls with flat chests.....

If you do not want jail = no anime

They want us in jail for "not working hard enough" no matter what we do. It is literally ALL about the money. Fuck capitalism. 🤮

Never use any M$ products.

>>158362

what makes this better than tortaxi?

No intelligent person accesses the dark web......

No. He isn't great looking and might even be a JEW.

>>158337

Never!

how could you ask such an absurd question?

>>158281

That's what I wanted to hear!

>>157633

Bait!

Please remember if they check someone's devices at an airport or border crossing (let's say across the USA and Canada), they already suspect someone has real cp on their devices. They don't ever do "random" checks. There is no way to "hide" cp. Every device check is because someone is suspected of having real cp.....nobody checks for your anime files....

>>158322

Sucks. You can only make friends if you're a liberal otherwise friendship is off the table.

Quit romance unless you want reproduction. The point of romance is reproduction.

Ok so after further consideration I decided that the idea of adding significant modifications to a 6k lines of code 20 file assembly language behemoth firmware developed by a big company was just not prudent for me. I need to be able to go in there and add tweaks and improvements for years to come and maintain my code there. The firmware of the ESC is absolutely essential to get just right as it has a massive impact on the performance of the final humanoid robot. The speed and fluidity of movement, the amount of strength, the amount of acceleration, it is all impacted by this. This is just essential. And assembly language is not in my wheelhouse. I am very inexperienced with it. So I officially decided to simply scrap their entire firmware and start from scratch coding firmware for it in C language. I have begun that process and so far so good. I will say though that the Keil PK51 Developer's Kit is an evaluation version and is necessary to convert the C code into the .hex file the microcontroller needs. The evaluation version limits your code size to 2kb which is unacceptable. To get the full version and get that restriction unlocked you have to fill out a form on their website (silabs.com) and they send you a code by email and you can then use that to unlock the software fully. So I did that and am now good to go on that front. While beginning this long journey, I also have been figuring out how single wire bi-directional communication between my arduino "flight controller" and the 8051 Busy Bee microcontroller on the ESC will be able to talk back and forth. I decided to make a custom communication protocol from the ground up for this which I will also then use for all communications between all of my various microcontrollers in my robot's microcontroller network throughout its body. So working out the details of that has also been a recent challenge. But with chatgpt's help I'm making steady progress and have a nice overall plan already. Things are moving along nicely.

How long do you think it will take to finally finish and have a working robot

>>158338

Too long to know like decades

While on my journey to develop the firmware for the ESC so far I was trying to figure out how to implement all the features the original ESC has to offer in its hardware setup but then it occurred to me that I don't need most of that stuff. And a lot of the complexity that was in the original ESC firmware I also realize I don't have to recreate or reproduce in the C language with my own style and formatting but can just leave out entirely. I recalled that my plans for a long time prior to now were to have the BLDC motors operate in a blind manner. This is called open loop commutation. Back EMF normally closes the loop or a hall effect sensor closes the loop or a encoder closes the loop but I had long ago determined I don't need a closed loop. All I need is for my code to instruct the stator's rotating magnetic field to advance through each of its 6 commutation steps either clockwise or counterclockwise at a certain speed and a certain acceleration/deceleration and to do so with a certain duty cycle which will dictate how much power it is moving with. So it can move with a lower duty cycle for a gentle touch or a high one for a rough and rigid or load bearing hauling effect while under serious load etc. Now the back EMF is nice for drones because they are trying to maximize thrust and do so as efficiently as possible but I don't need all of that. If my rotating magnetic field is too fast or not high enough duty and it happens to blindly pass up the rotor because the rotor can't keep up, I call that slippage or desynchronization. And some would feel that is not acceptable and that back EMF or an encoder would prevent that. The logic there is that slippage will result in a single lost revolution perhaps more than one resolution will be lost and that will make the motor's actual rotor location begin to drift further and further from the expected location so that the resulting end stop location will be significantly different from what was expected of it and therefore the accuracy will be thrown off and people feel this is unacceptable. However, consider the 3d printer (well at least the older ones not sure on the new ones), when they hit something or w/e and have some hiccup, the stepper motors sometimes skip or have slippage as I've been describing and that throws off the whole rest of the 3d print. Those 3d printers have no feedback but just give a best guess speed and power level and assume the rotor will always keep up and stay inPost too long. Click here to view the full text.

All of that to say, we want to keep our ESC firmware simple, dumb, and very limited. This way it can be made very bug free and made more quickly and not require frequent revisions and updates to perfect it over time. It can be a staple. And then the adaptive main brains PC AI can be doing the heavy lifting and take on the responsibility to play that ESC like a musical instrument with great skill. Keep the ESC dumb and make the main brains PC be smart in its use of it I say. Keep the complexity higher up the food chain and let the dumb worker bot ESCs and stuff stay dumb and just follow orders blindly I say.

So that is my return to my previously envisioned approach to this and I feel quite confident it will work out well and chatgpt agrees with me on that.

Moreover, our arduino will also be measuring current so if we see a current increase it can be a collision detection clue and we can report that back to the main brains PC and he can then decide to up duty cycle or slow down to address the extra load or resistive forces that have been encountered - or it could be that this just indicates touchdown - like if grasping for a cup, slippage and current spikes can indicate that we have contacted and are now actively grabbing that cup and the main brains PC can instruct the ESC to just hold steady at a single commutation angle and stop rotating because we are now actively gripping the cup or w/e. So in that case it would not matter really. In fact, I really can't think of any scenario where slippage would be disastrous in its affect for our designs. Also of note is I do plan to put strain gauges on the fingertips so that would also help to know when grip has occurred and how hard the gripping is. So we have multiple redundant clues going on.

And one more thing: because we have a 16:1 downgearing minimum on our BLDC motors, there are going to be a ton of full revolutions of the motor before significant movement of the joint even occurs. Alot of turns are just tightening up slack in the pulley system. So concerns about motor wiggle at startup and things like that making the robot seem like it has the shakes are also not going to be an issue for that reason among others. Also the fact that so many turns are involved to make a full joint rotation means that misPost too long. Click here to view the full text.