aFrInaTi0n

Some more information would be nice to give reasonable advices: Which kind of motors? For how long were they running until it shut down? Weight of the model? Seems the A Peaks are 2.35, so I am guessing its buggy motors - two of them (even of separate PF ports) easily drain too much from the battery (as you see the low voltage of 11.4 as a result). Recommendations without knowing more would be: Decrease the weight of the model Change the gearing for having more torque but less rpm at the wheels use more than one Buwizz (depending on 1. or 2. even one buggy can be too much with the wrong setup for one buwizz I guess)

Thanks @FriedlS for the nice pictures! 👌🏻 so I hope I those also will be included in the diff-alone product. Bear with me - the package was sent already from mainland china.. 🙃

@FriedlS got in touch with em and placed an order for 2x the square frame diff alone without further gimmicks - but with outputs with lego axles as it is a valid option - hopefully I explained my needs well enough :D From the picture of the single diff product it seems to have "non-LEGO"/ RC outputs -> that is my confusion, as I would like to have this product with LEGO compatible outputs..

@zen-es Is the Differential with LEGO Axle inputs and outputs able to be ordered separately? Wrote you guys a request via your webform already.

Great project of yours, had watched some of the videos, also the latest TRR and its funny and impressive! Will ask questions if I got any - thanks! My hopes are that I can solve most of my future issues on my own as I am an IT systems engineer.. so should work out (excepts electronics maybe.. weak field yet :D).

OH you didn't get a single comment yet? :O Need to say thank you! Recently got myself a Arduino BLE Sense V2 to see if the onboard gyro is usable to maybe do some funny things together with lego.

Arent there any generic BT HID libs? Sorry but using SDKs from the vendors of PS5 / XBOX may not be the best approach as you may just have implementations for specific controllers.. https://developer.android.com/games/sdk/game-controller or https://developer.apple.com/documentation/gamecontroller/supporting_game_controllers as a starting point for generic input support..

Ah thanks for clarification!

Can you tell the reason for this? I know it is correct that way, but except motorcycle fronts, V- or all symetrical patterns it needs to go the other way. The regular arrangement makes sense to me, as water is channeled from the middle to the outsides of the tread - isn't the other way around leading to water being pumped towards the middle? I would really appreciate an (private, if too off topic in here) answer.

I would more like to have the old Blacktron series continued or some of that era - no fckng licences needed, as they just increase costs for customers and limit creations to be somehow realistic (and maybe less functional in the end).. edit also there is no real VTOL spacecraft available irl - so I would hope to just be fantasy scifi

For the last two pics, I guess the threads are still wrong... for V-shaped profiles the intersection of the two lines needs to go "forward" / needs to touch ground first at the rotation. As far as I remember the idea is to push the water into the channels and with continuous contact direct the water to the outer edges of the tire. Conversely, the water is pushed from the outside to the center and would increase risk of aquaplaning. But I guess its not needed for MOCs :D

Nice it worked out! Looking awesome!

Nice looking! One idea for the model / render looking better: In the LDraw library, there is also the pneumatic cylinder in its extracted position (https://library.ldraw.org/tracker/24079). It can be downloaded via my LDraw-to-Studio downloader to be used from the CustomParts folder - only caveat: connections need to be added manually in PartDesigner. Direct link to the 19475-f2 to be downloaded. Edit: meh, extented size is half stud longer then the small shock absorbers.. so may not for your mountpoint.

Ah damn, then excuse the little misassumption :D Oh, proper Controller Support will be a kickass feature! Best wishes for a fast working implementation there! Edit: HW Feature-Request for a Buwizz4: A Gyro sensor :P

I would also be interested, if for e.g. the gyros three axis could be used as drivers for outputs with the possibility to have some adjustablity for the multiplicator of the input towards the output. Example: Self Balancing Model: Model with 2 parallel wheels, Buwizz mounted 0° in the model User could use an Input of Type "Gyro", config options could be: Multiplier for the generated values to the output Which of the three Axis to use for measurements (x,y,z) I reckon this would only work out with pwm motors / original LEGO servos. Also generally asking: As the BT stack issues are solved and the newer PWM motors are implemented to be used too - what are the next steps and are there any estimations, when those could be released into a next BETA release? (no, writing an email unfortunately wouldn't help me as the responses are regulary just bs.. ) Best regards

@NYYLE I know, having released an own app may be nice from the perspective of your own reputation - but wouldn't it be better to hand this over to BrickController as an Feature/PullRequest? Only my opinion here - but another app just for MK Boxes would be not of interest to me, as I don't see any additional value for myself..

Updates from me! MOCs: RC Superbike Series - Free Chassis RC Superbike Series - Kawasaki Ninja H2 RC Superbike Series - Display Stand Another thing which just came to my mind yesterday and wasn't tested by anybody (in the brickworld) I guess: Using a virtual pivot for a motorcycle to get rid of a physical one.. Seems like Newton is with me - just need to put it onto a prototype - hopes would be, that it may have less slack then regular coat-hanger physical mounts..

Too clickbaity to even considered to be watched by me. I better keep my mouth shut for people trying to surf on others reputation for their own good.. but only my personal opinion and there may be others :)

Set a trap nextime... get a ww IP and then let the Lego idiots copy it into production & only then hit them hard... "play fair" and so on...

@msk6003 have you recreated a complete fresh profile? At least for me I got some weird outcome of using old profiles in the new app version, recreating them from scratch solved the issue.

It depends on several aspects: Selection of rendering on CPU or GPU (gpu ponly possible with NVidia graphic cards) Hardware being used Used Rendering Engine (POV or eyeSight/cycles) Quality settings of the render (Sample size) Parts with special materials/surfaces (transparent, luminous, metallic, chrome color types) To give some examples (out of my memory, may not be accurate), main components were the same (Ryzen 5 3600x at 4.3GHz, 32GB RAM (3200 clocks), SSD for system and data partitions), Rendering same object (small partcount models, but with reflective materials and some lightsources etc) in a FullHD resolution with High Sample Rate in the Eyesight render on the GPUs: CPU computation: 15-20 Minutes Old Geforce GTX1050 (2 GB VRAM): 12-15 minutes per image Current Geforce RTX3060 (12GB VRAM): ~4 minutes per image Hope that somehow helps as a starting point - if others tell their render times, I reckon it would also be very benefitial to have the specs of the system given. RAM or VRAM isn't giving the huge increase inbetween the graphicscards, it is more a thing of their new generations having a multitude of faster working computing units, the 2 GB VRAM on the old graphicscard were never a limitation for my renders - RAM / VRAM may get a topic to be concerned for real huge models with tens of tousands of parts to be loaded into the renderer. Another general thing I recognized to have a little speed up: Setting the task priority for the running eyesight.exe from normal to "Higher priority" in the windows task manager seems to enable the Windows Kernel / resource Schedulers to give it a little more throughput, but this may result in lag of other running applications (watching videos in the browser for e.g.).

I think its too risky for them getting plenty of complains of watered units... But I think there was at least one guy @Marxpek who 3dprinted a case for the Buwizz (2) with some rubber ring to seal it of from at least splashing waterdrops, but if I remember correctly, one would better not try to submerge it completely in water :D Ah, here you go:

I would be soooo scared to wet the electronics somehow as I usually have bad luck with such "ideas" :D Thanks for the additional pictures!

Nice to see the next boat season has started. One question: Is the skipping teeth sound coming from the steering? (Via regular motor instead of servo?) Best regards

All fine and thumbs up if it is working as expected now. Asking for help should never be considered wrong by anyone.