Andman
-
Posts
452 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Everything posted by Andman
-
You are falling victim to an illusion. It's level. And even if it isn't because of tiny height differences because of the suspension... It's nothing i would complain about. -
Absolutely right. Testing a lot IRL is absolutely mandatory. But to use something like that IRL was the purpose from the beginning on! :-) A pity that I dissembled my 42114 for another MOC. I don't have any C+ motors left to assemble it again. As for the extrem cases, a sudden stop could be handled by a conditional statement, which monitors the actual motor speed, for the gear shifting logic, which i haven't build yet, to immediately stop the motor(s) or shift to lower/neutral gear. Will try to replicate that in Powered UP. Thanks!
-
My gut feeling tells me that it could be wise to get the gear ratio at the diff as close as possible to the ratio between front drive and rear drive, so the diff turns as little as possible when you are driving. In the best case it does not turn at all, when you are driving although front and back tires have different diameters. That way you lower the total friction because the internal gears of the diff do not turn under normal circumstances. Does that make sense?
-
Could be. Do you happen to have a video showing the issue?
-
https://bricksafe.com/files/andman/prototypes/IMG_20210622_194426.MP4 Different number of tread links. Same speed at the idler gear (24z). So the length of the track has no influence to the speed at which it is driven.
-
I'm afraid you are fundamentally wrong. The circumference of the rubber track has no influence on the ratio between the front and rear tracks. The only thing which has influence, is the driving sprocket wheel. You can extend the ancathete and the counter ankath as much as you like and the tractor would still run at the same speed and the tracks would still have the same ratio. That's were you are wrong. The track is not rolling. It's is driven by the sprocket wheel. The only thing which is rolling, is the sprocket wheel and no matter how long the rubber track is, the sprocket wheel has still the same circumference.
-
Thanks @Pybricks! I thought a little bit about shifting gears and ac-/deceleration and have to think out loud. So... when do we want to shift up? When set speed is max (100) AND actual speed is 100 (or close to 100) When do we not want to shift up? When highest gear is already active When driving backwards (depending on the model and the preferences) When do we want to shift down again? When set speed is max (100) AND actual speed is not 100 (or close to 100) When set speed is 0 (shifts down to lowest gear) When do we not want to shift down? When lowest gear is already active Did i miss anything? I also noticed different behavior of the motor depending on which block you use to control it. When i use the motor power , the motor is running at 112 when i set the slider position to 100. I assume that the hub is then providing the max current allowed and provided by the batteries. When the motor is stalled, it returns to the original speed before it was stalled. When i use the tacho motor speed block the motor runs at more or less exactly at the set speed regardless, if your batteries could deliver more power. Another thing i noticed is that the motor "overshoots" for a short amount of time after it was stalled and released again. Means it will run for a short time at 112 in my case and the returns to the set speed 100 Not sure what to do with these findings yet.
-
Doesn't make sense to me too. Why should the number of track segments should matter? I very much agree with @Jundis' statement:
-
I finally had an idea how to flatten the diff between the set and the actual speed. The goal with that code is to replace the physical torque detector. Here is my approach: Declaration of variables/widgets/ports a to j - stores the actual speed of the motor at a given time v - speed set by slider widget 3 t - sets the interval at which the actual speed is read y - sum of a to j divided by the number of data points (10 in my case) z - difference between the measured average speed of the last 10*t seconds (1,5s in my case) Port A - driving motor Widget 0 - shows set speed Widget 1 - shows actual motor speed Widget 2 - shows the average diff between set and actual speed Detailed walk-through It's actually quite simple. Every 0,15s the actual motor speed an port A is measured and assigned to one of the 10 variables. Every time a value is stored the average of all ten variables is calculated. That makes the diff between set and actual speed less "jumpy". I haven't really thought through how to deal with acceleration and deceleration done by the slider 3. What do you guys think?
-
I didn't think about that problem. Good catch! Agreed, since in that case the motor wouldn't be able to deliver enough torque. But measuring the load would be better. What bothers me more is, how can i calculate a running average of a given number of value of a certain interval in Powered Up to prevent to frequently oscillating gear switches. I'll probably create a thread in the Mindstorms forum tomorrow to ask for help.
-
What do you mean by experimental code? What would be the advantage over the possible solution I posted above?
-
@Pybricks, can pybrick read the current on a given port? @Zerobricks, what do you think about my proposal? I haven't tried it out. I'm worried about the diff being too quickly changing. So it might happen that the gear is witch rapidly when the diff is close to the value where the gearbox has to switch to another gear. A possible solution could be to get the average of, for example, the last 10 values of the diff (set motor speed - actual motor speed). But i haven't found a solution to calculate a running/moving average so far. @TechnicBrickPower, any idea regarding the running average?
-
How would you measure the current?
-
Have you thought of using the diff between set speed and actual speed to detect when to switch gears? That way you don't loose force/torque at the physical torque detector and you only need two instead of three motors. Here is a quick mock-up: Blocks from left to right: sets the value of a with a the yellow slider widget 0 shows the set value of a on yellow display widget 1 show the actual speed of the motor connected to port A and green display widget 2 the diff between a and the actual speed of the motor is is stored in the var b b is shown in the red display widget 3 the green round block reads the value from a and sets the motor speed accordingly. The result looks like that, when the motors is stalled: You could switch gears based on the diff you see in the red widget, couldn't you?
-
Based on the shield width, ca. 50 studs according to @Brick-a-brac (6,3m IRL), the scale is more or less 1:16. Therefor the overall dimension in studs could be: Total length (w blade and ripper): 82 Length of Track on Ground: 34 Total width (w blade): 50 Width from track to track: 28 Height: 36
-
Would you mind to post some pictures? How do you control it?
-
Pybricks Q&A
Andman replied to Pybricks's topic in LEGO Technic, Mindstorms, Model Team and Scale Modeling
The major drawback with Powered Up is, that I have to use a phone. I would like to use my PS4 Controller instead, to get rid of the phone. So, does Pybricks support Controllers in general? If not, is that somewhere in your backlog? If it is, when will the support be roughly available? Does Pybricks currently support connections between hubs so they can communicate with each other? If not, is that feature in your backlog? If yes, when will it be roughly available? -
Technic 2021 Set Discussion
Andman replied to LvdH's topic in LEGO Technic, Mindstorms, Model Team and Scale Modeling
Forgot the incident with the ship Ever Given in the Suez Canal? Who knows what that will mean for the availability of sets in the world. -
Would assume the same. Now what?What's the best way to let TLG devs know?
-
Don't worry. I can confirm that code looks exactly like yours.
-
At least the Control+ app updates the Firmware automatically once there is a new one available. I don't know if the Powered Up app does the same. So, since there was no notification for a new firmware, I assume it's up to date.
-
L and XL are working. App v3.6.0 (11883). Firmware of Technic Hub is up to date as far as i can tell.
-
I have the Boost Interactive Motor attached, But I have the C+ L and the C+ XL motor available too. Can quickly test now.
-
@Toastie, Thanks for the test. I cloned your code. I'm running the loop with 0s delay and just crossed 5500 cycles with the technic hub 88012-1. I don't have the hub 88009-1, so i can't test it. Which phone/tablet did you use? I tested it with a Nokia XZ2.
-
I agree. May be the BT connections unstable for whatever reason and cannot handle rapid flow of commands.