Hello,
Is there a way of having e-stop behavior with an I/O of the ODrive board. In a similar fashion as Roboclaw boards? (see page 45: http://downloads.basicmicro.com/docs/roboclaw_user_manual.pdf)
1 Like
The motor will lose torque with a very high degree of certainty if you pull (and hold) nRST pin low on header J2. The drive will also reboot.
Thanks for your answer, so there is currently no E-Stop function?
I think it would be really useful add an input dedicated to an E-Stop. It could be as simple as sending a 0 velocity command when a pin is low.
Once I will have a working setup and a bit of time I will try to add it to a custom firmware.
I agree that an e-stop, that doesn’t require you to recalibrate the encoder would be really useful.
There’s different types of E-stops. https://machinerysafety101.com/2010/09/27/emergency-stop-categories/?doing_wp_cron=1548126008.3579199314117431640625
You’re looking for a “Category 2” stop - bring things to a halt, and keep them there under power (Vel Desired = 0). Lower, you find the sentence: Category 2 stops are not permitted for emergency stop functions
Disconnecting power to the drive, or holding nRST low is the correct way to implement a Category 0 E-stop
2 Likes
That was a really nice read, thanks for linking it.
The way I’m used to motor controller e-stops, is that they turn-off the mosfets to the motor wires, or short them to each other. They leave the controller running but put it in an error state. In most emergency situations it is important to be able to read any sensors related to the motor (position and temperature for example).
Does cutting power to the motor, but not to the controller, full-fill the criteria for Category 0?
The implementation I’m describing is shown and described briefly in roboteq’s controller manual on page 38.
https://www.roboteq.com/index.php/docman/motor-controllers-documents-and-files/documentation/user-manual/272-roboteq-controllers-user-manual-v17/file
I am also looking for an emergency stop solution to stop the motors (Safe Torque Off) without powering off the Odrive (to be able to restart the system without having to recalibrate).
I was looking into 3 phase contactors to cut the current supply between the Odrive and the motor upon pressing the emergency stop button.
Regarding the sizing of such device if I set in odrive the current_lim to 15A can I assume that the max current that will go through one phase will be 15A ?
Thanks !
Hi,
I’d also like to use one or two GPIO pins as a hardware EStop input, but I can’t see any way to configure the GPIO pins to do this, either in master, devel, or Wetmelon/RazorsEdge.
Ideally, I’d like to perform a category 1 stop by shorting all phases to GND.
I could try to implement this myself, but I don’t know if anyone else is working on it?
I notice there is a new flag in Wetmelon’s branch called ERROR_ESTOP_REQUESTED but it only gets set on a command message. It should be fairly easy to set it from GPIO?
Yeah it should be easy to set up a GPIO to do it. Of course doing this in firmware rather than a direct hardware line to the transistor drivers is less perfectly safe, but as long as you understand that I think you can do this.
Hi Oskar,
Thanks for this. Yes, obviously a proper SIL-rated STO line direct to the FET drivers would be a more reliable stop, but a firmware-based EStop would still give a high degree of reliability, given that a brushless motor cannot self-commutate. So if the software crashes, the worst it can do is burn out some motor windings (which itself can be mitigated with motor fuses). It’s still possible of course that the software can ignore the GPIO and still carry on computing the FOC algorithm, but it should be simple to demonstrate that this is extremely unlikely.
Actually some industrial drives are starting to implement STO this way, because it allows for more advanced safe-stop functions like category-2 stop (stop and hold position) or safe-velocity limits for robots with a ‘teach’ mode.
But compared to listening for stop commands over CAN/USB, or to a brushed-dc driver using a GPIO as an EStop (e.g. RoboClaw), this is much safer.
Hello everyone.
I have pushed e-stop functionality to my branch:
I have been testing this for about 6 months and it works reliably. Recently I made a new PCB with a special chip that monitors for a square wave, and I am using it to drive the e-stop input on the odrive. Now I have to produce at least a 10hz square wave from my raspberry pi or the motor stops. The serial communications code to the motors will toggle the line after each serial communication, so if the motor control code locks up, the motors shut off within 100ms.
I drive the square wave first through a mosfet which receives power from a physical e-stop switch. So actually both the voltage from the e-stop switch and the square wave from the raspberry pi must be present if using my interface circuit. (The actual e-stop code only looks for a 3.3v or 0v logic level and works with a simple switch.)
I updated my interface board. I am using RS-485 for motor comms through an ethernet cable which also carries the e-stop signal. At this time we are not releasing the board on the other side, but I hope we can release it in a few months.
Here is the interface board with the square wave to ttl logic converter chip and the ethernet jack with RS485 to ttl serial converter.
1 Like
@towen did this end up in current branch? Is there any way to do e stop built in without reset odrive?
I don’t think it is. I don’t know why.
But if you need it, you can always merge tlalexander’s changes into your own repo.
Well i see a lot of changes but the one about estop seems to be this one
How do i update the firmware? Can i do it over usb? What are odds it messes up odrive where i can’t fix from usb?
Yes you can do it over USB. Read the firmware developer guide.
The USB firmware uses a built-in DFU bootloader from ST, which is permanently stored as ROM in the STM32 chip. In theory it’s not possible to brick it.
Normally, the odrivetool dfu Firmware/build/ODriveFirmware.hex command will first ask the ODrive to enter bootloader mode (it jums to a special memory address in ROM) but in the event that the firmware is not working, because maybe you broke it, then you always have the DFU switch as a fallback, which forces the chip to start the bootloader ROM on power-up. Don’t forget to switch it back to RUN before you try to use it. 
1 Like