FadeDude
South Africa
Asked
— Edited
Resolved by ptp!
Hi there.
Is there a way to implement a failsafe on the EZB?
Right now, if my EZB loses connection, everything stays in the state it was before the connection drop.
It would be great if there is a way to implement a failsafe with default values to use in case of a connection break.
If not a programmable failsafe, releasing all servos would do the trick.
Thanks
Check out ptp's firmware - I believe it has some fail safe features. There is a link to the Open IoT Wifi firmware, to create your own -or- ptp's firmware on this link: http://synthiam.com/Products/ARC
I assuming you are using the .NET SDK or Plugin.
1) You can monitor the EZB connection State, and if you detect a non intentional disconnect, you can reconnect again.
2) The only way to know if a TCP connection (SDK to EZB) is still connected, is to send some data.
You can implement a idle timeout Timer, every time you call a SDK method, you reset the timer, if timer fires you can send a digital out command on a specific port to force the socket to communicate, if the socket/connection is dead, the connection event (1) will be raised early.
Points 1 or 2 only works on the Desktop side, this means if your robot lost the wifi signal, and the wheels are in motion there is no way to stop the wheels.
BUT
it's possible to be done via customized EZB firmware, look for a Post "EZB Custom Firmware V2".
I've implemented a feature that allows the user to define the initial values for the EZB Ports when you switch on the controller.
I can create another feature to allow the user to define the ports values when the controller is disconnected e.g. pwm 0, servo position x etc.
bear in mind you will need additional hardware to flash your controller.
A link to ptp's firmware is on the open iot page - in my above post
Thanks guys.
Seeing as I don't have the hardware to write new firmware, I'll have to live with it as it is. :-)
If anyone does want to implement it in some future release, I think just a basic "Release all servos" will suit most use cases for a connection drop.
For now, the wheels shall keep turning (Pun intended, of course)
Thanks for the info.