Motor.On: strange behaviour

[Mikhail Glukhov]

Hello,

First of all, thank you very much for creating MonoBrick and allowing us to write programs for the EV3 using my favourite C# language.

I have come across a simple problem. here is the code:

public void RotateMotorBy30Degrees ()
{
Motor m = new Motor (MotorPort.OutA);
m.ResetTacho ();
m.On (30, 30, true, true);
m.Off ();
}

=> What I expect from the motor to do: simply to turn by 30 degrees.

=> What I get: if before running the program I manually turn the motor to a certain position, and then run the program, the motor behaves like that” first, it makes a fast movement to a certain “initial” position, and after that it executes the program and turns by 30 degrees.

This behaviour is strange, since I call the ResetTacho function.

Would very much appreciate your help.

Regards,
Mikhail

[Anders Søborg]

Hi

I will have a look at it tonight

Anders

[Mikhail Glukhov]

Hi Anders,

Thank you very much, I am looking forward to your reply.

Regards,
Mikhail

[Mikhail Glukhov]

Hi Anders,

Have you had the time to have a look at this bug?

It seems strange that such basic operations with the motor don’t work as expected. Or maybe I am doing something wrong.

Regards,
Mikhail

[Anders Søborg]

I will have a look tonight – but as I have said in other posts. The interface for the motor will change in the future…

Anders

[Anders Søborg]

Hi

I just realised that this function will be removed for the next release. Instead our own PID will be used- I will keep you posted. In the meantime I think workaround is to place On(0) before you start moving the motor.

Anders

[Henrik Kurka]

Hi Anders. I have just started to do some test-coding trying to learn both C# and Monobrick at the same time 🙂

Am I correct to understand that I should not use On() anymore, but use Move or MoveTo instead?

[Anders Søborg]

Hi Henrik

I think that you sould forget about the On() will be replace by one function call SetSpeed. MovTo will be replaced by our own PID controller (which can be tuned for depending on the load you have on the motors).

For motor position you should stick to the SpeedProfileStep function. Hope this makes sense

Anders

[Henrik Kurka]

Yes, that makes sense. I’ll check out the SpeedProfileStep function.

By the way – how are updates communicated? It seems the blog hasn’t been updated for a while.

Takk for hjelpen!

[Henrik Kurka]

One follow up question. I don’t think I understand the Steps-parameters in SpeedProfileStep and the Tacho count.

I just executed the following:

			Bakmotor.ResetTacho ();
			Bakmotor.SpeedProfileStep (50, 100, 300, 100, true, true);
			LcdConsole.WriteLine("SpeedProfileStep (1), Taco: " + Bakmotor.GetTachoCount());
			LcdConsole.WriteLine ("Ultrasonic: " + usSensor.ReadAsString ());

			Bakmotor.SpeedProfileStep (-50, 10, 30, 10, true, true);
			LcdConsole.WriteLine("SpeedProfileStep (2), Taco: " + Bakmotor.GetTachoCount());
			LcdConsole.WriteLine ("Ultrasonic: " + usSensor.ReadAsString ());

The output is something like:
peedProfileStep (1), Taco: 1
Ultrasonic: 361 cm
peedProfileStep (2), Taco: 4
Ultrasonic: 1111 cm

It seems both the GetTachoCount and the ultrasonic sensor reading are wrong. How can the tacho count be 1 after the first run and 4 after the second run backwards?

I think I need an explanation on what exactly the tach count is (is it degrees?) and what the Steps parameters are. Are they also degrees?

Also note that the output from the ultrasonic sensor seems to be different for every run.

[Henrik Kurka]

I think I just found the answers to my previous question. I just found that the output of the display tricked me as the last two digits of the tacho count were clipped. So I think it’s safe to say that the tacho-count shows the number of steps which is the same as degrees.

About the Ultrasonic-output, I think the explanation is as simple as there is a comma missing. It should be 36,1 and 111,1 cm 🙂

[Author]

Posts