Forum Replies Created
-
AuthorPosts
-
Anders SøborgKeymasterHi there
I just tried you program, and it turns out that what you have observed
…If I turn the engine with my hand a little bit the program continues…
is in fact a error in the firmware that happens when you move a very small amount and the program has not been AOT compiled. I already fixed it and will create a new release tomorrow. A temporary workaround is to make the motor move a big step the first time you create a profile. I modified your program so it looks like this.
using System; using System.Threading; using MonoBrickFirmware; using MonoBrickFirmware.Movement; using MonoBrickFirmware.Display; using MonoBrickFirmware.UserInput; namespace MoveMotorA90 { class Program { static void Main(string[] args) { Motor motorA = new Motor(MotorPort.OutA); ManualResetEvent stop = new ManualResetEvent(false); bool run = true; WaitHandle motorWaitHandle; ButtonEvents press = new ButtonEvents(); press.EnterPressed += delegate { stop.Set(); run = false; }; motorA.SpeedProfile(30, 300, 300, 300, true).WaitOne(); motorA.ResetTacho(); while(run) { LcdConsole.WriteLine("Position A: " + motorA.GetTachoCount()); motorWaitHandle = motorA.SpeedProfile(30, 15, 15, 15, true); WaitHandle.WaitAny(new WaitHandle[]{motorWaitHandle, stop}); } motorA.Off(); LcdConsole.WriteLine("Position A: " + motorA.GetTachoCount()); } } }
Let me know how it goes…
/Anders
Anders SøborgKeymasterHi there
Sorry I did not answer your second question.
I also tried to delete the time to wait, but the Brick still does wait for about 4-6s. Why is it doing that?
The program need to JIT compile each function call (only the first time they are called). That is simply the nature of running on the .NET framework, but on a small processor like the one in the LEGO brick this can sometime takes a little bit longer than expected. On a PC you do not notice it while on the LEGO brick you will… One way to avoid this is to AOT (Ahead Of Time) compile the program (using the menu) from the program menu on the firmware. Another way is to call the function that take a long time to execute once to make the program JIT compile it – this way it executes fine the next time.
/Anders
Anders SøborgKeymasterHi there
Great project that you are working on. I moved your topic to the right forum. Anyway to answer your questions
Sometimes the engine does not even the first 90°, it stops at 89° but the program waits for the 90°.
Your program does not use the waithandle that is returned from the speedprofile function. The execution continues but you wait 1000 ms. Please have a look at the motor example found here
/Anders
Anders SøborgKeymasterDid you build the application for 32-bit or 64-bit?
/Anders
Anders SøborgKeymasterWhat system are you on?
/Anders
Anders SøborgKeymasterIt seems strange that you are able to have it working with the NXT but not the EV3 – I mean it uses the same USB connection. Have you tried to single step through the program?
/Anders
Anders SøborgKeymasterHi
Please post the complete code as it is important to know what namespaces you use. It makes a big difference whether you use the NXT or EV3 brick class…
Anders
Anders SøborgKeymasterHi there
Did you try to use WPA2 – as I remember it should be backwards compatible…
/Anders
Anders SøborgKeymasterHi there
Please post your code otherwise it is hard to help
/Anders
November 19, 2014 at 21:30 in reply to: Mindsensors' GlideWheel sensor (and possibly other sensors from MS) doesn't work #4989
Anders SøborgKeymasterHi Andreas
Great I will have a look at it when I get the time…
Anders
Anders SøborgKeymasterHi Jacek
Yes it is possible but I never got around to implementing it. As I remember one of the Unix-Devices (probably the /dev/lms_dcm device) in the sensorManager has access to info about the brick…. you are more than welcome to have a look at it if you are up for it…
/Anders
Anders SøborgKeymasterHi there
Amazing – could you please add a pull request (so you can get credit) so this can be part of the next release. Thanks
/Anders
Anders SøborgKeymasterHi
I will have a look at the raw data from the sensor to see if it has RGB values (to be honest I can’t remember if this is the case), but as you already point out it might not be available since our image is based on an older version of the LeJos image. But do you actually need the RGB values? the raw value should be good enough. You can see more here
/Anders
Anders SøborgKeymasterHi Hasan
I am no expert in F# – but try to share some code then maybe others might be able to help.
/Anders
November 10, 2014 at 22:10 in reply to: Mindsensors' GlideWheel sensor (and possibly other sensors from MS) doesn't work #4974
Anders SøborgKeymasterHi there
Great. Now remember to add your code to the Github using a pull request..
Anders
-
AuthorPosts
Follow