I got my CAN network up and running and sending positions, however regardless of what settings I change it doesn’t seem to be using “Trajectory Control”. It just moves the same regardless of what settings I edit.
Is there a way to get it to use trajectory control via CAN?
Check that tools/odrive/enums.py contains the line INPUT_MODE_TRAP_TRAJ = 5
Also check that you have a file called Firmware/odrive-interface.yaml It should mention trap_traj: TrapezoidalTrajectory somewhere.
If you don’t have that file, then you are NOT on rc-0.5.1.
I’m definitely running 0.5.1 and have loaded it from a mac and PC just to be safe and have the files listed. I’ve compiled it and also used the compiled version to no avail. I am stumped.
Well… this just aint my week when it comes to odrive.
I got the new odrivetool up and running like a charm… on the old odrivetool I had the CAN bus sending positions. However now that I’ve moved to the new tool I can’t get the motor to move to position like it used to via the same messages sent via the CAN bus.
If I add some to the end it jerks however I think this has nothing to do with the “input_pos” command.
eg: 0xcc 00 00 00 00 00 05 00 00
eg; 0xcc 00 00 00 00 00 00 00 00
I’ve spent most of the day on this and making no progress… anyone able to through me a line?
I’ve upgraded both the firmware & odrivetool. Do you know of a command I can run via USB to double check this? The only ones I know of are below:
odrv0.fw_version_major = 0
odrv0.fw_version_minor = 0
odrv0.fw_version_revision = 0
odrv0.fw_version_unreleased = 1
It does work via set input pos via USB. However when I send the command via CAN I get no movement, so my guess is this is a CAN problem.
Does anyone know where I can change the firmware version in the code? I’m looking for where I can edit the firmware version so I can triple check that the firmware has indeed updated properly. I’ve done edits to firmware before so I’m comfortable I’ve done it before, however I want to be 100% sure.
However, I do know I’m connected via CAN because I get movement in this part of the CAN packet:
And when I then set “input_pos = 1” it will move to that position, and when it recieves the CAN message, it runs back to 0.0 (and I’ve tried many combinations of HEX in the first 4 bytes).
Hmm, it sounds as if maybe you are sending the wrong node ID?
Make sure that you have set axis.config.can_node_id, and that you are sending the same node ID in the packet.
0xcc decodes as node ID 6, is that right?
Try my CANSimple.py - I wrote it a while ago but I don’t think the protocol has changed - if it has, you should be able to see where to change it. Note that you need the python3-sortedcontainers package installed (for reasons of the GUI that I started writing on top of this) and you also need to have my own enums.py in the same directory.
Hm, it’s a shame you don’t also have a RPi or CANable or something to test with. I’ve never trusted Arduino.
Straight bare-metal GNU AVR-LIBC back when Arduino used Atmel AVRs was great, but Arduino itself puts so much abstraction in.
You could still use my code to generate message IDs for you to send (just print them instead of trying to send a CAN frame)
Maybe this is an endianness issue? The 11 bit message ID is more than 1 byte - are you treating it as one 16-bit integer or two 8-bit ones?
(this is where python’s struct.pack came in really handy for me )
Thank for the reply Towen. I think the universe is sending me a message to step away from CAN for a minute, my arduino MKR died in a puff of smoke. I’ve never had that happen before and not sure why.
I think your on the money with getting something to test it with, I’ll order something to connect my PC so I can do some more rigorous testing.
I’ve come to know, my ecu does not support RTR / SRR.
Is there any other option to make the ODrive stream the encoder position and measured current to the bus?