Hi Zennix, Hi community
first I want to wish you and the comunity a happy new year!!
Regarding the ST-programmer: Now I tryed several hours to get the OpenOCD get running. But without success. Although I did all steps according to the manual my computer can´t start the program. When I open the *.exe file, the programm seem to start for a fractual second, but then…nothing. I also tryed lot of compability settings…but also without success.
(Remarking: I have a new Windows 10 computer with an i5 processor and RTX-graphic card - so no old stuff)
So I swaped to an other DFU-tool called “DfuSe”. Its recomendet in the chapter: “Upgrading firmware with a different DFU tool”.
After installation the program is now running .
But it does´nt recognise the ST-Programmer (Available DFU Devices).
I changed the drivers with the Zadig-tool several times, used a second ST- Link (I ordered two), forced the Odrive in DFU-Mode, changed the USB-Ports, rebootet my computer and the Odrive, checked all wiring …but…nothing, the program does´nt recognise the ST-Link!!
Something goes completely wrong…
Anybody in the comunity with any ideas, same experience ?..
One example of compatible drivers are the ST-LINK/V2 USB drivers, from ST, available as part number STSW-LINK009. Download the stsw-link009.zip archive, extract its content to a separate folder, and run the dpinst_amd64.exe (or dpinst_x86.exe ) with administrative privileges.
I followed the Manual you mentioned (https://docs.odriverobotics.com/configuring-vscode.html)
a few steps, but I a am sorry…thats much, much, much too difficult for me.
I have a collegue at my work and he is a professional programmer…maybe he can do this steps for me.
Hi Peter,
thats really great that you made it.
You are now half the way up the “software mountain”
The master brunch has some issues if you try to use the serial command interface like we have to. Also it didn’t support end switches.
The branch with end switch support comes from wetmelon and is located here: https://github.com/Wetmelon/ODrive/tree/Endstops
How to use it:
I downloaded the latest version and did the fixes for you.
Hi Zennix!
thank you so much for your help and efforts! I appreciate this very much!
I imediately flashed your custom made firmware and it works so far, but I have some errors codes I have to check for the next days.
I am not sure how to connect the end switches to the Odrive. I think the connection has to be made from GPIO Pin 8 to GPIO Ground or any voltage pin?
Do I need the switches for the startup procedure or can I test your firmware without switches (maybe temporary disable the switch in via the config?
best greetings!
Peter W.
Hi Peter,
there are a lot of additional settings through the ODrive Tool. Please have a look to the thread I have shown in my last answer.
You have two switches per axis. So you will need 4 GPIs for two axis. You have to enable the endswitches otherwise it’s like a normal branch firmware.
I have my switches active low, means switches GND to the GPI but you can define it in the settings too. I had some debouncing, therefore I connected some caps between the GPIs and GND. Described all in the upper thread.
Greetings / Zennix
Today I studied the Odrive-commands that are given in the Odrive documentation and I made a summary In order to get a better understanding for building of the commands:
please have a look (still in progress…):
But I found that a lot of commands and settings shown in the firmware are not explained or shown in the Odrive documentation. So its difficult for me to optimise the firmware for my system without having a detailed understanding of the commands !
what to do!!!
I changed some settings in your firmware, but I am not able to get the Odrive running with the firmware. Now there is an error shown, that I can´t find in the troubleshooting. It is error = 0x0040
please have a look:
Hi Peter,
I gave you the latest build of the endstop firmware. I have a version running from september last year. https://drive.google.com/open?id=1lOZ5YWdu3BavNJusFNKw6GGAO-fryOhN
You can try this. But I have made some settings inside the firmware, so I didn’t have to make it after every flash progress.
The changes are as follow:
axis config:
startup_motor_calibration = true; //<! run motor calibration at startup, skip otherwise
startup_encoder_index_search = true; //<! run encoder index search after startup, skip otherwise
// this only has an effect if encoder.config.use_index is also true
startup_encoder_offset_calibration = true; //<! run encoder offset calibration after startup, skip otherwise
startup_closed_loop_control = false; //<! enable closed loop control after calibration/startup
startup_sensorless_control = false; //<! enable sensorless control after calibration/startup
startup_homing = false; //<! enable homing after calibration/startup
enable_step_dir = false; //<! enable step/dir input after calibration
As we have the same config, so you can use it as it is. Maybe the current and the vel_limit is to high for testing. With your encoder you can use index search as well.
Normally your settings are kept after a flash but you should know that the default settings has changed.
Thanks for your spreadsheet.
You should add the vel_limit. It limits the rotation speed of your motor.
And save_config.
Hi Jerry,
nice to see you here in the thread and thank you for your hint.
Because I didnt change the connection between the encoder and the Odrive and it was running before, the source for the error had to come from anything other .
greetings
Peter W.
Hi Zennix!
Thanks again for your great support!!
Today I flashed the new firmware you gave me today. I changed the configurations acording to your proposal, but nothing worked…
But I allways set my counts per revolution “cpr” to 800 and the encorder.switches to 200 PPR (I thought it is ok) and now I changed it to 8192 (odrv0.axis1.encoder.config.cpr = 8192).
And…Bang!! …now everything is working (nearly) perfect!
Maybe this was the issue.
My Odrive now follows the pos_setpoint command and if I want to turn the motor by hand he resists…really cool
Regarding the spreadsheet: It is only a draft and I did´nt test all commands. My aim is to make an easy to use and common understandable spreadsheet with all the main commands. When it is finished I want to share the file with the community in order to help other newbie like me.
I tried to sent commands from Sim Tools to the Ordive with help of the “Output Testing” - but the Motor doesn´t respond.
What I dont understand is:
Do I have to set the output type to
DOF Output,
(a) axis output, or
(b) axis output?
I Tryed them all, but no response of the Motor (note: my Motor is connected to the M1 side of the Odrive)
You wrote about an issue with the ASCII protocol, but I dont really understand what you say and where to find the ascii_protocoll.cpp
Now at the end of the day……I honestly wonder if controlling my simulator with Odrive is not too difficult for me as a Software-beginner.
Every time I solve one problem, a new one emerges that I can not solve myself.
Please be honest … does that make sense?
I also have a bad conscience to have to ask you over and over again how it goes on.
you are really close to the end of the tunnel. You wrote that you use M1, why do you drive M0 with game engine?
Try: p 1 32767<13>
If you want to see movements only for one axis, try LFS.
You can see, that sway is connected to Axis1a, so you have to write in the second line of game engine: p 1 <Axis1a> <13>.
To your ASCII issue. In the firmware I sent you, I removed the bug. To this, you cannot use parameter w and r in ODrive tool anymore, but as sim rig user you will not need it.
As I told you before, ODrive is not a out of the box product. You can go and buy a ready build sim rig for thousands and thousands of €. Or you can go the stoney way and do it by yourself. We are the first people who build a sim rig with ODrive. I found nobody doing this before. So its a development process with up and downs.
During my project, I often come to a point that I thought there is no solution for my problem. But after digging and help of the community, it goes further and further, sometimes in small steps but it moves. I wait 6 weeks for the endstop firmware, without any progress.
You are in the lucky situation that somebody (me ) allready has a running configuration. You can be sure, that your project will be supported to 100%.
Hi all!
After some weeks of silence I want to share some news about my Project.
Yesterday I finished the last main parts for the prototype and did a
first assembly for first tests - and what can I say…so far
everything is working like expected.
The internal pneumatik-cylinder-System is tight and can be pressurised
by a simple bike-pump. So later the permanent load of the platform plus
person can be compensated to zero.
I did some first runs with my extremely weak 12V, 4 A power suply and
the actuator is running. Of course not as fast as with the future 36 V
supply.
The next steps will be to add the end-switches and to buy 3
car-batteries (connected in series) that will be my future power-supply.
Then I will push the actuator to its limits
Here are some impressions….
nice to hear and see your progress. Thats a really good idea to use it like an air spring.
Are the two bearings tight enough that you don’t lose the pressure?
…now everything is working (nearly) perfect!
) allready has a running configuration. You can be sure, that your project will be supported to 100%.
