Detecting colors and signal duration. Is it possible?

[Bentz32]

We also stumbled upon issues regarding the sorting arm and the move motor subVI...

The distance moved when processing 2 of 2x2 yellow bricks, differs... The first one moves the correct distance, whilst the other moves slightly less... As far as i can see, there's nothing in the code doing this... I think it must be the limitations of the lego motors (or poor design 😞 )...

But if you have time, could you see if there is anything in the code that may cause this irregularity? It's really frustrating....

Thanks 🙂

[Albert.Geven]

Hi

about the position accuracy, not too high speed to prevent slipping

and always move back a bit further so you can approach the start position from the same direction.

Attached an untested program that when pushed on the out button should remove one block only

pressing stop somewhere on the screen will stop everything.

[Albert.Geven]

I leave the update to you , look at position control!

[Bentz32]

Thank you! Will check it out! 

[Bentz32]

Hi Albert

We're nearly there! Program can now pull out one at a time! Still got a problem with irregularities in the sorting arm (move motor VI) though.... let me explain:

I'll leave you the VI we use now for moving the arm...
We want the motor(Arm) to run the distance relative to the position from the table and then immediately stop in the correct position... since gravity is pulling on the arm, a slight drop before braking occurs when using the wait for (seconds) function... this creates irregularities because the drop is different almost every time... just a tiny bit, but enough to compromise the whole sorting process...

Ive been trying to replace the wait for(seconds) with "wait for rotation" (these are mindstorms features) and connect the position to it's input... however, I think the "wait for rotation" has another unit than the relative to position motor function that we use.... I've been thinking that some kind of conversion of the position is needed before connecting to the "wait for rotation"... its unit is degrees, whilst the position is encoder counts or something...

Maybe you can help us with the conversion or perhaps you have a better solution for fixing this...

Motor has to stop immediately when reaching the relative distance...every time, no exceptions... we can afford probably around 5mm of irregularity, backlash

Appreciate all the great work! Sincerely, thank you!

[Albert.Geven]

Hi

Maybe you should have a check in the subvi where you are monitoring the position.

And I believe that it is possible to steer the motion to a position instead of just using time.

Why not control that directly.

I have not programmed the latest EV3 so I can be mistaken, but in the first mindstorm set I have used it for sure.

[Bentz32]

I've tried using this as a substitute for wait for seconds/milis... In lightbulbmode, the whole process stops when reaching this... It won't proceed through to the brake function. I've tried adding several different constants just to make it pass through to brake, but systems stops there no matter what... 

It doesnt make any sence that the system wont go past this function.... Any ideas? 

[Albert.Geven]

Is the port not obliged to connect?

And do you have the correct spin/motor

[Bentz32]

I use the large lego motor, looks like the one in the "wait for rotation" icon... I've tried connecting it to the right port and everything... It just wont complete in lightbulbmode... Will not go past

[Albert.Geven]

Hi

You can doubleclick on that vi and look inside to see what happens.

I would make a small test program to see what you need to connect and how fast it responds.

Use the built in debug (press the lightbulb on top of a block diagram and see what slowly happens.

It reads the position and maybe you can do that in your own test?

It also waits 10 ms maybe too long for you anyway.