Home→Forums→MonoBrick EV3 Firmware→Motor.On: strange behaviour
- This topic has 10 replies, 3 voices, and was last updated 8 years, 10 months ago by Henrik Kurka.
May 4, 2014 at 10:48 #4241
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.On (30, 30, true, true);
=> 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.
MikhailMay 6, 2014 at 14:15 #4250
I will have a look at it tonight
AndersMay 6, 2014 at 15:45 #4251
Thank you very much, I am looking forward to your reply.
MikhailMay 7, 2014 at 22:10 #4262
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.
MikhailMay 8, 2014 at 18:12 #4267
I will have a look tonight – but as I have said in other posts. The interface for the motor will change in the future…
AndersMay 10, 2014 at 19:41 #4292
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.
AndersMay 12, 2014 at 20:32 #4321
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?May 13, 2014 at 14:45 #4325
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
AndersMay 13, 2014 at 19:02 #4336
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!May 14, 2014 at 20:26 #4344
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.May 14, 2014 at 20:43 #4345
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 🙂
You must be logged in to reply to this topic.