Please keep us posted on your adventure. I'm very curious to see how it works out for you.

I'm just tossing this around in my head; my concern (like you) is getting the motor back to "Home" or a certain exact spot. We need the arm (or in your case, a periscope) to safely retracted into the body of the robot. With the Roo in "Position and Speed mode" it uses the encoder to first Home to know exactly where the motor is positioned. We then can park the appendage in the exactly position once the animation is completed. With servo control, theoretically, once set up in the proper position, we can return the servo back exactly to that spot. When we again restart the animation and the servo hasn't settled or moved, ARC will assume it knows it's position on the next start up and all will be well. The problem is "what if" the servo has moved when powered down? How do you get it back to the exact parked position before sending it out on it animation adventure? The servo will park where it started out and may not now be in alignment with the hole it needs to enter. Disaster and destruction will ensue as everything gets sucked in. One thing I tried was to install a limit switch to let ARC know the arm is centered. If not it would not retract. However then I had a arm sticking out that I needed to manually retract.

I'm very interested in how you overcome this. I really want to start using ARC's servo commands instead of Simple Serial. So much simpler.

Dave,

You hit the nail on the head.  The animation mounting system that I created is modular and allows the user to mount hardware magnetically onto a plate that is also the seat for R2’s dome.  The periscope you see is magnetically seated on the plate and can be literally pulled off for maintenance and traveling to philanthropic venues and conventions.  So this module’s motor system is absolutely going to shift during transport.

Unless ARC can use a limit switch to reassign home servo position, I don’t know how else it can be accomplished outside of    simp serial.

Heres a link to my YouTube channel so you can see the Warp Core Base Plate I created for the Warp Core Dome System.

https://youtube.com/user/Warpcell

The kangaroo handles the positioning - and the kangaroo also has input for limit switching. The idea of the kangaroo was to make anything a servo. They did a wonderful job at the design. So you would connect the limit switches to the kangaroo, not the ezb. And it would calibrate itself on startup to know the position.

from: https://www.dimensionengineering.com/datasheets/KangarooManual.pdf

Hi D.J.,

The rotary motor has a single limit switch that I use to register the home position when sought out by the home command.  Are you saying there is a way to use servo commands to seek out and find the home switch?  For example, when I send a movement command in serial (2, p3000 s2000) to the Roo, it takes a few revolutions to get there and the Roo ignores the limit switch every time it hits it.  Yet, if I send the home command (2, Home) the rotary moves until it hits the switch and at that point Home is re-established and the p3000 is cleared as the home is now P0 no matter how many revolutions it took to get there.

Presently, if I tune the Roo with the limit switch in servo mode, the switch will register as position 180.  This effectively limits the rotary to a single rotation.  A mechanical stop tune may be better but I would need to literally grab the periscope at certain points during the tune to establish the end points of the rotation because currently there are none.  A Teach Tune is not possible due to the gear ratios within the rotary mech.

That would be super awesome if a servo command can take the place of the serial commands.  However, the Roo does not currently calibrate at setup.  It only calibrates during the initial Tune.  Currently, I have launch commands upon connection that start the baud rate, start the motors, raise the lifter, home the rotary, all before lowering the periscope into the dome; all done in simple serial.

Does that make sense?

Thank you,

Doug

Oh, so the rotary motor has a limit switch that you're not able to use because you want multiple rotations of the output?

If so, we'll have to not call it a limit switch. If that's the case, then yeah we can't use it at all.

So I'm not sure how the "servo mode" works with the kangaroo when using an encoder and the shaft is moved without power on. How does it recalibrate itself. I did read that it can recognize rubber stoppers because the current is monitored.

That’s a good question.  The Roo has serial commands to initialize and home which has to be done whenever the system power cycles.  There are no commands for that in servo mode, that I know of.   In any case, here’s a video I made to explain it.    The other advantage reason I need the condition is to ensure the periscope doesn’t rotate prior to being raised.   That can cause a real mess.

First I gotta say wow. What a beautiful work of craftsmanship and engineering.

You are working on the same problems I was when I built my B9 robot arm. If the arm retracted into the torso without being completely centered then it would hit the arm hole and stall. Thank God the Kangaroo detects the stall (or runaway) and stops. However I found damage can still happen to the structure or motors.

The only solution I could come up with was to add a center switch that was monitored by an ADC port on the EZB. I had the main animation script wait and check that switch ADC voltage first before the arm was allowed to retract. If after sending the command to center and retract and that switch was not closed it would not retract.

A few things I didn't like about that solution; *One, I had to come up with a second animation script that would start up automatically (using If/Else If commands) upon failure that trys to re-center the arm and close that switch.  *Two, there was a pause while the script checked that script.  *Three, the animation took longer then wanted if centering failed.  *Four, If the arm couldn't ultimately find center I had to park the arm manually with ARC movement controls.

I wish I was in the position and had time to work on this here on my robot along with you. However I'm currently neck deep in another project I can't stop. However finding a solution to this issue or better way to command a Roo may help make my current project more elegant. I'll stay tuned. Please keep us up to date. I'll help if I can and learn from you along the way.

Thank you so much Dave!   I really appreciate the information you shared.  The Roos Getp command is specifically there for a conditional script.  Perhaps DJ can help us get the position registered to be digested by ARC.  I’ve added an extra home command to my scripts but it’s a poor substitute for an if/elseif scenario because the lowering script still assumes the rotary is in the roper position with no way to verify it.