oDrive status and roadmap

jct · September 5, 2019, 2:25pm

Hi all,

I am developing robots and I will need some of the new features discussed in this forum.
However I don’t know where to find the latest version and in which state of development they are.

Among important features :

implementation of CAN bus.
This is essential as I want to connect a raspberry pi with multiple odrive boards.
absolute encoders
Searching index and moving motors and parts at startup is not possible in many applications with safety issues.
end points
Again essential to avoid to break something.
auto tuning.
In applications with multiple motors and odrives, it is not convenient to tune manually each motor.
Auto tuning is mentioned in the documentation as an upcoming feature.
UI for odrivetool
The GUI developed by tinker_inc is a great product.
However it does not work for me out of the box with the latest firmware on windows. Some modifications are required.
It’s not complicated but it is a bit disapointing to not get it as a core product with odrive.
…

To plan the devlopment of future applications using oDrive, it should be very helpful to have a roadmap showing the status (in development, completed, tested, verified …) of these features and the timeline for introduction in the master branch.

I am sorry if I missed a previous discussion about these topics.

Maybe there is a devel branch to test all these new developments ?

BTW, Is there a V4 version planned ? if yes, what will be the improvements ?

In advance, thanks if anybody could clarify the future of this great product.

Cheers,

Wetmelon · September 8, 2019, 8:49pm

Working in feature branch.

Sorta working in feature branch, needs testing & validation

Working in feature branch

Not started.

Roadmap here: https://github.com/madcowswe/ODrive/projects/1

Try https://github.com/Wetmelon/ODrive/tree/RazorsEdge if you want to experiment with the newest features.

jct · September 9, 2019, 8:42am

@Wetmelon Thanks for these links.
I was not aware of this RazorsEdge branch.

I suppose you mean “RazorsEdge branch” when you said “feature branch”.
Am I right ?

regards

Wetmelon · September 10, 2019, 3:05am

Yeah. Although RazorsEdge is primarily made from pull requests from other peopl.

kedvall · September 29, 2019, 7:19am

@Wetmelon What is the difference in purpose between the RazorsFrozen branch on madcowswe/ODrive and RazorsEdge branch on your fork of ODrive?
They both have a similar number of commits, but it seems each lack a number of commits the other has?

I’m on RazorsEdge testing my AS5047 encoder over SPI right now, but not sure if I should be on RazorsFrozen instead?

Thanks!

Wetmelon · October 3, 2019, 3:06am

RazorsFrozen is undergoing review for eventual merge. But otherwise no real difference. I would stick with RazorsEdge for now

kedvall · October 3, 2019, 3:18am

Ah okay, thanks!
Also, is there a list anywhere of what features in RazorsEdge are pretty well tested and what are still under active development?

Wetmelon · October 5, 2019, 1:22am

The Changelog in RazorsEdge is a good place to start.

github.com

Wetmelon/ODrive/blob/RazorsEdge/CHANGELOG.md

# Unreleased Features
Please add a note of your changes below this heading if you make a Pull Request.

### Added
* Simplified control interface ("Input Filter" branch)
    * New input variables: `input_pos`, `input_vel`, and `input_current`
    * New setting `input_mode` to switch between different input behaviours
      * Passthrough
      * Velocity Ramp
      * 2nd Order Position Filter
      * Trapezoidal Trajectory Planner
    * Removed `set_xxx_setpoint()` functions and made `xxx_setpoint` variables read-only
* [Preliminary support for Absolute Encoders](docs/encoders.md)
* [Preliminary support for endstops and homing](docs/endstops.md)
* [CAN Communication with CANSimple stack](can-protocol.md)
* Gain scheduling for anti-hunt when close to 0 position error
* Velocity Limiting in Current Control mode according to `vel_limit` and `vel_gain`
* Regen current limiting according to `max_regen_limit`, in Amps
* DC Bus Power limiting according to `power_supply_wattage`
* Unit Testing with Doctest has been started for select algorithms, see [Firmware/Tests/test_runner.cpp](Firmware/Tests/test_runner.cpp)

This file has been truncated. show original

Ben_M · October 8, 2019, 3:20am

Similar to OP, we are looking to use them in a commercial product and just explaining our current position with the Odrive, so other users are aware of some minor issues that are holding the product back - All issues maybe our own fault not setting them up correctly or missing checking some error flag etc, this is still a work in progress.
We are testing using the Odrive in commercial Autonomous ground vehicle (similar in size and function to Amazon warehouse robots, we now have 4 such robotic platforms in field trials at customer’s sites.
We are using two in wheel motors with AB encoders (no index) and using one of the inbuilt Hall sensors as a index pulse.
We are experiencing two issues.

We are sometimes getting crazy heat or crazy movements from the odrive, this is dangerous and holding our product off from commercialisation. We think the issue is related to encoder ‘slip’ so the internal model of the rotor position is out compared to reality, this ‘slip’ being caused by missed or extra encoder pulses and as the encoder is incremental not absolute this slip is not corrected. We are using shielded encoder cables and nowhere near overspeeding the encoder. We now have both physical temperature monitoring and software current modeling to safeguard the motors from overheating.
But we still have an issue where sometimes the motor just starts driving and subsequently the robot driving out of control, crashing into things. When this happens, the motor can easily exceed the max velocity limit set in the odrive! So not sure how the limit takes effect, I do remember there is a percentage or fixed figure, it is allowed to overshoot the limit, will need to try and find this setting and see if that is our issue. We might still have some kind of noise or faulty encoders but it highlights a failure mode this is not monitored, at anytime in any project and encoder or wiring may fail, may experience external EMI and the end result could be uncontrolled motor movement and velocity! It would be good if the index pulse could be used as a sanity check.
We are also having an issue where sometimes the preroll to find the index is reporting success and no error flags but then axis will not drive, repeating the preroll can fix the issues, and this is easily done for testing but needs to be resolved before the product rolls out because there are no errors, we tell the robot to drive forward and it starts spinning around the non operating wheel.
Previously we were doing the preroll with load (the robot driving on flat ground) no we have built in little feet that the robot can deploy meaning the drive wheel are free to spin in the air has increased the success rate, so load is somehow affecting the preroll. (it was always free enough to complete the necessary movement)

The odrives are working well enough for us to test and set up all the other aspects of our project and only now are we back to trying to make it so the odrive is reliable 100% of the time, always starts up cleanly etc.

Wetmelon · October 8, 2019, 4:21pm

The false index preroll is a known issue, add a 22nF cap to the index pin. The other issue - velocity limit exceeded during faults - happens when the encoder slips and you lose commutation. That can be either an electrical (add caps to input pins) or mechanical (ensure no shaft slippage) issue. There is an overspeed error that should kick in I’d you have your firmware up to date, and the overheating should also be fixed thanks to the “current controller unstable” error in the newest firmware versions.

What hardware and firmware versions are you using?

Ben_M · December 16, 2019, 12:36am

@Wetmelon, Thanks only just saw your reply from October the 9th!
Will check firmware version with my colleague and look at adding the Caps.