Lego GBC and Mindstorms EV3

[Hanso]

I am planning to create new GBC modules in the coming years. It will be a combination of Lego Mindstorms and Lego Technic. So not mindblowing mechanical constructions like Akiyuki, but constructions that can only work because they are controlled by the intelligent Mindstorms brick.

 

My first module that I am trying to build (still unsure if I can make it work), is based on the Planar Parallel Mechanism that I saw on Youtube:

I find it really cool how it moves. And I thought: let's build this, and use the grabber (visible from time frame 1:23) to pick up balls at the left side of the GBC module and bring them to the right side.

 

Here is an LDD sketch from the first prototype:

 

And a small movie of the first test.

 

The green markers are there, to put the prototype in the start position. That's my major issue right now: how do I now where the four legs of the mechanism are?

Working on that now, will keep you posted.

 

Suggestions and compliments are welcome ;-).

 

Regards, Hans aka Mindstorms GBC

 

Edited December 16, 2019 by Hanso

[msk6003]

Wow.... incredible mechanism...

But one claw is to slow for most GBC rayout. I think you need replace claw to some bucket-kind thing.

[Hanso]

22 hours ago, msk6003 said:

Wow.... incredible mechanism...

But one claw is to slow for most GBC rayout. I think you need replace claw to some bucket-kind thing.

Thanks for the compliment. And yes, I am aware of the speed. But first I want the mechanism to work, before I increase the speed. Thinking of a bigger claw as well. But first things first ...

Hans

[Toastie]

On 12/15/2019 at 6:08 PM, Hanso said:

That's my major issue right now: how do I now where the four legs of the mechanism are?

Very nice and very interesting approach! This will look extremely nice on any GBC layout. Fantastic.

With regard to the leg position: When everything is rigidly coupled, don't these motors have internal rotation sensors? Leg position and rotation count should correlate or are the errors due to mechanical tolerances too large?

Again: Very nice!

All the best
Thorsten 

[Hanso]

On 12/19/2019 at 8:53 AM, Toastie said:

Very nice and very interesting approach! This will look extremely nice on any GBC layout. Fantastic.

Thanks!

On 12/19/2019 at 8:53 AM, Toastie said:

With regard to the leg position: When everything is rigidly coupled, don't these motors have internal rotation sensors? Leg position and rotation count should correlate or are the errors due to mechanical tolerances too large?

Yes, there is a direct correlation between motor position and leg position. But where are the legs at startup ...? That is the problem that I have.

Have some ideas worked out with a very smart colleague of mine, trying to get it to work in the coming holidays.

Regards, Hans

[Toastie]

13 hours ago, Hanso said:

But where are the legs at startup ...? That is the problem that I have.

Dear Hans,

I faced a remotely similar problem with my switch drive controllers: https://www.eurobricks.com/forum/index.php?/forums/topic/154740-moc-lego-switch-drive-controller/

What I did was to drive the trolley to an end-stop (touch sensor = zero position) and then a little away from it (so it is not closed anymore). In your case you would need four sensors, right? I would use RCX type touch sensors all in parallel (simply stacking the 9V 2x2 electrical contacts and then use a 9V -> NXT conversion cable (provided the NXT cables are compatible with EV3 terminals). You would need to initialize each motor individually (to free each time the corresponding sensor). But you would need only one sensor input. With an NXT this should work, I believe.

All the best,
Thorsten 

[Hanso]

On 12/21/2019 at 10:35 PM, Toastie said:

Dear Hans,

I faced a remotely similar problem with my switch drive controllers: https://www.eurobricks.com/forum/index.php?/forums/topic/154740-moc-lego-switch-drive-controller/

What I did was to drive the trolley to an end-stop (touch sensor = zero position) and then a little away from it (so it is not closed anymore). In your case you would need four sensors, right? I would use RCX type touch sensors all in parallel (simply stacking the 9V 2x2 electrical contacts and then use a 9V -> NXT conversion cable (provided the NXT cables are compatible with EV3 terminals). You would need to initialize each motor individually (to free each time the corresponding sensor). But you would need only one sensor input. With an NXT this should work, I believe.

All the best,
Thorsten 

Thanks for the interesting tip. But I think I don't understand it completely. If I am correct, I still don't know where the legs are at startup. And therefore, I don't know which movement I can make.

[Toastie]

As far as I understand the mechanism, it has one possible "defined startup configuration": Led 1 ... 4 can move to a certain point, defined as zero, is that correct? It could be any extreme position you'll not reach during normal operation. I would move one leg after the other to this position, which is recognized by the touch sensor being pressed. For each leg this is either to the left or to the right. So upon startup move the leg - regardless where it is - first to its initial zero position. Now you know where it is and you can take care of things to come next.

Best
Thorsten 

[Hanso]

On 12/26/2019 at 1:08 AM, Toastie said:

As far as I understand the mechanism, it has one possible "defined startup configuration": Led 1 ... 4 can move to a certain point, defined as zero, is that correct? It could be any extreme position you'll not reach during normal operation. I would move one leg after the other to this position, which is recognized by the touch sensor being pressed. For each leg this is either to the left or to the right. So upon startup move the leg - regardless where it is - first to its initial zero position. Now you know where it is and you can take care of things to come next.

Best
Thorsten 

Hi Thorsten,

You cannot just move one leg without forcing the structure. You will always have to move two legs at least, otherwise one of the other legs will be lifted (and thus breaking the structure). If I could move only one leg at a time, it would be easy to determine its position.

 

But I do have a theory that could work, so please continue reading.

 

I have made a second prototype, as you can see on the LDD renders (more pictures here):

 

How to determine the leg position at startup? Well, here is the idea (assuming that the motor position is directly related to the position of that leg):

\

[1] Startup position. No idea where the legs are ...

[2] Move the four legs in parallel to the left. One sensor will fire at a certain point. In this example, sensor 1 is triggered. So now we now the (zero) position of leg 1. But we also know, that leg 3 didn't fire earlier and therefore is 'behind' leg 1.

[3] Now move all four legs to the other side, sensor 2 is now triggered. So I know now the position of leg 1 (by the number of rotations of motor 1) and of leg 2 (zero position). And that leg 3 is 'behind' leg 1 and that leg 4 is 'behind' leg 2.

[4] Now I move the positions of the legs, by rotating the grabber. I know I can do this, because I know that leg 3 and 4 are 'behind' leg 1 and  2.

[5] and [6] I can repeat now step 2 and 3 to determine the position of leg 3 and leg 4.

I need to program this and see if the practice follows the above theory.

 

Will keep you posted.

Regards, Hans

Edited December 27, 2019 by Hanso

[Toastie]

4 hours ago, Hanso said:

You cannot just move one leg without forcing the structure

Dear Hans,

sorry, I missed that. Indeed, this renders everything much more difficult. I need to think about it - this is fun!

One thing you may want to take into consideration (but this is not thought out at all!): I would move the touch sensors in parallel to the moving legs, so that the leg will close the sensor when it moves by, but it can pass it freely. I did that in my setup as well - this gives you more freedom. Also in programming as the mechanism has not to stop immediately when the sensor fires (provided you want to avoid stressing the mechanism. On the other hand, you are using an EV3 - that brick is fast enough I believe to prevent that).

But more so, this allows you to position the "position sensors" anywhere on the rails = known location. When you make the rails a little longer on both sides, then moving all four legs into one direction (= "end-point" sensor 1 fires) should either fire none or some or all of the "position sensors" - then going all the way back to the other end position should fire the remaining "position sensor(s)". This requires 5 input ports though: 1 for the two "end-point" sensors hooked up in parallel (as you know where you are going on startup, when moving to the left only the left "end-position" sensor can fire) and 4 inputs for the position sensors. You could code the touch sensors using resistors but that is not a purist option ... there were resistor coded RCX touch sensors though.

This would require much less programming, as you just have to a) detect the end point position and b) read the motor position upon each sensor event.

Well, as said, this is not thought-out ...

Best
Thorsten 

Edit: There is another option: When you use the "end-point" sensors resistor coded (lets say 1kOhm each), you could use both "end-point" plus one "position" sensor on one port in parallel. 

Edited December 27, 2019 by Toastie
Think twice before you write ...

[Hanso]

While programming the startup procedure, I found out that there was too much slack in the drive mechanism. This is due to the 6542b gear; the gear has almost 90 degrees of free rotation within the 6539 driving ring.

(6542b gear)

(6539 driving ring)

This free movement of the gears, resulted in a free movement of +/- 2 centimeters of the chain belt. And that applies for each leg, so sometimes when I moved legs 1 and 2 to a more outer position, the triangle kind of collapsed.

 

So I made another drive, that has still the possibility to easily disconnect the motor from the chain belt in order to move it by hand while programming and testing. This is the new solution, it has almost no slack:

Connected state

Disconnected state

When I finish programming, I will give an new update including a video.

 

-- Hans

Edited January 2, 2020 by Hanso

[Hanso]

Working on a GBC layout, with all kinds of builds that are controlled by Lego Mindstorms. This is the first part, the Mindstorms GBC Circles. In the video you see the work in progress, don't have enough bricks to finish the build :-). Waiting now for my BL order.

Some more Stud.io renders on my Flickr page (click on the photo below):

Edited February 18, 2020 by Hanso

[Hanso]

Of course, the balls need to be transported to the dispenser. In the video below, you'll find the work in progress of the 'hit and run' module.

 

Edited February 19, 2020 by Hanso

[Hanso]

Improved version of the "Hit and Run" GBC module.

 

Edited February 24, 2020 by Hanso

[Hanso]

The Lego Mindstorms GBC module "Circles" is now finished, as you can see on the video. I am using two EV3 M motors and two EV3 Touch sensors for this module. One motor is used for rotating the buckets, the sensor checks if 1/16 of the circle is made.

The second motor/sensor is used for the ball loading, you can see how it works at the beginning of the video (time frame 0:12 - 0:25).

The module is now working standalone, still needs to be placed in a larger setting including the "Hit and Run" module.

 

Please let me know what you think and/or like the video.

Hans

Edited March 13, 2020 by Hanso

[Hanso]

The "Hit and Run" module, upgraded to 4 studs wide. Now able to handle 2 balls per 4 seconds, so 1/2 of the required speed. Will make a second version in the future when I build a closed GBC loop.

Enjoy, Hans

 

Edited March 15, 2020 by Hanso

[Hanso]

Read my last post regarding my GBC layout here:

 

Edited March 18, 2020 by Hanso