Hello
I purchased the ODrive v3.3 with accompanying N5065 270kv motor and rotary encoder.
I am attempting to deliver it usb velocity setpoint commands through a linux terminal I have set up in a Ubuntu VirtualBox VM. My host computer runs on Windows 7.
I am able to connect to the ODrive using usb. When I run the test_bulk.py script I do get the “ODrive BulkDevice Found!” response and the “Enter ODrive command:” prompt.
However, when I deliver it commands such as “v 0 1000 0”, there is no response from the motor. I have also tried “s 0 4 1000”, which also yields no response from the motor.
I have configured the parameters such as CPR and Pole Pairs in the low_level.c script. I have also changed the .control_mode to CTRL_MODE_VELOCITY_CONTROL. Besides that I have left the low_level.c script unchanged. Additionally, I have flashed the firmware to the ODrive succesfully.
Is there something obvious I am missing here? Should I be flashing the firmware after each time I send it a command such as “v 0 1000 0”? My impression was that I could send it a command like that or " s 0 4 1000" and see a response from the motor in real time. My intent is to deliver it a speed command that results in the motor spinning at the desired counts/s.
Please let me know any solutions
Will
Hi,
Great that you got everything flashing and communicating, and good to know that it works through VM.
It sounds to me like you have everything set up correctly, and indeed the response to the velocity command should be instant.
Some things to verify:
- Did you flash the “v3.3-pinout” branch, or master? It should be the former. (sorry, I will try to make this automatic as soon as I can)
- When you apply power or finish flashing, did the motor do the calibration routine (gets stiff, makes a beep, makes a small back/forth movement)?
Cheers!
Hello
Thank you for the quick response.
Yes it does do its calibration routine after each flash.
I have downloaded and flashed the ODriveFirmware-3.3-pinout, but still seem to be having the same problem. This time I have only edited the pole pairs parameter in the low_level.c file.
When running commands like “v 0 1000 0” there is no response from the motor.
Is there anything else that may be causing this?
Thanks again
Will
Can you check the motor error value? On M0 it’s “g 1 3”. You can decode the error code from the enum in low_level.h.
You can also check calibration_ok, which is “g 2 3”.
See if that helps. Supposing there is a motor error, you can search low_level.c for the corresponding enum value to see where it is set, and hence what is wrong. Of course you are very welcome to post what the error was here and I can give you some help too.
Cheers!
g 1 3 yields 0 which I believe corresponds to no error.
g 2 3 yields 1 which I believe corresponds to the calibration being successful.
Right now my test stand only has a mount for the motor, with the encoder attached to the motor’s rotor via the coupling with no additional support. So there is a possibility that the encoder casing itself is rotating a small amount. Could that be the issue?
Additionally, I am using a 18V 3A power supply. Should I change anything about the current limits in low_level.c, etc?
Let me know what you think
Thanks for your continued support
Will
Hm yes it’s possible that the encoder calibration has issues if the encoder is not secure. Of course the more secure it is the better, but there will be significant issues if it moves more than 30 degrees electrical (which is 4.3 degrees mechanical for a 7 pole pair machine).
I think your power supply is fine for getting started on, no high power moves of course, but completely okay to do some simple moves. I think the settings you enumerated should all be fine.
Feel free to email or DM me what times you are available on the weekend or next week to do a Skype call, and we can do a live support session. [EDIT]: I’m generally available 10 to 23 Pacific Time.
Thank you for the offer of a live support session. I will let you know if that’s the route I’d like to go.
I flashed the “sensorless-b4-v3.3” firmware branch and it does respond to usb velocity commands now, although it is a little inconsistent. Basically it sometimes does not go to the speed it is commanded or sometimes does not respond to commands.
It is working better now though. Is there a reason why it would run on the “sensorless-b4-v3.3” firmware but not on the others?
Thanks again for your help
Will
b4-v3.3 uses the pinouts from the boards pre-v3.3. It shouldn’t work with v3.3 as far as I know.
Thank you guys for your help.
Since setting up a new test stand and re-downloading and flashing the “v3.3-pinout” branch, it does respond nicely to usb velocity and position commands with the encoder connected.
However, without the encoder connected and using the “v3.3-pinout” firmware, it does not respond to usb velocity commands.
I tried the firmware branch labeled “sensorless” and it does respond to usb velocity commands without the encoder connected. Is this the sensorless firmware that is meant for the ODrive v3.3?
In general, is that how it is supposed to work? Run “v3.3-pinout” with the encoder and “sensorless” without the encoder? Or should it work without the encoder using the “v3.3-pinout” firmware branch?
Just curious at this point as the system seems to be working quite well now.
Thanks again
Will Whitesides
I tried the firmware branch labeled “sensorless” and it does respond to usb velocity commands without the encoder connected. Is this the sensorless firmware that is meant for the ODrive v3.3?
Yes
In general, is that how it is supposed to work? Run “v3.3-pinout” with the encoder and “sensorless” without the encoder? Or should it work without the encoder using the “v3.3-pinout” firmware branch?
The code is setup in such a way that you can run the sensorless branch in “encoder” control mode, or in “sensorless” control mode by switching the “control_mode” variable in the motor initialization struct. Using v3.3-pinout for encoder and sensorless for sensorless will also work if you prefer. I’ve been working on refactoring the code, and one of the things I want to do is to allow USB commanded switching of control modes, but it’s just not there yet.
Normal operation requires an encoder. So this is on purpose, it has detected an error: there is no encoder plugged in, and is refusing to operate. The error checking commands I presented earlier should return ERROR_ENCODER_RESPONSE (which is error code 7) in this case. If it’s still returning error 0 (aka no error, like before), then please let us know, as that would be a bug.
In sensorless mode you do not need an encoder, and hence there is no error if it’s not present (it’s not checked for at all). The sensorless mode is still out on the feature branch called “sensorless”, and has yet to be merged to master, and hence there is not much documentation on it yet. But when it does get merged in, we’ll make clear exactly how to chose between encoder mode or sensorless mode.
For now, yes check out “v3.3-pinout” effectively is encoder mode, and check out “sensorless” branch and you get sensorless mode. Again, in the future it will both be available, and a good way to chose.
I’m glad it’s working well! Let us know if you have any other issues. If all goes well, we’d love to see what you’ve made with your ODrive 
.