pdw

The fundamental problem with this approach is that the perpendicular distance from the 5L beam to the hub is not constant. You can see in the image that the axle is not centred in the pin hole of the cross connector. To make this approach work, you'd need that connector to be hinged at both ends so that it can remain parallel to the wishbone arms. Did you mean outward or am I misunderstanding? I think this design would put a lot of stress on the connection between the brown axle and the hub.

It's already using a worm gear, but that's not sufficient. It's the fork tilt control for this model. I want to be able adjust the tips of the fork height by less than a stud so that I can get them aligned for sliding under a palette. This is about 10° of fork tilt. It's controlled by a worm gear driving a 20T gear, so a full motor rotation is 18°. There's a little bit of scope for playing with the geometry of the connecting arm, but no space for any additional gearing. The issue isn't running the motors at slow speed, it's getting them started at slow speed, and the lower PWM frequency seems to do this.

A bit of a breakthrough on this one: I've discovered that SBricks allow you to vary the PWM cycle length, and if I use the maximum value for this, which works out at about 73Hz rather than the usual 1KHz, it seems to work beautifully. The motor will reliably start at low power even when loaded, and I can reliably turn the motor fractions of a rotation by tapping the output. Since discovering this, I've found out that PFx Bricks have a "torque compensation mode" which does exactly this - low PWM frequency drive. At the moment I've just got a hacked version of BrickController2 for testing, but I'm planning to turn this into an option that can be set on individual outputs.

I've got a PF M motor that I want to be able to move very small amounts. The problem I've got is that whilst the motor will run slowly, getting it started requires quite a lot of power such that the shortest possible tap of a button moves it too far. I've noticed quite a difference in the behaviour between an SBrick and a BuWizz running at the same voltage. For example, where the SBrick takes about 85% power to reliably get it moving, but the BuWizz needs just 60%. As you'd expect, running the BuWizz in high power mode reduces the percentage power needed to get it moving, but strangely, in ludicrous mode it's completely stalled at the same percentage and requires a much higher percentage power to get it moving. My only theory is that the stalled motor is tripping the current protection at the higher voltage. I've tried hacking the BrickController2 code to send the shortest possible burst of power to the device, but even that seems to be too long. I've also tried a fake M motor which behaves differently again, but not usefully so. Any other suggestions or experience? Obviously the right answer is lower gearing, but that's not really an option here.

That looks like the thing I've seen, wired in series with the motor, not across the terminals, and positioned so that it's in contact with the motor so I assume it's a thermistor.

Fully charged NiMH batteries should be around 7.2V, so if it's less than 7V fully charged you have a problem. My SBricks generally seem to run at around 32C. I can't remember if the SBrick app does it, but you can get the SBrick Pro beta app to give you a live voltage read out, which would be useful to see what the voltage is dropping to under load. You say you have two batteries and two SBricks: do you see the same problem with both, or can you isolate the problem to one of them? Lego motors have thermistors in them which will drop the power if they get too hot, which might explain the progressive power drop you're seeing, but I wouldn't expect that to have a knock on effect on the servo. My first guess would be a problem with the power source, so I'd check the voltage you're seeing on the battery boxes, and if that's low, check each cell individually.

Not experienced either of these. Which app are you using to control it? What temperature and voltage are the SBricks reporting when you're seeing the problem?

From watching your video, I don't think it's the voltage that's going to kill your Lego, it's that wall :-) I'm curious about this. I've not taken a PF M motor apart myself, but the images and videos I've seen all seem to show a thermistor. Meanwhile I've seen various references to M motors having a large filter capacitor, which I've not seen.

The slack is only really noticeable because it's 4 wheel steer, and you can sometimes see the front wheels turned a slightly different amount to the rear wheels. I reduced it a bit by bracing the cross axle as much as possible. Quite a lot of the remaining play is due to the very short axle in second servo. As you say, I don't think there's any alternative at this scale.

@eric trax's brilliant CLAAS Scorpion 756 telehandler MOC is the first Lego model that's really inspired me in a long time. I found the combination of clean, scale looks and a genuinely "playable" but compact RC model very appealing. My original plan was to build the model and stick a few lights on it, but it transformed into a bit of a project for me. This has turned into quite a long post, so I've hidden some of the details in spoilers. The original model has four wheel steering, but the CLAAS telehandlers have four steering modes: two wheel, four wheel, crab and "offset", and I found myself wondering if this could be reproduced in the model. This meant squeezing another servo and more wiring into an already tight model. I originally built the model with two SBricks rather than three IR receivers, which bought me a little bit of space in the cab. The bevel gears do introduce some additional play into the front steering but it's not normally too obvious. The next challenge was how to make the steering controllable in the way that I wanted, which lead me on a bit of a software development journey. More on that below. The other significant mod is the mudguards. At first I concluded that there simply wasn't space, but after a lot of attempts I struck upon something that works, and that I'm happy with. I had to redesign the rear lights in order to get more clearance (I think the result is actually a bit closer in style to the real thing) and the front of the cab and exhaust position also needed tweaking for more clearance. Lights Two SBricks for six functions meant two spare channels, which I filled up with lights: Six front lights Two rear lights Front and rear left and right turn signals Rotating beacon light I tried hard to keep the wiring as discrete as possible, but I must own up to drilling through a hollow stud for the beacon wiring. Other mods I made a few other "functional" mods which may be of interest to others building this model: Slope bricks on the front chassis: Spacers rather than axle joiners on the arm extension driveshaft, to remove the risk of the tilt motor cable getting sucked through the hole in the top of the arm. The spacers rotate freely, avoiding the cable getting snagged. Extra half bushes in the lower LA joint to fill the gaps and prevent cables getting caught in the gears. I slightly redesigned Eric's neat system for quickly changeable attachments so that I could use the bucket on the same system. The change was necessary in order to get enough clearance for the full range of bucket tilt. It's a step back aesthetically, but it's worth it for me for the ease of swapping. Controlling the model As mentioned above, the Scorpion has four steering modes. Rather than just putting the two servos on separate controls, I wanted to try and emulate these modes: 2WS, 4WS, crab, and offset mode which allows the position of the back axle to be set, and then the vehicle steered using the front axle whilst crabbing. SBrick Pro Beta In order to implement this, I started looking at the SBrick Pro Beta app. This uses visual programming to allow you to do just about anything with different controls. I got quite a long way down this path, including things like differentiating long and short button presses on a gamepad, emulating a self-levelling fork by blipping the tilt motor when the elevation motor is running, various steering mode switches, and a "drive mode" switch to temporarily put the accelerator and steering on separate joysticks for better control. I even implemented a system that ramped up steering sensitivity as you increased the crab offset so that you could have the model crab forwards with the joystick centered, but still reach full lock in both directions. Unfortunately, and as you'd expect from a beta, it's still quite rough around the edges, and whilst it makes doing complicated things possible, it makes doing simple things quite hard. One issue is that are no events for joystick input, so you have to run a tight loop to constantly poll their position. I think as a result of this, the app is absolute power bandit. Overall, it's a great app with a lot of potential, and I'm really looking forward to future releases. I found that the drive on the model was a little underpowered, particularly when turning, which I think is down to friction in the CV joints. The model was also getting enough play that swapping and charging AAA batteries was getting boring. The new SBrick app supports lots of other devices, including BuWizz. BuWizz on its own isn't ideal for this model as it doesn't have enough channels, and it'd be a struggle to fit two of them, but the combination of BuWizz + SBrick seems like a real winner: 8 channels in less space than a AAA box + one IR receiver. Thanks to some great service and very fast delivery from BuWizz, I was able to get a BuWizz out of the EU before the UK, so I swapped the battery for a BuWizz. Unfortunately, I immediately hit a problem: the BuWizz only turns on power to the permanent lines of its outputs once it's connected over Bluetooth, which means that if you power an SBrick from a BuWizz, you must connect to the BuWizz first. The SBrick beta app doesn't do this, and it's close to impossible to get it to connect to all devices at once so I found myself looking at BrickController2. BrickController2 BC2 has the same problem, but it can be tricked into finding the SBricks by running the BuWizz app in the background. Even once you've discovered the SBricks, reconnecting was a bit hit and miss. Fortunately, BC2 is open source, and I managed to fix this myself (hopefully this will be in the next release). BrickController2 is a great app. It's fast, reliable and easy to configure, but didn't allow me to implement the different steering modes I wanted. The joy of open source (and a good few hours of coding) mean that I now have a custom BC2 app with a flexible system of "modes" that can be set or toggled using controller buttons. This allows me to switch between 2WS and 4WS, and crab and normal. I can also press and hold a button to set the rear axle position for offset mode, and the position "sticks" when the button is released. I intend to submit this feature in due course, but the code needs a bit more work first, and I'm happy to have been able to contribute a handful of other minor bug fixes and features to BC2 along the way. Still to do The one unresolved issue I want to address is trying to make the fork tilt more controllable as it seems very hard to control the speed of the motor. Set at 100% power, the fork moves far too fast to be controllable when unloaded, but set at anything less than 100% and it often doesn't have enough power to move at all when loaded. I also want to try BuWizz's ludicrous mode for drive, but need to add a cable with a voltage drop diode to protect the SBricks. Once again kudos to Eric for this model, and also to @M_longer for the very high quality instructions. I see instructions for some new attachments have just been released, so that may be what I'm doing next! More photos on Bricksafe. I'll try to do a video showing the different steering modes.

Your expectation is correct. Unfortunately there's a bug that means that rather than treating the input as zero when in the dead zone, it ignores it completely, leaving the output at its last value. I submitted a fix for this a few days ago, so it should be fixed in the next release.

Not got a lot to add, but having just built Eric Trax's Claas telehandler (with some mods) I'm following this with interest. It's a lot of functions in a small space, and the central boom really limits the available space.

Yes, it's Studio, and yes, the XL actuators were a problem. I managed to add them as custom parts by downloading them from ldraw.org, and importing them into Part Designer, but it wasn't entirely straightforward and I don't recall exactly what I did to get it working. The only other part I struggled with was the universal joints as Studio won't let you bend them, so I had to assemble them from their components, which of course messes up the parts lists export. Here's the finished model: It's based on a Caterpillar 216B.

Thanks to BC2 being open source, I was able to take a crack at this myself, and I'm pleased to say I got it working. With my changes, you can now scan for a BuWizz, then it'll stay connected so you can rescan and find attached SBricks. I've also changed the "play" connection process so that it always connects BuWizzes first, and gives some progress as it does so. I've submitted my changes for inclusion in the app, so hopefully it'll make it into a future release. I've also got a change to allow you to use full steering at full speed on a single joystick on gamepads where you can't get 100% on both axes simultaneously.

Yes, two driveshafts running front to rear. I had the same concern about drive train stress, but went with portal hubs and 8T/24T gearing at the wheels so the bevel gears and axles are at low torque. The downside was I couldn't figure out how to get the motors between the wheels with this arrangement. Here's a render I did for the instructions. I can take some photos of the finished model tomorrow.

It'd be a nice enhancement to BrickController2 if it could keep connected to a BuWizz whilst searching for other hubs, so that you don't need to do this dance with the BuWizz app. Powering SBricks from a BuWizz is a nice way to get a lot of outputs, and the extra power from a BuWizz, but it's tricky to get everything connected (I've been having similar issues using the new SBrick Pro beta with a combined BuWizz/SBrick setup).

Following this with interest. My Christmas present to my daughter was a wheeled skid-steer MOC, and it's a really fun little model. I echo what's been said above about weight distribution. My design had all four motors behind the rear axle (PF, 2 x L, 2 x M) and the battery box (6 x AA) between the wheels and it was a bit too keen on wheelies. Managed to shuffle the battery a stud further forward and the handling is now pretty good, although it's much slower to turn when it's loaded and the weight is evenly over both axles. I think what you've got is a great start. Four motors should give you plenty of power for turning, and nice low central weight. I'm not familiar with the hub, but I suspect you'll get away with putting it behind the rear axle, especially if you can keep it low.

Well it seems they've left a gap in the market In this day and age, a massive 6 x AA battery box seems very old fashioned and inconvenient. Actually, there's lots of things I can think of that need 5. Mobile machinery is always popular (cranes, lifters, telehandlers, etc.) and once you've used two channels to make it move, two channels for other functions is quite limiting. I do think that it's a shame that given that they've made an uncharacteristic break with backwards compatibility, they didn't go for a more ambitious bus-style system that would allow far more channels, as it opens up more interesting possibilities for lights and sensors. TLG's focus may be on the sets, but as a parent, one of the reasons I'm always happy to buy Lego for my children is because I know it can and will be built into other things, so the flexibility to be able to do more with it is very important.

I think one of the most disappointing things about the new PU system is the lack of compatibility. The fact that Technic has changed so much over the years, and yet is still completely compatible with the stuff I had 30 years ago is impressive. The fact that I can't use any of my old PF motors or LEDs with PU, even in a "dumb" mode, is not. With the previous switch from old 9V to PF, there was the ingenious solution of putting an old 9V connector on the underside of one end of the extension cable. Even if the hubs just had a single PF output on them it would open up more possibilities. Cheap adapter cables would be even better. I also think that 4 channels on a massive, non-rechargeable battery box is pretty underwhelming, particularly as you can't double up motors on a single channel. Given they broke compatibility, TLG could have knocked it out of the park with PU, with 6 or 8 channels and LiPi/LiIon rechargeables in something the size of the AAA battery box. Better still, properly smart devices on a bus-style system where you don't have to wire everything back to the hub. I guess with the trend for huge models, using two hubs to get 8 channels isn't a problem for the official sets.

There's two systems: Power Functions and the older 9V system. Both are 9V, and both use a 2x2 square connector, but the connectors are different. The old system has a contact on one corner of each stud, whereas PF replaces two studs with a 4 contact connector. Those are the same thing, and it's Power Functions The former is old 9V and the latter is Power Functions. The PF stuff will all work together, and the old 9V stuff will work with the little cube 9V motors. Power Functions extension cables have a connector for the old 9V system on the underside of one end of the connector, which allows you to connect between the two systems. The extra pins in the PF system provide unswitched 9V power, which is used by the servo motor and the IR receiver, so if you want to use either of those, you'll need a PF battery box. There's lots of good information here: https://www.philohome.com/tech.htm

Very nice, and a very elegant solution to the steering. I assume the beam is only pinned in one place, and that all the other connections slide in the central channel of the beam? I'm working on a model with mixable crab/normal steering, but I only have two axles to worry about!