Powered up hints, tips and requests thread

[allanp]

I did a quick search and couldn't find a similar thread besides the control+ general discussion thread, so apologies if a similar thread already exists.

This thread is intended to demystify the whole custom controls thing in Powered up. Here we can share our tips and tricks, and our programs that we've made, kinda like the axle collection thread, and we can also request programs from the community as well. This is not a thread for critiquing powered up, but about making the best of what it currently has to offer. I'll start with a couple little tricks I have found. 

[TIP] When you are setting up a servo motor, like for steering for example, the program starts and does it's calibration step. However, when you play with the model I have found the servo tries to steer too far on full lock, which causes the motor to bind and remain stalled drawing too much current from the hub and slowing everything down. You can resolve this issue by adding a 0.8 multiplier to the servo command block, so the motor will stop before being mechanically blocked. You can tweak this 0.8 figure up or down to give you as much steering lock as possible before the motor is mechanically blocked.

[TIP] You can reverse the direction of a motor or a servo by adding a multiplier to the command block, and multiplying by minus 1. In the case of the servo motor above being multiplied by 0.8, instead multiply it by minus 0.8.

[TIP] I have found the custom controls programming to be quite buggy. Like today I was making a 4 wheel drive, 4 wheel steered vehicle, using 2 motors for steering. One steering motor had a plus 0.8 multiplier, with the other steering motor having a minus 0.8 multiplier. Then when I pressed the controls button to test, it wouldn't calibrate or do anything remotely like what I wanted. The motors would just wiggle a bit and make funny PWM noises. But I was able to make it work by just unlocking, then locking the controls screen using the little padlock icon in the top corner, then for some reason it worked perfectly. I suspect doing that resets it somehow, so it could be a useful trick if you find your programs not working right.

[TIP] A servo is not limited to 90 degrees either side of zero like the old PF servo motor. It will use it's calibration step to find out how far it can mechanically travel and then use that to know how far it has to move. I don't know what the limit is but so far I have found it can do several rotations either side of zero, which is very useful if for example you want to make a big, heavy articulated vehicle, and you want to gear down the servo motor to gain extra mechanical advantage.

I'm sure these are very basic and well known tricks already, but I am far from any sort of expert when it comes to Powered up, and the whole idea is to help those who perhaps would benefit from those of us who are much more knowledgeable. So are there any other tips and tricks you would like to share, any programs that you think would be a useful for others to copy, or are there any requests for programs, for example:

[Request] Program for Claas 42054 style steering. I would like to have a vehicle that has 2 steered axles, controlled by two servo motors (one motor for each axle). For the controls I would like to have 1 horizontal slider for steering, and 3 buttons to select between 3 steering modes, 2 wheel steer, 4 wheel steer and crab steering.

Maybe others more knowledgeable than me could also post a block showcase, where they pick one block and explain in detail everything that block can do. Scrolling through the many blocks I must admit I don't know what half of them do!

@kbalage Also, may I have permission to include this link? https://racingbrick.com/powered-up-code-block-guide-full/

 

 

 

Edited February 6, 2021 by allanp

[howitzer]

Great topic! I don't have much to contribute for now, but your tips on the servos are very nice to know, as my excavator project has a gearbox selector which needs to work like servo. I thought of running it "blind", just having the motor turn for a set amount of time so the gear selector would switch, but calibrated movement might be better. Right now I'm learning to code with Python, so it's hard to say how much of this code block knowledge will translate there...

[allanp]

[TIP] 2 wheel steer, 4 wheel steer and crab steering modes for a 2 axle vehicle.

This code is based on a test rig I quickly put together. It doesn't have suspension and is rather crude (albeit quite powerful), but it serves the purpose.

It has 4 L-motors in total, 2 for drive and 1 to steer each axle, note the blue letters on the picture below to see which ports they are plugged into.

The control scheme looks like this:

You don't need all the dials, but I just like lots of dials! The Black horizontal slider is set NOT to return to centre and is to select between Crab steering, 2 wheel steering and 4 wheel steering. The other 2 grey slider are set to return to centre. And here is the code:

To "operate" or play with, just use the horizontal and vertical sliders as usual to drive the vehicle. Note that you may need to unlock, then lock the control screen to reset (this seems to clear some bug with the calibration). The black horizontal slider allows you to select between the steering modes and can be moved on the fly while driving, and is also infinitely adjustable in case you want the rear axle to only have a small amount of steering. 

Some notes to explain the code.

Starting at the top left we have the steering motor for the front axle connected to port D, being controlled by slider 1, which is the main steering control. You may notice I have a 0.75 multiplier. This is to prevent the servo motor from reaching it's maximum limit. It's kind of like a safety to prevent stress.

The next code block down controls the steering of the rear axle. So this time we have the steering motor on the rear axle plugged into port C and is also being controlled by the main steering control slider 1. This is then multiplied by the same 0.75 safety margin. This is then multiplied by the position of slider 3. Slider 3 is the steering mode selector and you may notice that is has a 0.01 multiplier. This is to convert the standard range of a slider from -100 to 100, to -1 to 1. 

On one of the drive motor code blocks you may notice a -1 multiplier. This is to change its direction of rotation.

The 2 dial code blocks below that are taking/measuring the speed from the two drive motors. Dial 4 is measuring the speed of the motor connected to port B through a -1 multiplier to account for it's reversed direction, and dial 2 is measuring the speed of the motor connected to port  A. It's pretty cool that by doing this you get the actual speed of the motors, and not just a representation of the throttle position.

Below that are the two dials that measure the turning angle of both axles. Dial 5 is measuring the angle of the motor connected to port D, and dial 6 is measuring the angle of the motor connected to port C. To both of these I added a "+100" to centre the dial, and a divide by 2 to suit the dials range of motion.

Note that the small green blocks used to capture the motors speed and angles for the dials look similar, but  they are not the same. There are 2 different blocks used for capturing the speed of a motor and the angle of a servo.

 

Edited February 7, 2021 by allanp

[2GodBDGlory]

I recently finished a small-scale Jeep Cherokee XJ using Powered Up, with a four-speed gearbox that can function either manually or automatically. The program is somewhat crude, but I may add it here in the near future.

[Johnny1360]

I desperately need this thread, I am at a complete lose when it comes to using PU in a MOC, so I will be revisiting this thread often.

Thanks for creating it.

 

[kbalage]

 

On 2/6/2021 at 9:57 PM, allanp said:

@kbalage Also, may I have permission to include this link? https://racingbrick.com/powered-up-code-block-guide-full/

Sure, feel free to share it anywhere :) I also have a page describing the Powered Up ecosystem in general, worth to check for someone who's not familiar with it. And here is a YouTube playlist with all my videos related to Powered Up, including tutorials, tests and more.

[dr_spock]

Using the tilt sensor for control can save your finger joints pain from tapping on hard glass too much.

 

[2GodBDGlory]

On 2/6/2021 at 3:57 PM, allanp said:

 

@kbalage Also, may I have permission to include this link? https://racingbrick.com/powered-up-code-block-guide-full/

I highly recommend that guide! A few hours spent reading it and trying each block to see if it did what I expected, and I was able to start making my own codes!

[Gimmick]

Tip:

Use motor angle as input value for other motors. Example: Simple remote control, build in speed/power/direction control in mechanical sets.

Code-Image:

What it does:

• Set the angle of motor C as input on the speed control of motor A, set 'a' to 1, save current C position as 0°, limit the max power of C to 15% and force C to return to 0 constantly [can be changed to check if angle != 0, this could save battery].
• In this example the max possible angle of C is +/- 40°, but the speed control needs a normalized -100 to 100 input.

 

• Optional: Run calibration on C. The calibration in the blue custom object can not be started from the mainprogram, if you include the calibration block in the main screen it will start immediately and can not be stoped without stopping the whole program. But the loop does somehow overwrite the behavior of the calibration, so if you insert a "wait 3 seconds" block before A is set to 1 it can be ok. Optimal solution could be: Use the 'old' self-made calibration from @kbalage wich can be found on racingbrick.com.
• Optional: Angle of C is multiplied by 'a' to make it easier to stop and to prevent uncontrolled behavior if you play with the calibration block.

-> If you let go of the wheel/gear/lever which is connected to C it returns to 0. The force and speed needed depends of the construction and personal preference, mechanical assistance like a rubber band can be useful to make the movement smoother.

[allanp]

Tip: RC Pneumatics

 

Please excuse some of the sun yellowed pneumatic pipes 

BTW, I seem to have some issues with programs not being saved. Sometime I reopen the app to find that the code is still there but the controls have all gone, or sometimes the controls are there and the code as gone. Another issue is that I can't seem to be able to name the different programs. When I select to name a program the keyboard doesn't show up on my phone.

[ord]

@allanp I've been facing the same problem with the keyboard not showing up (I upgraded to Android 11 and app version 3.6.0 recently so maybe it's because of one of them?). 

As for the programs not saving, I feel like when this has happened to me it's been when I've closed the app without exiting the program but I could be wrong.

[allanp]

@ord you can exit the program? All I can do is swipe the program off the screen!

[ord]

1 hour ago, allanp said:

@ord you can exit the program? All I can do is swipe the program off the screen! 

What I meant by "exit the program" is to click the back arrow at the top-left of this screen, which I think might save its current state:

On 2/13/2021 at 1:01 AM, Gimmick said:

 



 

[Andman]

On 2/6/2021 at 9:57 PM, allanp said:

[TIP] When you are setting up a servo motor, like for steering for example, the program starts and does it's calibration step. However, when you play with the model I have found the servo tries to steer too far on full lock, which causes the motor to bind and remain stalled drawing too much current from the hub and slowing everything down. You can resolve this issue by adding a 0.8 multiplier to the servo command block, so the motor will stop before being mechanically blocked. You can tweak this 0.8 figure up or down to give you as much steering lock as possible before the motor is mechanically blocked.

Thanks for the tip. I noticed that problem during a test of a truck today. Will test your solution.

I have another issue or features (depends on the perspective :-) That truck has three axles, one in the back (live axle) and two steered in the front (independent suspension). All of them have pneumatic suspension. I would like to build not only an automatic height leveling system but it should also be variable. As possible inputs the height and the angle of the suspended axles are available. The height ranges from 1 to 5 studs ground clearance. The angle of the front axles steering arm can rotate 45 degrees. The mechanical solution would use movement to switch the pneumatic switch to adjust the hight. But that limits the height of a vehicle to just one. You can see an example here: 

 

While it maybe possible to build a mechanical heights adjustment system, which also makes it possible to adjust the desired height, I would like to solve that electronically. I already was able to read angles from a C+ L motor. The issue is that it is too bulky for that purpose and the resistance to rotate it has a negative effect on the suspension. The other option could be the distance sensor or the tilt sensor. But their "resolution" and responsiveness is not so good as far as I know.

So has anybody any other idea? Or experience with the tilt and motion sensor? The mechanical issues with the L motor/rotation sensor aside: Can anybody say if it could be possible to program something like the above mentioned in the app powered up app?

Edited March 27, 2021 by Andman
added question

[Gimmick]

@Andman

Just an idea:

Split the pneumatic system in two parts: left and right (or rear and front, but the angle might be to small)

Condition1: on program start the current height is known.

Increase height:

save current angle.

increase height on one side, calculate the height based on the angle -> stop if height is reached -> increase height on the other side until the angle is identical to initial angle. It depends on your requirements, if the function has to work on uneven surfaces.

You can do some dry runs by turning the hub by hand and connect two motors for the valves. A reset button for setting current height = max or 0 will be usefull i guess :D

[Andman]

I'm going to split it into three unit. Left middle/front axle, right middle/front axle and rear axle. front and middle are connected in a way that it simulates a bogie suspension. That means when one wheel goes up that other one goes down. That also means as long as one wheel is going up in the same way the other one is going down, the valve to the pneumatic cylinders should remain close. Only when the compression or decompression of the cylinders and therefor the change of the steering arms angle is uneven a servo should open the valve. Same applies for the rear axle. As long as the axis swings around the center, the valve should remain closed.

So basically i need one angle sensor per "unit" and not for every wheel.

11 hours ago, Gimmick said:

if the function has to work on uneven surfaces.

This is exactly the reason why i can't use the internal sensors of the hub. It can't detect, if the values changed because of a steep or because of uneven ground. Or am i wrong?

For calibration i can imagine something like:

1. Open all valves to lower the height until the height of the vehicle or the angle of the steering arms does not change.
2. Switch valves to the opposite direction, Run pump until the height of the vehicle or the angle of the steering arms does not change.

Now i have min and max. In the app i would like to have buttons to change the height to fixed values or a slider to change the height like i want.

Here is a picture with some ideas. The rotation could be read from the yellow axle connector

Edited March 28, 2021 by Andman
added picture, typos

[Rebel_Lego]

Sorry for the massive bump, but I thought this was the best tread to post my question. Is there a way to put the power of the motor calibration lower? Because my L-motor tears the steering system apart...

[Andman]

24 minutes ago, Rebel_Lego said:

Sorry for the massive bump, but I thought this was the best tread to post my question. Is there a way to put the power of the motor calibration lower? Because my L-motor tears the steering system apart...

Not that i know. Some mechanics of one of my MOCs suffered the same problem. There is a code block to lower power of the motor. But that one does not affect the the calibration procedure. Which combo of gears are you using? If you are using old style gears, newer ones might be sturdier and solve the issue as it did in my MOC.

[Rebel_Lego]

The problem is that a connector slides of the axle so something I can’t change. I’ll try figuring out a different solution.

[Andman]

46 minutes ago, Rebel_Lego said:

The problem is that a connector slides of the axle so something I can’t change. I’ll try figuring out a different solution.

Than the only advice i can give, is to secure that connector.

[Rebel_Lego]

I figured something different now, securing the connector wasn’t an option because the turning radius would be like an oil tanker, the steering works fine now

[Rebel_Lego]

Hi,

A motorized MOC of mine uses the PU City Hub (the one with two ports) and two L-motors. When I'm driving around, after five minutes or so the app lags and doesn't react or only steering reacts. I can move the slider, but the value I read in the dials says that the value doesn't change. In other words, the thing stalles and holds the last value, making my truck drive forward without any possibility to control it. Is anyone else experiencing these problems and has somebody a solution to it?

[Gimmick]

@Rebel_Lego

So the truck stops, or does it keep moving if the "last value" is not 0? Are the dials linked to the motor-output (for the real value) or to the sliders?

Maybe add some simple blocks to the coding area so you can start the motors without sliders and use that if the problem occures again. Just to check if it's a problem with the interface or maybe some kind of overload protection on the hub that kicks in.

[Andman]

On 8/14/2021 at 3:35 PM, Rebel_Lego said:

Hi,

A motorized MOC of mine uses the PU City Hub (the one with two ports) and two L-motors. When I'm driving around, after five minutes or so the app lags and doesn't react or only steering reacts. I can move the slider, but the value I read in the dials says that the value doesn't change. In other words, the thing stalles and holds the last value, making my truck drive forward without any possibility to control it. Is anyone else experiencing these problems and has somebody a solution to it?

Could you please post a screenshot of your code?

[recklessGlitch]

On 8/14/2021 at 3:35 PM, Rebel_Lego said:

A motorized MOC of mine uses the PU City Hub (the one with two ports) and two L-motors. When I'm driving around, after five minutes or so the app lags and doesn't react or only steering reacts. I can move the slider, but the value I read in the dials says that the value doesn't change. In other words, the thing stalles and holds the last value, making my truck drive forward without any possibility to control it. Is anyone else experiencing these problems and has somebody a solution to it?

Same problem, got it fixed  ... somehow

I am using the hub in a motorization of the 10300 DeLorean (https://rebrickable.com/mocs/MOC-142730/). I had the very same problem:
After some time the hub stopped reacting while the drive motor kept running, crashing the car...
So I tested using a simple big tractor wheel attached to the L-motor driving back and for. Again, same behaviour.

Programming / overload Protection???
I also asumed it may be some kind of protection. I tried LEGO's own crocodile control (in the powered up app) and it seemed to work (using a very slow way to change speed)
so i experimented with changing my Powered Up programming to react more slowly on input. Indeed that bought me some time but it happened again after a few more seconds.

Batteries
Philo (https://www.philohome.com/) suggested then to use rechargeable Batteries: The normal throwaway Alkalines deliver less current and their Voltage goes down under pressure. So I started using rechargeable NiMH AAA batteries. Then I tried it again - coincidentially using my old phone (Samsung galaxy s5 android 6) and it worked. Several people have confirmed it.

Android Version??
Some time later I used my current phone (Huawei P20 pro, android 10) and the problem appeared again. I swaped phones, S5 works, P20 apperas to work but produces described problem, consistantly.

Fazit:
So is it just a software problem occuring on certain Phones or is it also a Voltage/Current Problem fixed by new batteries? Using rechargeable Batteries is better any way.

The myth of overload Protection:
I have just tested another gearing for the DeLorean, more geared up, which also drains more current(ampere) from the motor.
Using the buwizz 3.0 to control the motors, there is a built in Ampere-meter: I can see the overload protection kick in at about 1.5 - 2 Ampere (which would be a lot). It happens at around 30% of speed, result: Disabling the motor for a second maybe. After that everything works finr. That is very different behaviour from the behaviour described for the city hub.
By the way the city hub does not stall, it keeps working, only it doesn't deliver enough power to really speed up the DeLorean with those gears. So do the motors have an overload protection? Or is it inside the hubs?


DeLorean Motorization using the Buwizz 3.0