Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Analog input for position or velocity control #243

Merged
merged 1 commit into from Dec 17, 2018

Conversation

@kalvdans
Copy link
Contributor

commented Sep 13, 2018

This change makes it possible to control position or velocity with analog input signal. Fixes #93 .

Example configuration:

odrv0.config.gpio3_analog_mapping.endpoint = odrv0.axis0.controller._remote_attributes['vel_setpoint']
odrv0.config.gpio3_analog_mapping.min = -400
odrv0.config.gpio3_analog_mapping.max = 400
@CLAassistant

This comment has been minimized.

Copy link

commented Sep 13, 2018

CLA assistant check
All committers have signed the CLA.

@kalvdans kalvdans force-pushed the kalvdans:analog branch from d8db9f3 to cc0f083 Sep 13, 2018

@madcowswe

This comment has been minimized.

Copy link
Owner

commented Sep 14, 2018

Thanks! I want to consolidate our threads a bit and create a master "command handler" thread. Once we have that we should put this analog poll on that thread.
Do you mind leaving this PR hanging until we have that?
Thanks.

@anilsawe

This comment has been minimized.

Copy link

commented Nov 29, 2018

Hi,
I made these changes to the firmware and was successful in driving the analog inputs to change the vel_setpoint. I am using two 9K ohm potentiometers to control the setpoints - connected to 3.3V (also tried Anlogg vcc).
However, with this firmware, my motors seemed to have stopped working. I am using Hoverboard motors and was successful in running them at various speeds for a long time - forward and reverse. Now the motors turn and stop. If I turn the potentiometer they will move forward and reverse but the motion stops after part of a revolution.

I went back to the original firmware and the problem persists. Is it possible that some settings have been corrupted? Hopefully, my ODrive board is not damaged. It's V3,4-24volts.

Any clues?

Anil Sawe
anilsawe@gmail.com

@madcowswe madcowswe merged commit cc0f083 into madcowswe:devel Dec 17, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
license/cla Contributor License Agreement is signed.
Details
@kalvdans

This comment has been minimized.

Copy link
Contributor Author

commented Dec 17, 2018

@anilsawe I'm glad you tried the branch and got it working for a while. I suggest you dump all configuration variables and see if the operating mode has accidentally switched to sensorless.

@madcowswe Sorry for late reply, but I like the idea of having only one thread for the high-level control (the vesc firmware calls them apps).

@madcowswe

This comment has been minimized.

Copy link
Owner

commented Dec 18, 2018

@kalvdans Yeah, it would be much easier to trace what could affect what is happening then currently. Nevertheless, I merged this now because it's still useful in it's current state, and we can refactor afterwards.
Thanks for your contribution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.