I have some questions about Pypot concerning troubleshooting of the robot.
When the robot works, it works. But when there are issues, it is not clear for me.
When a motor has an overload error, the synchronising task stops while the main task is always there. The error message is “… overload…NotImplemented…” I imagine this part has to be coded by the user. The error.py code must be overloaded ? It would be nice to have the number (the name) of the motor which has an error.
Moreover, the robot has to be unplugged/replugged. I imagine setting a switch relay on servo power commanded by arduino but… It is complicated. Do you think we can overload this protection using Pypot?
Then there is this “checksum” error. It is special since there is no need of unplug/replug procedure. Just reinstanciate the robot (In my case, relaunch the soft). Is it possible to ignore this error ? If one transmission has an issue at 50Hz, It is OK for me to ignore it.
More generally, I imagine a monitoring class included in the robot with the status of each motor, temperature, load, connected/disconnected (for false contacts). The ideal challenge is to find the robot error and cause very quickly.
It is my “flight control” view of the robot. In an aircraft, the pilot can access the Flight Control view of the aircraft and identify directly if there is an issue and where it is. For a show with public, it is more than crucial.
Yes this is why I designed the error managing system this way. My thoughts were that I do not know which errors are important for the users and which ones are not. And it could be dangerous to wrongly decide it and hides it. I could have just logged warnings but let’s face it nobody reads the warnings.
Yes I agree! This is on my todo list for so long now… But this is not necessarily trivial when we use sync read.
No you can’t bypass this security from software. You will have to use an alternative firmware for the motors if you want to do that.
Yes, this is quite easy. You can do exactly the same thing as I did for the timeout and communication error: see the BaseErrorHandler. I did not did by default because I never encounter this checksum error when working on our robot. Thus I wasn’t sure if we should just ignores it as we do for timeout. This could be integrated as the default behaviour.
Yes this would be nice But not so easy. All motors are on the same bus, so when one motors sends random things on the bus all you read is bad messages. We would need to have multiple wires, doubled captors… well as you said like what they do in an airplane. But I’m afraid for this we will need other motors and another type of communication.
Yet, we could already have something simpler like position, temperature, torque… This is precisely what poppy monitor is doing!
Thanks for the answers.
I will test the code about checksum to inhibit this error.
My aim is not to have a safe system but a very transparent system as far as we can. If one message is wrong, I wish the one after can be readable at 50Hz.
I am going to test on AX motors to deactivate the motors inside protections to report them in the software so that I can manage them and see if I can detect a motor disconnection without having errors.
But not so easy. All motors are on the same bus, so when one motors sends random things on the bus all you read is bad messages. We would need to have multiple wires, doubled captors… well as you said like what they do in an airplane. But I’m afraid for this we will need other motors and another type of communication.