I"m having trouble finding a definite source for all the available commands that I can use with the native command set over Python.
There is this page https://github.com/madcowswe/ODrive/blob/master/docs/commands.md but it does not seem to have all the functionality listed. F.e. get_adc_voltage seems to exist according to the demo script but is not listed in that document.
Is there a complete API overview somewhere that I have missed?
I also asked this question over a week ago and also got ignored.
I can only assume that complete documentation doesn’t exist… 
Look at this thread. Although there is not a list (yet), you can get all the settings by typing odrv0.axis0.
Also, it is not done, but check out the odrive ui tool that is being worked on in the thread below.
tinker is doing a tree like dynamic ui that will be pretty neat and intuitive to check and modify settings.
wayneStock
This is awesome! Thanks for your work thus far. I’d be looking into the potential of using this with my single-axis iteration.
I tried getting it to work using the advice provided by the previous comments but am getting this error. If anybody has any advice on how to fix this, that’d be awesome. (I’m on Windows 7, 64 bit).
Hi,
For errors with UI tool probably would be best to post in the UI tool thread.
The error occurs because the UI tool is calling attribute that doesn’t exist. Which version of odrive board you are using? and what’s the firmware version?
When dynamic version will be functional these errors wouldn’t occur as it would scan for the values that exist inside the odrive object instead of manually presetting and calling them.
Also, the quick fix would be to comment out few lines inside odrivetool_UI.py
at line 830 inside “def scan_can_config(self)” function.
Just comment out all lines that start with “self” by adding # infront of the line.
But probably I would be expecting more of these errors. As in my version it all works, so I am not sure what could be other differences.
Ah ok. I’ll give it a try. Thanks so much.
Will also post any future errors in the UI tool thread. Thanks again for your work on this.
Edit: Shit - just noticed I tried this using Wetmelon’s CAN branch. Perhaps it’ll behave differently with the latest, normal firmware. (additionally, I’m using my design, which is essentially the v3.4, 24V version)
Thanks this is helpful for now!
Would be great to get a documented list at some point though.
The thing is about open hardware/software and documentation is that things are continuously changing/improving, especially the variables used. It is very tedious, especially when you don’t have a big team, to update all the documentation along the way.
wayneStock
Oh absolutely. I think a generated documentation of at least the commands and the variables they take would be very helpful already.
A lot of projects use things like doxygen and put the descriptions into the code as part of a comment that is then parsed out by the documentation generator. I think thats a fairly lean way to keep track of things and if you change a command you can change the description in the same place (be it just once sentence if its not self explanatory).
Fwiw, this is what the functions available in the Encoder class look like:
// Communication protocol definitions
auto make_protocol_definitions() {
return make_protocol_member_list(
make_protocol_property("error", &error_),
make_protocol_property("is_ready", &is_ready_),
make_protocol_property("index_found", const_cast<bool*>(&index_found_)),
make_protocol_property("shadow_count", &shadow_count_),
make_protocol_property("count_in_cpr", &count_in_cpr_),
make_protocol_property("interpolation", &interpolation_),
make_protocol_property("phase", &phase_),
make_protocol_property("pos_estimate", &pos_estimate_),
make_protocol_property("pos_cpr", &pos_cpr_),
make_protocol_property("hall_state", &hall_state_),
make_protocol_property("vel_estimate", &vel_estimate_),
// make_protocol_property("pll_kp", &pll_kp_),
// make_protocol_property("pll_ki", &pll_ki_),
make_protocol_object("config",
make_protocol_property("mode", &config_.mode),
make_protocol_property("use_index", &config_.use_index,
[](void* ctx) { static_cast<Encoder*>(ctx)->set_idx_subscribe(); }, this),
make_protocol_property("find_idx_on_lockin_only", &config_.find_idx_on_lockin_only,
[](void* ctx) { static_cast<Encoder*>(ctx)->set_idx_subscribe(); }, this),
make_protocol_property("pre_calibrated", &config_.pre_calibrated,
[](void* ctx) { static_cast<Encoder*>(ctx)->check_pre_calibrated(); }, this),
make_protocol_property("zero_count_on_find_idx", &config_.zero_count_on_find_idx),
make_protocol_property("cpr", &config_.cpr),
make_protocol_property("offset", &config_.offset),
make_protocol_property("offset_float", &config_.offset_float),
make_protocol_property("enable_phase_interpolation", &config_.enable_phase_interpolation),
make_protocol_property("bandwidth", &config_.bandwidth,
[](void* ctx) { static_cast<Encoder*>(ctx)->update_pll_gains(); }, this),
make_protocol_property("calib_range", &config_.calib_range),
make_protocol_property("idx_search_unidirectional", &config_.idx_search_unidirectional),
make_protocol_property("ignore_illegal_hall_state", &config_.ignore_illegal_hall_state)
)
);
}
It’s fairly well structured, so it might be possible to script something… But if someone feels like going through the firmware and finding all of the make_protocol_definitions() functions and documenting the entire protocol properly, that would be very beneficial 
