ord

@Jonas thanks! Correct, just a standard cylinder.

Here is my latest MOC; a 3DOF cartesian parallel robot with suction gripper. It is capable of lifting small parts within a work envelope of 7x7x5 studs.

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:

@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.

Thank you . I don't see why it couldn't be stacked (to make a 0-99 counter, if that's what you mean). That would actually be pretty cool; it would just require a mechanism that steps every 10th rotation and can handle a reasonable amount of torque.

Version 2: I'd like to present version 2 of this MOC. Taking inspiration from aeh5040's seven-segment display, this version features: Control by a single shaft/motor Number incrementing and decrementing Faster response time than version 1 Unfortunately, mostly due to the goal of having only one input, this version doesn't feature a 'minus sign' segment.

Perhaps you could deduce more accurate angles from the accelerations in x/y/z.

From my experience with a similar project but with an Android device: - As @David Lechner said; long, smooth accelerations work best. - Even with long, smooth acceleration, data inaccuracy will build up quickly. You will likely want to record the data at a high sample rate but whatever rate you choose, that will be the rate at which inaccuracies accumulate. These inaccuracies might come from rounding or from the sensor itself. - It is impossible for the device/hub to know when it has come to a standstill without some outside input (a constant velocity is the same as a a standstill in terms of acceleration). Because of the previous point, when returning to a standstill from movement it is highly likely that your calculations will show that the device is still moving and hence your distance measurement will drift. This drift will also occur during movement. - Treating velocities of say -0.1 to 0.1m/s as 0 did help prevent drift at standstills for me but introduced other obvious problems. Good luck!

This is great news - if I understand correctly, 2 stud wide chain drives will now be possible with these sprockets (down from the previous 5 studs)

I admit, there is something nice about having the axes in the same plane. If you were to control it with linear actuators you could do away with the lower turntables and have it mounted on pins, I think, to streamline it a bit. I wonder how luffing is driven in the actual machine...

You could mount the boom axis above the luffing axis (rather than on the same plane)? This looks like how it's done in the Gradall excavator photo you attached. This could also lend itself well to controlling luffing by linear actuators, if you want to go down that path. Great project btw - it has a lot of similarities with an industrial robot arm. Well, I guess it kind of is a robot arm... on tracks

Nice robot arm! I'm working on one myself so will be following this thread. I haven't done it before but was considering using the Robotics toolbox for Matlab to simulate the arm and get joint coordinates to plug into python. Any idea how you might approach it?

I imagine the notches are there to allow the inner core to slide out during molding.

Here are some pics of the mechanisms. It is really quite simple: blue cams are horizontal segments and red cams are vertical segments. The segments fall back due to gravity The code is the complicated part (screenshot here). Basically: The first loop returns the tilt angle as an integer between -9 and 9 (and its modulus for simpler coding later on) The second loop rotates the motors (in parallel) every time this value changes. Motor positions are determined by... The next four loops. They constantly determine which segments should be on or off, depending on the integer(s) returned in the first loop

Version 1: Since the release of the Powered Up Technic Hub, I've wanted to experiment with its internal tilt sensor(s). This is the result; a mechanical seven-segment display that shows the pitch of an 'aircraft' accurate to 10 degrees. It works by having 4 motors each controlling 2 segments of the display (8 moving segments total) via cams. Each motor moves to one of 4 positions, putting its respective segments to OFF-OFF, ON-OFF, OFF-ON or ON-ON. It's not as responsive as I had hoped but was a fun little build Version 2: (See post below for more information)

Thanks for the explanation @Thierry-GearsManiac - a truly unique concept P.S. That linear drive by Yoshihito ISOGAWA is great

Fascinating. Can you define what the output dial actually reads (in your initial model)? i.e. it is the average flowrate of the balls but across what period? For example, a real life situation might be: 10 balls, 10 no balls, 10 balls, 10 no balls... In this situation will the dial tend towards 100%, 0%, 100%, 0% or hover closer to 50%. Is changing the period simply a matter of adjusting the speed of the cvt?

Thank you very much. Great work

@kbalage I experience that when controlling the motor directly with the slider but with a variable in between, as above, it seems less pronounced and can even stabalise. Still, it is far from usable.

Thank you all for the kind words. It should be noted that the steering requires a ~0.2 second delay to function properly is buggy in this version of the app (3.0.0), making it impractical to operate. Hopefully something that gets fixed in a future update.

Using the controller GUI in the Powered Up app, it is possible to remote control a vehicle with electronic differential. w = wheelbase t = track v = velocity (of virtual motor in centre of vehicle) a = steering angle (+/- 30°) r = turning radius A = steering motor C = left drive motor D = right drive motor The theory: https://www.researchgate.net/publication/224184352_Ackermann_mobile_robot_chassis_with_independent_rear_wheel_drives

Here's an idea I had for a live axle with sprung linkarms, to soften front/rear collisions. Top shaft is steering, bottom shaft is drive