Good news, everyone! RazorsEdge (and RazorsFrozenTesting) branches have been merged to the main repository’s devel branch in preparation for firmware release. Anyone using a Razors branch, please switch to devel https://github.com/madcowswe/ODrive/tree/devel. If you have issues or PRs open that target devel, you will probably have to rebase them.
4 Likes
I’ve got a V3.5 48V odrive with a D5065 motor and an AS5047 encoder hooked up in ABI mode. Everything works fine when the board is flashed to the current head of master, but when I flash the board to the head of devel then nothing happens when I send the calibration command via the odrivetool (no beep, no motor movement, no errors). The board also always shows vbus_voltage to be 12v instead of the correct value. I can reflash the board back and forth from master and devel and get the same result each time (everything works fine in master, no movement from devel). Both the master and devel dfus were locally compiled on my machine and flashed via DfuSeDemo/usb. I’ve created a dump from the board on master and a dump from the board on devel. The only thing that jumps out is that none of the properties seem to be populated for the hardware (everything is set to default values) for the devel dump. The board seems to be communicating fine though because the configuration can be modified and saved properly. Any ideas what might be going on? I’ll start working backwards from the head of devel to see if there is a version that works, but I thought I’d see if anyone had any ideas before I go too far down the rabbit hole. Thanks!
After some debugging it looks like commit bd26cc9ef30a328685b445b623933fca4d08a40f “Merge pull request #408 from madcowswe/feature/uart_baudrate” that is causing the problem. Flashing the board to the devel branch at the commit just prior ( 7148de710abb5701dd2e24ca8e549121870fefa5) and everything works as expected. It is a rather large (merge pull #408) has 6 sub commits so it is tricky to see what is going on there. Looks like a lot of can bus code got added, but doesn’t show up nicely on the github diff view for some reason. Does anyone have any ideas?
After some more testing I realized that it was only the single axis V3.5 48V boards that weren’t working. I tried a dual axis V3.5 48V board and it worked fine with the head of devel. Something in the setup process has changed with bd26cc9ef30a328685b445b623933fca4d08a40f (aside from just breaking out the encoder initialization from the axis setup). The easiest work around I found was to add a new property to each axis called “use_axis” which can be used to skip the setup for a specific axis. When this is set to False for axis1 then the single axis boards work as expected on the head of devel. I’m not sure if this is the preferred approach or even if support for single axis boards is something that is desired (given that they are external), so I’ll refrain from submitting the “fix”. Just wanted to close the loop in case someone else runs into this.
Hi jdow,
because I am an old hardware gui I need some help from your side to run my 5047 Enconder using the SPI interface on my boad v3.6 / 56V .
- is there a possibility to get a compiled version (elf - file ) of this branch anywhere in Github ?
- or do I have to install the compile environment on my PC and try to do a compile ?
- or are there other ways ?
many thanks for your reply !
I’m having exact problem with devel branch on my custom board. ( even though I haven’t got the calibration process to work on master branch ) I would like to try the devel version, but got the same 12v and current sense not reading etc How and where did you add this new property as I will have to do the same. Here is the link to my issue Can't Calibrate Motor Custom Hardware
Maublas,
There are precompiled elf/hex files for the released versions here but nothing for development branches. That means that unfortunately you’ll have to go through the process of installing the tool chain checking out the code compiling locally and flashing. The guides aren’t bad but there are a lot of steps, just be patient and make sure everything installed correctly / system paths got added (windows).
I actually just got the 5047 working on the devel branch in SPI mode for the first time (had been using ABI mode for all the above posts) and was finally able to power cycle and go straight into AXIS_STATE_CLOSED_LOOP_CONTROL with no calibration! You’ll need to follow the encoder SPI instructions to get this to work. The only thing that I found to be wrong in the guide was that I had to connect MOSI on the encoder to MOSI on the odrive (not 3.3v as is stated in the guide). You’ll also need to tune the axis controller velocity gain (odrv0.axis0.controller.config.vel_gain) and the controller velocity limit (odrv0.axis0.controller.config.vel_limit) to avoid getting an ERROR_OVERSPEED controller error the first time you move the motor in closed loop control (due to the extra CPR of the 5047 in SPI mode). Experimentally I found that vel_gain = 0.00025 and vel_limit = 60000 worked decently.
Matt303,
The quickest way to get it working is to comment out lines 245 through 252 (initialization code) in Firmware/MotorControl/main.cpp and after it put the following 2 lines
axes[0]->setup();
axes[0]->encoder_.setup();
This only initializes axis 0 (M0), and you should be good to go.
I had initially tried changing AXIS_COUNT in odrive_main.h to 1, but there are a bunch of places in the code where the second axis is accessed without checking the AXIS_COUNT. Even after fixing these there was some dodgy stuff happening between the two axis timers in the pwm_trig_adc_cb method in low_level.cc that I didn’t want to try and sort out. So the simple solution seems to be to just not run the setup code for the second axis.
Adding the property is something that makes the work around nice because it can be controlled via the configuration, but isn’t necessary. I’ll submit this as a change if the ODrive guys are interested.
1 Like
jdow,
thanks for your hints - with your proposed change concerning the axis I tried to compile the firmware - the process did not stop with an error and reached the end. A problem with the version.h file was showed - but I think this should not be important?
Running the software on target the Encoder Calibration process did not start at all and failed. Wheras the “Full Calibration prcess” started and failed because of no reponse of the encoder. -
No active signals on the SPI lines could be measured in any state.
Because the SPI interface is running stable on your side I want to ask you to make a reference compile (hex) for my
Odrive version 3.6 - 56V
Thank you
Okay I made you a hex file for your config from devel. If your SPI isn’t working I’d also recommend checking that your config for that axis is set properly :
odrv0.axis0.encoder.config.mode=257
odrv0.axis0.encoder.config.cpr = 16384
odrv0.axis0.encoder.config.abs_spi_cs_gpio_pin = 4 (or whatever pin you’re using … should be 3 or 4)
Check that MOSI on the encoder is connected to MOSI on the odrive (not 3.3v as listed in the instructions)
Make sure you changed the AS5047 to use 3.3v instead of 5v (this requires resoldering the evaluation board … need to unsolder resistor and move to 3.3v pad as well as moving the jumper. This is detailed in the board manual)
1 Like
jdow
your support helped me a lot - many thanks - compiling and also running the SPI interface is now working as described.
But the last step - running the “closed loop” always fails - I tried to change the parameter vel_limit (6000-300000) and vel_gain(0.00025-0.004) but I did not work
My setup:
One motor (eX8108-105kV with 21 pole pairs) and the two interfaces of the 5047 are wired to the ODrive. Running the firmware version 3.6 works fine, e.g. closed loop and move to position.
Using the the devel branch compile in incremental mode it is possible to go into closed loop - but if you touch the rotor or do a pos_setpoint command it will instantly crash with the overspeed error.
Do you have an idea what parameters should be changed? Could it be a problem with the new firmware? There are a couple of new parameters in the devel branch-?
thanks in advance
Did you have any errors after the full calibration step before you requested closed loop control? You could try turning up the vel_limit even higher or turning off the overspeed error for the axis0 controller :
odrv0.axis0.controller.config.enable_overspeed_error = False
That being said I’d guess that this is a symptom and not the problem. Once you’ve done the calibration are you able to manually rotate the motor and see the shadow count value (odrv0.axis0.encoder.shadow_count) change? If not then there is a problem with the encoder. Do you have a second as5047 encoder to try? Maybe try another odrive board?
jodow, Thanks for your advise
the problem can be solved by setting odrv0.axis0.controller.config.enable_overspeed_error = False
What do you think about the influence of the this setting - concerning the stability of the controller ?
Maublas, great to hear that fixed it! I don’t have a lot of experience tuning the controller so I’ll leave your question to someone more qualified. That being said I’d assume that it isn’t a great idea to turn this check off in the general case. I also only had this issue on initial startup of the motor, so it could be related to the initial setpoint for the motor. Perhaps you could try adjusting the setpoint to match the position of the motor read from the encoder before reqesting closed loop control to avoid the initial high speed movement.