Trying to setup PWM with this firmware but:
odrv0.config.gpio4_pwm_mapping.endpoint = odrv0.axis0.controller._remote_attributes['pos_setpoint']
does not work as “endpoint” has been removed!
vel_setpoint and pos_setpoint cannot be set. They produce errors.
Hope someone can help
Many thanks in advance
Mr Anders W
Sweden
I don’t think ‘endpoint’ has been removed, but you should be using ‘input_pos’ instead of ‘pos_setpoint’.
This is to allow things like input filtering and the new trajectory planner to work. If controller.config.input_mode is set to INPUT_MODE_PASSTHROUGH then it sets pos_setpoint immediately.
Thanks
“endpoint” is missing here but I’ll test what you have write
In [125]: odrv0.config.gpio1_pwm_mapping
Out[125]:
min = 0.0 (float)
max = 0.0 (float)
It is a lot to chance i doc.
Thanks
Anders
NameError Traceback (most recent call last)
C:\ProgramData\Anaconda3\lib\site-packages\fibre\shell.py in ()
----> 1 odrv0.axis0.controller.config.input_mode = INPUT_MODE_PASSTHROUGH
NameError: name ‘INPUT_MODE_PASSTHROUGH’ is not defined
You need to use the odrivetool for rc-v0.5.1 to use the enumerations, sorry. That value works out to “1” though if you just want it to run
Thanks!
What I do not understand is how to connect one PWM (3) to motor 1 and another PWM (4) to motor 2.
Please fix ODrive/issues/478
Thank you!
Thanks for new firmware!
I want to mention that change in controller gains lead to very jerky hoverboard motor behavior.
So can you provide some hints on achieving proper motor behavior?
rc4 is available. Fixes sensorless mode and a potential risk of damage for the brake resistor.
rc5 is available with a fix for unintended acceleration in sensorless mode when using INPUT_MODE_VEL_RAMP
Dudes, what have you done to the firmware?
Is there any changes to the controllers? I can now run much slower and smoother in position mode than before. Very nice!
One comment; if I auto-format ascii_protocol.cpp the compilation fails as when including “odrive_main.h” it has to be above “autogen/type_info.hpp”. I spent hours figuring out why it failed (yes, i have made a few modifications to the code which i thought was the problem).
Maybe VScode can be configured not to mess around with the includes, but i added a comment on the line above “autogen/type_infor.hpp” in order to keep it below the rest:
#include “odrive_main.h”
#include “communication.h”
#include “ascii_protocol.hpp”
#include <utils.hpp>
#include <fibre/cpp_utils.hpp>
// commet to keep order correct…
#include “autogen/type_info.hpp”
#include "communication/interface_can.hpp"s
Great work on the new firmware! I love it.
Yeah, check out the .clang-format file. I think there’s some switch for includes that you can modify.
The following changes are not present in the CHANGELOG file. This is already being reviewed in the Update CHANGELOG to mentiond gain unit changes #497 Github issue. add motor.config.torque_lim is also missing from the CHANGELOG I believe.
Also this link to the chagelog file is broken.
So, for sure not an expert here, but I was able to use the RC PWM as per the hoverboard instruction page, and I cannot get it to work with new update. Is this something that is known, or am I doing something wrong. Tried the following…
SyntaxEditor Code Snippet
Done it with -2, 2, and with -200, 200 (with new rotations/sec instead of counts/sec) - it just doesn’t change the velocity setpoint. Before updating used with same configuration and it worked.
Ideas?
unless something actively changes input_vel, pwm_mapping.min and max (I think) are not going to be able to evaluate the setting and therefore, can’t apply limits. Now if your PWM controller is on and you’re jiggling the inputs, then I’d assume they would get evaluated and constrained. This could be an order of operations thing or I could just be totally wrong and this is a bug, but it works for me
Yea, I had the PWM source on (RC controller) but still no luck. I have tested it with a hobby servo, and it is working as expected, so I am confident it is creating the correct signal, just not being read in by the Odrive.
My fear is there is a disconnect between the Odrive firmware and the odrivetool I am using to drive it with. I believe I am using the most current version of both, but it is possible I messed up somewhere along the way.
Buzzy, is this working for you with the most current version of everything?
Again, thank you in advance to anyone for your help.
Correct, 5.1 and latest odrivetool, but it looks like my version is showing up as not released. I am also having trouble with axis1, but I think it’s unrelated (encoder problems). What versions are you running?
In [3]: odrv0
Out[3]:
vbus_voltage = 31.992919921875 (float)
ibus = 0.00021862855646759272 (float)
ibus_report_filter_k = 1.0 (float)
serial_number = 20703892304E (int)
hw_version_major = 3 (int)
hw_version_minor = 6 (int)
hw_version_variant = 56 (int)
fw_version_major = 0 (int)
fw_version_minor = 5 (int)
fw_version_revision = 1 (int)
fw_version_unreleased = 1 (int)
The unreleased was my mistake, I built from one commit past the tag. You can ignore it.
