Hi,
I know this is not standard support in AR3, however I really feel bad cause in some situation AR3 will move beyond limit switch due to some calibration mistake. Beside, I'm writing another web services which may make mistake and break limit switch too.
IMHO, I think I shall change AR3 firmware (Mean Teensy) to prevent any possibility of movement beyond limit switch. I tried changed Teensy function 'MJ' to return back slightly when hit limit switch. At initial stage everything look fine. When I start jog robot with longer distance, the robot randomly stop, it look like AR3 hit the limit switch during jogging, however I notice the limit switch still far away.
Below is the image I use serial monitor to connect Teensy. the command i send was copy from arcs program (MJB11166S25G15H10I20K5U8875V3277W0X7600Y2368Z3300). The extra return string "msg hit: 000 001" wrote by me, it tell me currently machine hit limit switch 6. I notice limit switch is far away, so send again the command, next round it feed back touch limit switch 2. I continue send again, it no complain, mean no hit at limit switch. I continue above process and I notice it like random error.
Below is the code i modified to read the limit switch value, i changed the code ~line 1516:
isJ1HitLimit = digitalRead(J1calPin);
isJ2HitLimit = digitalRead(J2calPin);
isJ3HitLimit = digitalRead(J3calPin);
isJ4HitLimit = digitalRead(J4calPin);
isJ5HitLimit = digitalRead(J5calPin);
isJ6HitLimit = digitalRead(J6calPin);Any expert have ideal? I think I did correct job but I don't understand why limit switch just randomly return HIGH when I jog robot, during calibration this issue never happen. After fix this I believe i can share this 'firmware' from my git repository.
Any of you have ideal?
default ARCS application controlled movement to prevent it break limit switch. however it is control in software, if we not use ARCS (like I developed another web service control panel, ROS/Moveit) then you will need to do own control. That is danger thats why prefered way is make the control in teensy so no matter which software we use it wont over limit
I've had this issue, but it was only due to mis-wiring. Ever since I got my wiring squared away (at least for the switches) I haven't had an issue. The only switch I've actually had destroyed was J2. The others just seem to bend.
Great thanks of your confirmation.
I'd make a 'HACK' by change the check limit switch algorithm. Now only continually 2 HIGH detected from same joint will force stop. Tested result seems good enough to say stable (no more sudden stop). If similar problem happen I will change programming rules become 3 time continually then stop.
So I've also encountered this issue as well while writing my own calibration sequence and can add my findings to this discussion. I wasn't sure if it was due to a fault in my wiring but if others are facing it too, I figure it's worth sharing.
I'm fairly certain that the spurious false readings are due to EMI noise from the motor cables. You can verify this by just reading the limit switches in a loop with the E-Stop on (24V to the motors disconnected), during which you should have clean LOW readings, and then reconnecting the 24V, after which you can observe the random HIGH readings.
The reason why this hasn't been an issue with Chris's implementation of the calibration is the way the logic is handled. Not sure if it was intended or a nice coincidence. The motors are driven as long as the readings are LOW, instead of stopping permanently when a single HIGH reading is received. This allows the code to skip over the occasional HIGH readings and resume moving the joint on the next iteration of the loop. (There is still an edge case where all 6 limit switches are reporting false HIGH readings which would wrongly end the calibration, but I also have another theory in Point 3 for why this rarely happens as well). In KS's and my case, the code was driving the motors until a single HIGH reading was received and terminating thereafter, which exposed this issue. You can also expose this issue in Chris's calibration sequence by imposing a long delay if any of the switches are read as HIGH. The calibration sequence will immediately enter the delay.
A strange observation I've made, though I may be mistaken on this, is that the false readings of the limit switches vary depending on which pins are being read. For example, just reading J3 limit switch in a loop will give consistent false readings, but when reading all 6 limit switches, there are false readings on some of the other switches but none on J3. This could be due to some capacitance in the teensy pins? Honestly I have no idea and haven't bothered to investigate further. What this does mean is that all 6 limit switches are unlikely to consistently give false readings simultaneously when being read at the same time, further helping to mask the issue.
In conclusion, there is some EMI and other shenanigans going on, no idea if it's due to the limit switches, wiring, teensy or a combination of all of them. Short of re-wiring everything with shielded cables, adding a shunt capacitor to the limit switch signal line could perhaps help with the noise. Changing the limit switches to NC instead of NO would mask (not fix) the issue and allow actions to be triggered by the limit switch. For now though, I don't think it's a big issue functionally especially if the limit switches are only needed for calibration, so I haven't bothered to investigate further (in my case I now just read the pin consecutively a few times hah). It did make for an interesting puzzle.
Previously I thought is weak connection within limit switch white cable and limit switch. However after some testing it seems not true. When jog robot it still once a while sudden stop due to limit switch signal HIGH
below is my teensy source code: https://github.com/SIMITGROUP/ar3_robotarm_webservice/blob/main/sketch/ARCS_teensy_sketch.ino
I don't know is it only happen at my arm, or it happen at others people arm too. If anyone can try this teensy code and see it have similar problem will be very nice.
Thanks,
KS Tan
I modified code to display all limit switch status when teensy looping every step (under "MJ"). It seems most of the time limit switch detect 000000, once a while detect seems HIGH at limit switch. Cause limit switch only carry constant voltage HIGH or LOW, I'm wondering will interference/noisy between the wire may effect it?
There is few situation motor will move beyond limit switch:
During not all joint at rest position, I press 'Calibrate @ Rest Position', at this time I allow move motor beyond limit switch
I don't know how it exactly happen during use joystick that time sometimes it over limit switch. Maybe same with issue 1)
I'm writing own web services program, sometimes internal bugs cause user allow move motor over limit switch. I'm wish to make hard control in Teensy to avoid i make similar mistake again.
Above is my code, near end of while loop i check limit switch signal.
I notice another weird scenario, I add code to fetch limit switch value outside while loop
while (Serial.available() > 0 or WayPtDel == 1){...}The limit switch seems detect correct value, only within while loop the limit switch value randomly return High. I notice all callibration pinMode = INPUT_PULLUP, am I did correctly to read the value? I saw calibration code using similar approach.
Hello, could you elaborate on the issue moving past and breaking the limit switch? I haven't had any reported issues with that so if there is something i can help with I would like to understand what you are experiencing.