Loading

MakerBot Print is our newest print-prepration software, which supports native CAD files and STL assemblies,
allows you to interact with all your printers via the Cloud, and many other exciting new features.

Download Now

Hey! This thing is still a Work in Progress. Files, instructions, and other stuff might change!
LoboCNC

WE-R2.4 Six-Axis Robot Arm

by LoboCNC Jan 4, 2019
Download All Files

Thing Apps Enabled

Please Login to Comment

Hi Jeff,

I'm experimenting with heatsinks and fans for cooling to solve the problem of those Moon's stepper motors heating up so much. I'm using a TMC2130 stepper driver which does let you run it at very low amperage, but I still get lots of heat after a while of running. I'm making progress as seen in the attached photo with lots of different ideas, but I notice that your new small actuator is 53.5mm in diameter. Your wrist shell is about 50.5mm in diameter. I could really use the extra 3mm in diameter on the shell. Do you happen to have a new wrist shell design that matches your new actuator?

I'll look into how much fussing is needed to grow the wrist shells by 3mm. The current ones are pretty tight for my motors, too (I have to scrape the labels off the motors to get them to slid in), so the change would help. BTW, when you aren't moving the arm, what are you setting the holding current to? I've been lowering it to nearly nothing as the gearheads aren't really back-drivable. If I'm cycling the arm a lot, then the motors will get pretty warm, but mostly when I'm playing around, the arm spends a lot of time idle, and the low holding current keeps them relatively cool.

I'm actually setting the current to zero on idle after a few seconds. That's not the part heating it up. It's the repetitive movements where it heats up after a minute or so. I agree, if there's not much movement with idle time between moves then the heat is manageable. Those RC motor sized heat sinks did arrive, as seen in the photo, and they're pretty cool. The only thing that may be needed is more holes for venting.

Yes, I'll be quite curious to see how your heat sinks work out. It's quite a nice coincidence that the small steppers have nearly the same diameter as the RS540/550 motors. One other thing I just looked up is thermally conductive 3D printing filaments, and I ran across this: https://tcpoly.com/3d-printing-filament/ Maybe I need to redesign the shell to explicitly act as a heat sink printed out of this stuff.

Please to make a video on how to assemble the arm. Because I find it quite difficult on arranging it

Hi LoboCNC,

I have a problem with my bearings ... I print the PlanetCluster gears at a scale of 99% (and the rest of the parts at 100%)
I just tried the largest actuators (20 pitch actuators) ... I aligned everything right, and I can place Ring48 gear over the upper part of the 3 planet cluster gears easily and turn them with motor Nema 17 ...
But I can not put the 6 mm balls easily ... and when I put less than 20 balls and it was impossible for the engine to turn ...
so I took off the PlanetCluster gears and just place the Ring48 ... I just put 24 balls and it is very difficult to turn by hand ...
and I noticed when I put 6 mm balls I haven't space to put others again (the part where I haven't balls becomes thinner) ...

please do you have any idea to get over of this issue?
thank you .

First, before assembling any of the gears, test assemble just the bearing. This will make it much easier to gauge when everything is fitting together well. And before assembling the bearing, first sand out any lumps or bumps in the bearing races - they should be smooth. (You don't need to sand out the layer lines, just any irregularities. Then assemble the bearing with just 3 balls and space them out at 120 degrees. The bearing should be very easy to turn at this point because it will only get tighter with more balls. If the bearing is still too tight, you may be over-extruding some, or your printer may be out of calibration otherwise.

Latest pic of actuator controller with touch wheel for jog dial. Also, shot of robot workspace in ChiliPeppr. Have the jog info working for one actuator so far and XBox control working.

Whoa, very cool. BTW, how are those Moon's motors working out? I've actually been using some other model that I had gotten surplus, and the Moon's were the closest I could find that were generally available.

The Moon's motors are pretty nice. I ordered some cheaper $3 and $1.25 ones recently on Aliexpress just to play around with them to see if they compare. I doubt they will be as high quality as Moon's. The only downside is it's super hard to fit them into the wrist shell because that slot you did for the wires and plastic box doesn't quite match up. I'm thinking maybe your motors had the wire on the bottom rather than the side.

$3
https://www.aliexpress.com/item/10pcs-DC-6V-Japan-FDK-dia-35mm-6ohms-2-phase-4-wire-Stepper-motor-stepping-motor/2054451318.html

$1.25
https://www.aliexpress.com/item/Brand-new-and-orginal-PM35S-35mm-stepping-motor-24V-2-phase-4-wires-7-5degree-stepper/32974327803.html

I'm testing out the temperature sensor on my small stepper actuators right now because those steppers run super hot. As I do tests, around 45 degrees C is when I see problems start. The main problem is the shaft disconnects from the sun gear because the plastic gets soft from the heat. One idea would be to put a heat insulator over the shaft and then attach the sun gear to the insulator. The best insulator is ceramic or glass, but getting the correct size sounds hard. Are there any other ideas for isolating the heat from the shaft of the stepper motor with the sun gear? Maybe just a higher temperature plastic tube around the shaft, and then glue the sun gear to that higher temp plastic?

The best thing might be to print the Sun15 gear in nylon. Nylon has higher softening temp. and it will wear well. Unfortunately, it is difficult to glue so you'd need to print (and then drill out) the bore a little undersized and them press it on. The other solution would be to file a flat on the motor shaft and then print the gear with a D-shaped bore. Also, if you switch to the antibacklash versions of the gearheads, they'll provide a lot more output torque per amp of motor current.

In general, though, motors and 3D printed plastic are always going to have an uneasy relationship. Here are a few additional ideas on managing the heat:

  1. The best option would be to run the steppers closed loop, which dramatically reduces the average current used. Unfortunately, there's no great way to get an encoder on the small 35mm motors without a backshaft.
  2. I use a stepper driver where I can set a holding current which is much less than the running current. This is a huge help if the motors are not being run constantly.
  3. You could add a heatsink to the motor body. Round heatsinks for 540 sized RC hobby motors are 36mm in dia, and with a little heatsink compound as filler could be added to the 35mm steppers.

Any chance you can post the models for the modified gripper you made with the moon motor?

Thanks,
Dylan

I believe the gripper is included with the arm step files but I haven't posted the STL files for it yet. The stepper version doesn't have much gripping power, though. What I really need to do is find a driver solution for the DC motor version. (Unfortunately, I can't seem to make the Tic T500 driver work with the small DC motor.)

Hi LoboCNC,

I think I am getting really close to completing this project. At this point I am just struggling to get the small actuators to work without stalling. I don't have a 0.3mm nozzle so I am trying to make it work with the 0.4.

Anyway, I am having a small issue with the TicStepTest program that I was hoping you might be able to help me with. Whenever I am trying to run a program that last more than 20-30 seconds, the program crashes, throws a bunch of errors, and closes everything in rapid succession. Please see photo of the error I am getting here:

https://1drv.ms/u/s!AmGu4mSmjSxdggQ_j0qJyJm6710N

Any idea why this would be happening?

Thanks,
Dylan

OK, I found the bug - just a bit of debugging code I forgot to turn off. You can re-download the latest version of the TicStepTest program from https://drive.google.com/open?id=1rKRuWC4jAOekrds_WGUC7DkwlVsk2zdb

I haven't seen that error, but it looks like the sort generated by some mishandling of something mathematically. Looking at your path data file, I see that you are just specifying 2 points very far apart. I suspect that somewhere internally the math has an internal 16 bit integer limit (+/- 32767), and that as you move past that limit (at the 20 - 30 second point), the error is triggered. I'll try duplicating the error with your data and see if I can't track down the bug. In the meantime, try instead using 26 path points (0 0, 20000 20000, 40000 40000, 60000 60000, etc), instead of just two, which should yield the same results. If this still triggers the bug, then I've got a slightly more significant bug to deal with.

***Scratch that above. I did some testing and the bug isn't related to any integer overflow problem. I'll have to look into it and get back to you.

Regarding getting the smallest actuators to work, it can take a lot of work to sufficiently clean up the gear teeth after printing so that they run smoothly. You could print the cluster gears slightly smaller (97% ?) but that will also introduce more backlash. Instead, I'd suggest you try printing my recently posted antibacklash versions which are much more forgiving: https://www.thingiverse.com/thing:3566678

Anti-Backlash Compound Planetary Gearhead
by LoboCNC

Thanks for looking into the bug. Please let me know what you find.

Now that I have a working robot, I'm going to start diving into the c++ end of things to try and understand that.

Video of my final make minus the gripper is here: https://drive.google.com/open?id=1wH6iYBWjGBd3szCdfBZgX4Us5ri9elJ1

Thanks again for everything!

So I've put together a small arduino sketch to show how to control this arm via the ROS package:
https://github.com/jasonhillier/we_r2_moveit_config/tree/master/examples/arduino/simplejoint_positions

It's a simple demo, but as part of another project, I am working to build a joint trajectory controller which will make this ROS package much more capable.

note this is using a RAMPS setup, but if anyone would like to modify it to work with the TIC drivers, I'd be happy to merge it into the repo.

This is really a great project to do, but it will take a lot longer than a weekend for sure. I end up printing in PETG. the first three actuators go together well, the last three will take a while. I end up using Nema 11 motors and had to re-size the interior of the center gear to 5.20 mm. I’m using a ramps/mega(because a had one extra), and three TB6600 external drivers. I added a Bluetooth module and an Android app. I printed the claw but haven’t mounted it yet. Also, I designed a Nema 11 mount for the 3 smaller motors that fits between the motor and each vaseshall if anyone needs it, I’ll post. Thanks for the great project.

Nice design, thanks a lot for sharing.

Printed first gearbox and tested it. With 7680 steps you get 360 deg turn. accuracy is there . Testing setup I have Arduino UNO- TB6560 driver - Nema17 (1.7A) 1.8deg/step with 12V. Need to order TIC boards and put printer singing for the rest of the parts :)

In your previous reply, you said "As for the power supply, I am using a generic 75w, 19v laptop supply. These are insanely cheap (<$10) and pretty widely available."
Is 19V 75w sufficient for 7 motors?? It means 4A, but Large NEMA17 motor uses almost 1.5A and motor driver's manual recommends at least twice of motor's current which means 3A for just one motor

SIzing power supplies for stepper motors is a little tricky. The first thing to note is that modern chopping stepper drivers act like switching voltage regulators that convert the high voltage of your supply output (in this case, 19v) to a lower voltage actually used by the stepper. The 1.5A 42mm long stepper I spec'd for J1, for example, is actually only rated for 3.5v, so what the chopper driver does is essentially convert the 19v down to 3.5v. The actual power used (1.5A x 3.5v) is only a little over 5w. This driver efficiency is maybe 90% so your 75w supply could theoretically power 13 of these motors. When you start moving, though, the drivers supply the same current to the motor, but at a higher voltage, using more power. Exactly how much power depends on your speeds and on the speed-torque curves of the motor. In practice, i've only measured about a 2.5A current draw from the power supply when moving the arm around, which is why I deemed the 75w, 4A supply sufficient.

Hi there, what model NEMA 17 Steppers should I obtain?

All the motors are listed in the Post Printing section of the Thing Details.

Hey folks,

I've put together a ROS Moveit package to control this arm! It's still in the early stages, but I thought I'd share and see if anyone is interested:

https://github.com/jasonhillier/we_r2_moveit_config

Cool, thanks for sharing.. need to start learning ROS as well.. btw do you have some idea already how to control TIC boards from the DRVIz simulation as well can you actually use pure STLs for making robot simulation or you require URDF conversion.

So for the controller, I'm actually working on another open-source project that I plan to publish in a couple weeks, which is an Arduino library for motor control. It is geared toward rapid prototyping to make it easy to control a set of motors via serial/ROS/gcode etc. At the moment my hardware build for this arm is using an Atmega2560 with a RAMPS board. I have 3 NEMA17 steppers and then 3 DC gearmotors with encoders for the top joints. I may change it to use the TIC setup later though. Either way, I'm hoping this motor control library will make it easy to interface for any hardware setup. That being said, I'd be happy to merge in any contribution for different controllers. I am currently using this library for the hardware interface:

https://github.com/ros-drivers/rosserial

As for the URDF, it is actually an XML file that points to a set of meshes (STLs) for the visual model. It can (optionally) be configured to point to another set of meshes for the collision model. Something I need to do for this ROS package is create convex hull STLs of each link so the collision checking is less complex/much faster. The only optimization you'll see in my URDF file at the moment is drawing a cylinder for the base collision geometry instead of using the STL.

For this model, I initially used this tool to generate the URDF from Fusion360:
https://github.com/syuntoku14/fusion2urdf

Thank you for the precise answers. Got interested about your setup by controlling 3 DC motor with encoders + 3 steppers with one Arduino mega and ramp. Can you consider sharing more details , wiring schema and your DC motor types would be super nice.

Looking fw as well new arduino lib for the control you are designing . . Cheers

I'm primarily using the DC encoded motors as a cheap stand-in for having closed-loop control. I'm actually in the process of installing encoders on the nema17's right now. If this smaller build goes well, I am interested in scaling up this design a bit or moving to metal. Something that can drive a few pounds of dynamic load. This will mean onboard drivers for the steppers aren't feasible anymore since I'll need larger stepper drivers (like for Nema23's). So right now my RAMPS setup with a lot of wires makes some sense. If you're interested though, here is what I'm using to drive the DC motors:
https://www.amazon.com/gp/product/B017FZF42G/ref=oh_aui_search_asin_title?ie=UTF8&psc=1

No particular reason for that other than something I had laying around that can drive the required current. i have everything DIN mounted, and at the moment using rj45 runs to control the motors and feedback for the encoders.

I guess now i need to learn how to use ROS.

Yeah, I'll be joining that club.

Hi! I started to make this a few weeks ago and the work is still in progress. These things take TIME. However I had already other half made robot in my shop and I was going to use some of the joints in my own robot. I researched further and ended up with modifying "compact planetary gearbox" found on Thingiverse. I made a video too, here is the link https://www.youtube.com/watch?v=aidAYsBgmcg

Thanks for inspiring work!

Love your thoughts on using the ESP32! I,m trying to work up one utilizing the Particle.io Argon and Xenon boards for a meshed network. Add motor driver and 9DOF for a system that always knows where each joint is relative the the others, 2- joints or 50-joints shouldn't matter. in process of designing boards to screw onto the back of the NEMA 17 steppers.

I'll have to print some of joints out and play with them!! What is the reach and payload?

The maximum shoulder-center to wrist-center distance is 15". I was shooting for a payload of about 1 lb., but the friction in the wrist actuators is still higher than I want, so the wrist joints are limited to about 1/2 lb. The shoulder and elbow joints, however, can easily handle a 1 lb load at full extension.

Jeff, it's so funny. I just realized you were the designer of my favorite 3d printed harmonic drive video on Youtube. https://www.youtube.com/watch?v=sdRGrTHq4hA

I presume you explored that harmonic design for this robot arm. Did it not work out? Were those plastic springs behind the harmonic gearing track not robust enough for the load?

The PLA version of the flex spline gave up after about 30 minutes of operation, but I printed another in PETG, which is still going. There would be a few problems in using the P.Harmonic drive with this robot, probably the biggest being that the gear teeth on the spline are pretty tiny, and I think they'd fail under the loads for the base joints. Also PETG doesn't wear very well, although that part could be reprinted in nylon. The diameter is too large for the small joints, and it'd take a little doing to get a much lower reduction ratio (~50:1 instead of ~150:1). The big plus for the P.Harmonic is that it is close to zero backlash without requiring the tight tolerances of the compound planetary. (BTW, I just noticed your comments on the video from 7 months ago talking about making an open source UR-type robot :)

Simply brilliant! Going to start printing tomorrow. Thanks for sharing.

Hoping you can help me troubleshoot again.......
I think everything is properly flashed and have successfully connected to your Ticsteptest program, but I am having trouble getting it to work as expected. For instance, if I turn on the speed mode, the motor will move for a short period and then stop. As I change the speed setting back and forth, I get varying results. I tried to do position mode and saw the same. When clicking through the step mode, I listened to the motor and could hear it change pitch with every step, but it wasn't really moving. I tried several different motors with the full range of settings with no change. Any ideas are appreciated.

With the motor moving and then stopping, you'll notice that there is a Min and Max position you can enter in the Position control section. These soft position limits are also active in velocity mode as a safety feature. (Sorry for the near total lack of documentation.) Set the Min and Max positions to very high values (say, +/-1000000000) to keep them from stopping your motor. I really should add a check box to disable soft position limiting.

When using single step mode, keep in mind that at the default of 1/8th stepping, if you are using a 200 step/rev motor, the motion from a single step will be nearly imperceptible.

OK. I changed the limit values for min and max and it definitely will continue forward, but I still cannot get any of my motors to turn in reverse. When going to a negative velocity or even a position less than current position, the motor will not respond even though the program is telling me the motor position is decreasing. I've tried on multiple motors without any of the actuator pieces to ensure they were not the reason for not moving backward but no success. Ideas?

Could you post a screen shot of the TicStepTest program with your settings?

I am not sure how it is happening, but it is not acting the same now as it was earlier. Now when I change the max speed to a negative and go left with the speed bar, it goes the same direction as positive to the right. I suppose I am going to try and re-flash the chip and see what happens.

Max speed should always be a positive number, so I'm not sure what is going on. I'm also not sure reflashing will help, but it won't hurt.

Okay, so I figured out how to make it go the backward. I had to change the max speed to a negative value and put the speed all the way left. To go forward, make it positive and go all the way right. Screenshot of my settings in positive direction here:

https://1drv.ms/u/s!AmGu4mSmjSxdgXM6JRilrLCMGr1S

I suppose I should be able to change this back and forth in run files, but looking at the circle test path file you wrote, it does not appear it will work with this behavior. I'm wondering what I am doing wrong.

Got my sensorless homing working this weekend on the robot arm using the TMC2130 stepper driver. Here's a video of it in action.

https://www.youtube.com/watch?v=NHvw9TKL92Q

Jeff, given that this sensorless homing is working for me (and I hope it keeps working), I know you had put that sunken channel into the actuator where you have a plastic end-stop in anticipation of some sort of end-stop solution. What do you think about a design where the part that bolts to the actuator could have the protruding element to hit that end-stop? And at the same time, also have an extra hunk of plastic that sinks into the Airsoft BB slot to contain the BB's? I'm having issues where, if the actuator is upside down, sometimes the airsoft BB's fall into that slot a bit and the actuator gets stuck.

Think we could kill 2 birds with one stone on a modified design?

Oh yeah, that would work. With all the actuators I've printed, the balls are really snug and show no signs of wanting to pop out (I have to force them out), so I've ignored this issue until now. Having something block the half of the hole on the inner race should do the trick. I'll include that when I get the rest of the hard stops figured out.

It only seems to happen on the small actuators where the BB's get stuck. On the medium and large it seems fine, although those axes are never upside down where gravity can pull at the bb's.

Hmm. For some reason the comment I posted, that I think you just responded to, isn't showing. It says "flagged for moderation."

I think that is a different comment that got flagged. The comment thread with my most recent comment is a bit further down. Try searching for "ChiliPeppr" in the comments - it's at the 5th instance. (I hate the way Thingiverse displays threaded comments...)

I finally got my shift register PCBs in that carry a DRV8825, SN74LVC3G17 buffers, and HCF4094YM013TR shift register. It works great! Just 5 wires running down the length of the arm, power, ground, data, clock, latch.

Controlling the whole arm with just a Teensy LC shifting the data out at 5MHz, and my own implementation of Bresenham. It's more than fast enough to get all the motors moving in 16th steps smoothly.

Working on a remote control teaching pendant now. Thanks for the great design!

That’s cool! Are you documenting the process somewhere we can check out? Thanks

One thing to consider is creating your own ChiliPeppr workspace for your approach. You could fork the workspace I already created. I attached a screenshot here. You can visit the workspace at http://chilipeppr.com/arm

The idea with the workspace is that ChiliPeppr is used by about 60k users each month for controlling Grbl-based and TinyG-based CNC machines. ChiliPeppr lets you send/receive commands to a serial port, typically to an AVR microcontroller, and control hardware from it via sending Gcode, sending config parameters, and getting real-time feedback from the controller.

With the workspace, I forked off the TinyG workspace, but then tweaked for the robot arm, you can see there are 6 axes where you can see the coordinates for each axis and do things like jog/home on each, move to a specific spot, etc.

You could then also write custom Gcode, load it into ChiliPeppr, and then play it to your control board. If you use an approach like Grbl or TinyG to buffer in the Gcode, then ChiliPeppr's Serial Port JSON Server could work without adding any new code.

If you play with the workspace you'll see you can click a part of it and you get a rotation object. Then you could position the arm virtually in the workspace and then send the coordinates to your axis.

Sounds very cool. Will you be posting your design and code anywhere?

Also I notice your step files have a new gripper design using the small stepper motor. Is that working out for you? I was considering designing a gripper from scratch with some flex/force sensors but haven't worked the details out yet.

The stepper driven gripper could use a little more gripping force. The reason I used the stepper motor version is because I couldn't coerce the Tic T500 driver to work with the small DC motor I used in the original gripper. (Basically, driving the DC motor from just one output phase of the stepper driver chip.) I've done this with other stepper drivers, but the MP6500 driver produces some pretty bizarre results.

Ah, gotcha.

I was thinking about making a small drv-sized board that fits on my shift register boards (got a few extras), with a micro on it that takes in "step/direction" pulses representing the desired force to apply. A simple P or PID on the micro would translate that into movements of the DC motor. Still haven't worked out the details on that though!

I'll post a make with details soon!

Hello, LoboCNC. Thank you for the project. I want to ask you something. I want to control this robot with the mega 2560 and ramps 1.4. Because the Tic 500 looks expensive. Could you add a design update for controlling with arduino?

I had the same idea, I have been looking this this guys setup and code also: https://youtu.be/Citiq6Zfdu4

To control this arm and gripper, you need a total of 7 axes of control. That would require 2 ramps setups, and even with that, it would be difficult to coordinate axis motions between the two controllers. Also, your cabling is going to get pretty hairy with wires for all 7 motors having to come all the way down the arm.

Amazing! Time to break out the arduinos/breadboards and get the printer dusted off.

Hi LoboCNC,

Got a couple more questions I'm hoping you can answer. Does your MPlab program for the PIC18F25K50 chip rewrite the LED functions of the chip? I felt like I had everything right on programming with the PicKit4 using MPlab "Make and Program Device" function appeared to work correctly. When I connected everything together, I did not get any lights on my Tic500 and I was unable to figure out how to make the TicStepTest utility connect to the board and drive the motor. The USB-TTL adapter you suggested worked great and connects as COM4 so I chose that option, but I am not sure how to make the module and address stuff work to connect to the motor. I only connected RX and TX wires from the USB-TTL adapter to the board along with power supply and motor connections..... Am I doing something obviously wrong?

Thanks,
Dylan

Yes, I reprogrammed the LED function. With my firmware, the LED only lights up when you move. As for getting connected, you should connect the RX, TX and Ground wires from your USB-serial TTL converter. The ground connection is required. You should also make sure that your converter is operating wiht 5v signal levels rather than 3.3v signal levels.

I've connected the ground from the USB-TTL line but am still getting the same issue. What's happening is that the TicStepTest program won't let me interact with any of the controls below the mod address stuff. I figured I would set the mod address as 1 and group address as 01 (also tried 00, 128, FF, etc), but after I tried to click the Module Address "1" radio button, it says no response from the module. Any advice you can provide to help troubleshoot is greatly appreciated.

-Thanks

When you reprogram the Tic board, it sets the default address to 1. So when you run the TicStepTest program, you first click on the COM port, and if the COM port is valid, it will enable the address selection block to the right. If you then select address 1, if all is OK, the rest of the controls will be enabled. If things aren't working, you'll get an error message "no response from module". Is this what you are seeing?

Yes, that is exactly what I am seeing. The MPlab program said it “found” the microchip so I assume I had everything correctly connected and everything worked on the programming. Is there any way to ensure the program uploaded correctly to the chip, or other diagnostics you can recommend?

Diagnosing these things is a little tricky when there are so many parts that just have to work right before you can get any feedback. The ideal thing would be to look at the RX and TX signals on an oscilloscope and then use serial data analyzer, but that's out of the question for most people. Have you verified that your USB serial port converter is using 5v logic level signals rather than 3.3v?

I bought the converter you recommended. It has options for both 5v and 3.3. I’ve connected to the 5v output and verified with DMM I am getting 5V output. Any way a DMM can at least detect a signal on the tx and rx lines? I really feel like my weakest area is MPlab but I have gone through the tutorials and believe I did everything right on uploading to the hardware. I connected per diagram on page 20 of the MPlab pickit 4 manual, except I also routed VDD to power the chip and changed those settings in MPlab to enable pickit to power. Used a 36kOhm resistor.

Oh, one other thing I just remembered about the CH340G USB converter - I had to make a couple of mods to get it to work reliably:
1) There are RX and TX LED's which seemed to draw too much current when trying to communicate with multiple Tic boards. I disabled these LED's by removing the 2 current limiting resistors located between the 12Mhz crystal and the RXD and GND pins on the end connector.
2) I added a 4.3K pull-up resistor between the Vcc pin and the RXD pin.
I don't know if these changes would be needed to talk to just one Tic board, but I needed them when talking to all 7 boards on the robot.

Maybe what I'll do is modify the code so that when you first power up the board, the LED lights for 1 second and then shuts off. This way, you'll know that your board has been programmed correctly. Stay tuned...

Hi LoboCNC,

Just to make sure I am not going to mess this up, can you please confirm I am planning on removing the right resistors from this chip? Picture at link below shows red lines through the resistors I think we are talking about.

https://1drv.ms/u/s!Aps_ODSz7U0ahKx7IxjpxFa_QqPw1Q

Thanks,
Dylan

Yes, those are the right resistors to remove. However, I also noticed that your yellow jumper may be in the wrong position. It should be connecting the 5V pin to the Vcc pin. And also, it looks like you have 4 wires connected to the converter, presumably RX, TX, GND and 5v. You should only have RX, TX and GND connected. You should not be trying to power the Tic board with the 5v as it is already being powered by a separate motor supply. (Unfortunately, it's next to impossible to find any real documentation on these really cheap USB adapters.)

Thanks LoboCNC! I didn't think the jumper or the 5V connections mattered in this configuration so I didn't think I needed to move it. I already had a double twisted pair of wire so I just used that and had the extra wire so I plugged it into the USB converter, but nothing on the other end.

I did switch the yellow jumper and tried again, but still same results. I am going to attempt to modify the converter now. Thanks again.

So I my friend pointed out my basic ignorance of these types of connections. I did not understand that RX is receive and TX is transmit so I needed to switch those inputs between the USB input and output onto the TIC board. I've got your program working now. Next stop is to get multiple motors running a program and then I'm home free for making the full robot. Thanks!

Hey, great project! Is it possible to control the arm with Tic boards over Arudino?

Yes, the Tic controller boards with my custom firmware can be controlled from any standard TTL level (5v signals) serial port, although you'd have to generate the software for driving the arm.

Working on ChiliPeppr workspace for this robot arm. Making progress...
http://chilipeppr.com/arm

Very cool! Where's the best place to get basic information on exactly what Chilipeppr is and how and why you'd use it?

Here's a walkthrough video of how ChiliPeppr is used to control CNC machines. The idea is that this robot arm will run Gcode as well and thus you can just extend ChiliPeppr to send that Gcode to the robot arm instead of just to a plain old CNC machine.

https://www.youtube.com/watch?v=mKLdgpz8gpQ

ChiliPeppr is an open source environment to create front-ends in the web browser for hardware machine control.

Even the Arduino web development environment uses the ChiliPeppr Serial Port JSON Server (SPJS) becase it's so rad, which is the app you run on your desktop/raspberry pi to talk to serial ports and expose them via a websocket to the browser. I don't think we'll need Serial Port JSON Server for this project since I think I can have the ChiliPeppr Robot Arm workspace talk direct over websockets to the 6 ESP32's I'm builiding into the robot arm, but for now SPJS is helpful because it lets you send TCP and UDP packets from the browser to the ESP32's and back.

The other video to watch is what Cayenn is, which is a protocol I created as part of ChiliPeppr to talk to ESP8266's or ESP32's from Gcode in a distributed way. https://www.youtube.com/watch?v=SlHhcErWCDQ

This is the technique I'm looking to use to write Gcode that then gets uploaded to each ESP32 and then run in coordinated, yet distributed, fashion.

Thanks for the detailed explanation. So if I understand correctly, ChiliPeppr is essentially a machine controller that just feeds g-code to the machine hardware, and also provides a user interface to other machine control functions. So with your arm implementation, each joint controller is accepting g-code from ChiliPeppr. What I can't quite wrap my head around is exactly how the 6 axis controllers coordinate their motion. Are all axes receiving the same 6-axis g-code commands, running the full 6-axis path planning algorithm, but then each only controls a single joint? This would then imply that the individual crystals on each joint controller are used to maintain synchronization - is that correct?

Yes, your take is pretty much spot on. On your question of how they coordinate motion, that's why that Youtube video I shared above on Cayenn protocol sort of helps you understand it. It shows syncing lasers that are running on their own ESP8266's with a main CNC controller.

What happens is the Gcode is parsed by ChiliPeppr and ONLY the Gcode commands for each actuator are sent to it via Wifi. The ESP32 stores the Gcode on its local flash memory. The key is that line numbers are added to the Gcode by ChiliPeppr. There is a sync signal wire to each actuator. The base actuator, acting as the master, starts playing the Gcode by sending a pulse on the sync wire. Each ESP32, including the master, count that pulse as line 1 of Gcode. If any actuators have a line 1, they all start playing that line at exactly the same time.

The next key item is that the master has to know how long to wait before sending the next sync signal. So, how do we know the timing?

The idea is to get back an execution time from each ESP32 as you send it a line of Gcode. So, the ESP32 will parse it and pass back how long it will take to execute back to the master. The master ESP32 records the lengths coming back for each line and then just waits the length of the longest move. This probably only results in 1ms resolution, but I think that should be good enough. I can't see a need for something more precise, but experimentation will tell.

Now, you might be asking what about feed rates where you want the actuators to start and end at the same time, but the base has a longer move than the arm? Well, the master ESP32 will see the longest move, and then ask the shorter move to extend the length of that move by reducing its feed rate. So, it sends the longer time over Wifi to the ESP32 and ask it to recalculate its move to a slower speed. This is essentially what happens on a CNC controller when there's an XY move on the same line. It slows down the shorter move to have them stop and start at the same time. There's no reason that can't be done a bit differently here.

There can also be indeterminate moves and pauses from each actuator, especially grippers or end-units like dispensers. In that case the master will just wait for a signal back from an ESP32. These would be for moves where it's ok to wait. Let's say you have a gripper that has a start gripping command. Maybe that gripper has force feedback. The line of Gcode, when parsed by the end gripper, would have sent back a "wait for receipt" instead of a time. That would make the master just wait for a Wifi signal back instead of counting on a timer. Then when the gripper says it's got the thing in its hand, the master sends the next sync signal to play the next line of Gcode. This is sort of like the wait command on 3D printers where they wait for the temperature on the heated bed until resuming play.

This gives huge flexibility to adding on stuff later rather than relying on a main controller to do everything. It also gives a richer, more intelligent robot arm. Let's say that an actuator freezes. Maybe one of the airsoft bb's got stuck. It could detect that it's stuck and send a signal back over Wifi. The master could then pause the Gcode, wait for a fix, the actuator could get re-homed, and then the Gcode could play that line again. All of those commands would be over Wifi since they aren't timing sensitive. The only time sensitive stuff is the sync signal.

It's all theory though beyond what I show in that video. Much of what I'm describing would be new code to get it to work.

Again, amazing work! Thanks for the video.

hello, I'm designing a 3d printer for a job from my college, I'm thinking of putting a 3-color diamond hotend! I wonder if in the actuator it would withstand the force of the extruder by pushing the filament to the hotend without the actuator losing the alignment, and spoiling the quality of the 3d impression, or even being imperfect or faulty. summarizing, will the actuator support the kinetic force of the filament that is forced on the hotend without there being any misalignment in the actuator that will be attached to the hotend? thank you very much...

I'm new to 3-D printing and have very little experience with robotics, but I am going to give this a go one step at a time. First I'd like to just try building one of the large actuators and playing around with programming it on my computer with the TIC controller. I'm hoping this might get me spinning some motors and seeing how everything works before I have to get too deep into firmware modifications and custom software. Any advise anyone can provide on my journey would be greatly appreciated. I've ordered a TIC controller, NEMA 17 motor, and can pick up the screws and wires local. Can you please recommend a power supply and/or share the make and model of the one you are using in this design? What else am I missing to get started?

Good decision to tackle this project incrementally, especially if you don't have much experience. As for the power supply, I am using a generic 75w, 19v laptop supply. These are insanely cheap (<$10) and pretty widely available.

Hoping you can answer a question for me. How did you connect the Tic T500 to the computer and have it recognized as a COM port to be tested with the TicStepTest program? I thought wiring a USB cable into the serial connection ports would do it, but it is not showing as connected to the computer when I do it that way.

Thanks,
Dylan

The TicStepTest program I wrote is only for use with the custom firmware I also wrote for the Tic T500. If you are using the stock Tic T500 firmware, you need to use Pololu's test software found here: https://www.pololu.com/product/3135/resources

Using my custom firmware is quite a bit more involved and requires you to re-flash the PIC18F25K50 microcontroller using a PicKit 4 programming tool from Microchip.

Okay Thanks! I have already been playing around with the Pololu software. I thought I might be able to play around with your program without the new firmware while I waited for the PicKit tool to show up. I ordered the PicKit4 tool a few days ago so I should get that in the mail any day. I'm hoping I'll be able to follow your instructions and the online manuals for the PicKit4 to get the firmware installed. From there, if I connect my spliced USB cable into the serial TX, RX, Ground, and V-out pins on the Tic T500, will it show up as a COM port on my computer?

Just curious, is there any other software that would allow me to write and run motor programs?

Thanks,
Dylan

You can't really just use a spliced USB cable and connect to the RX, TX and GND -- USB and standard asynchronous serial TTL are completely different beasts. Also, any software for driving motors would have to be written explicitly for what ever controller boards you are using as there is no standard for motor commands (outside of controller boards that run a g-code interpreter). You could check the Pololu forums to see what other software might be available for talking to their standard Tic controllers.

Sorry if I’m being dense. I suppose the more direct question would be, how are you connecting your tic to the computer once you’ve reprogrammed the microchip?

Oh, sorry, I forgot to mention how you actually do connect. You need to get a USB to serial TTL converter like this one:https://www.ebay.com/itm/6-Pin-USB-2-0-to-TTL-UART-Module-Serial-Converter-CH340G-Module-STC-5V-3-3V/223171155058?epid=19007644191&hash=item33f6099472:g:vuIAAOSwFzZbsoN6 There are a bunch of different versions using different converter chips, but you want one that will operate with 5v RX and TX signals.

Hi LoboCNC,

Again, I greatly appreciate your responses.

Is there any reason it would not work to just program 1 tic and run one motor using your TicStepTest program? I just wanted to make sure I could do everything on one before I went further.

Thanks!

Yes, definitely - start by reprogramming just one TicTep and then play around with the TicStepTest program. It is a very general program that can deal anywhere from 1 to 10 axes.

Well.... I think I just cooked my pickit4. Thought I had everything hooked up right, but when I powered on it flickered, turned off, and stunk like burnt electronics. I thought Pickit pin 1 goes to RST pin on Tic500, pin 4 to PGD, pin 5 to PGC, Pin 2 to the power supply, and Pin 3 to ground, but it fried when I turned it on. I'm guessing I pin 2 was supposed to be the power supply for the chip? Doh!

Thanks

Ouch! Yeah, you have to be pretty careful in hooking up the programmer. Pin 2 is an output power pin that you can optionally use to power the Tic board from PICKit4 (the power comes from your USB port). Hooking this up to a separate power supply will definitely fry things. Also, you do not want to connect pin 2 (Vdd) to the Tic board at all if the Tic board is powered separately. Just for reprogramming, I sometimes have the Tic board powered by the PICKit4, but don't try to run a motor this way! In any case, make sure to follow the PICKit4 documentation very carefully.

I just want to give a big shout out to microchip.com. I emailed them and told them that I screwed up and wired it wrong. I asked if they sold the microchips on the board so that I might replace the one I burnt or if they could repair it, and they just responded with an email saying a new one was on its way. Unfortunately, I had already bought a replacement, but I still really appreciate the service.

I've been trying to get one of the small motor's from Moon's to run off the Pololu software, but I keep getting safe start violations on my Tic500. I've tried a lot of different current limits and speeds to no avail. Any pointers you have for getting the Moon's motors to run?

Thanks!

Nevermind... not sure what was up but I took it apart and ran it without the planetary gear attached and it worked fine. Usually when there was too much force, the motor would try to go so I really don't know..

Hi!

Cool project! would it be possible to get the editable CAD files? I would like to explore the design a little bit and also adapt the base of the arm to my already existing inspection platform.
Br,

Dag

The CAD file are posted in STEP format in the file WE-2.4.STEP.ZIP.

Comments deleted.

I have an idea-why printing entire arms? U can use very cheap(1m long 110mm diameter=about 1-2$) and tough(comparision to printed parts) hydraulic PCV pipes for straight part of arm. This will save a lot of printing time and filament. I think u can use PCV 90' "knee" for joints body too, just fit gears and motors inside. PCV pipes are cheap, common, tough and standardized by dimensions.

Sounds like an interesting design challenge! My gut feeling is that it won't save that much printing and would end up being bulkier, but I'd be happy to be proven wrong.

I can try, but now i have a big project on desk for next weeks(or months-will see). You are right, this can be a bit heavy with pcv pipes as body.
I don't have slicer here(i am at work now :P ), but i think we can save about 50% filament and printing time without straight parts of arm(50% of printing time/filament for these parts, not for entire machine).

I tried to make this arm and had made the largest actuator and it works well, but I found it is hard to assemble the shoulder plate or the upper arm to the ring of the actuator, because of the toleration of length of screws, if it is too long it will conflict with the planet gears, if it is too short it can not touch the thread in the nuts. Did I do something wrong or you have the same problem?

I designed the mating parts so that standard length imperial screws would just grab the nuts but not protrude into the gearbox. Are you using 3/8" long 6-32 screws?

The imperial screws and nuts are not common used here so I modify the nut and screw used in the largest actuator to M5, the screws I am using is 10mm long, I cut it a little it can work, but I still think is it better to make the plate in the actuator more thicker, then it will have more tolerance, but that has to modify a lot of other parts and not sure is it a solution?

Rather than just making plates thicker, what I really need to do is make a metric version for (the rest of the world) that uses common metric screw lengths.

Wow, that is very good. I love this design, thank you very much! I think I have to take a month to build this arm.

What gauge wire do you think you need for the motor power wiring? I'm running all steppers at 24V so that doesn't need very high gauge, I think, since the stepper driver does the chopping. The NEMA 17's need more power than the micro steppers, so I assume I could even reduce gauge from joint to joint. Thoughts?

I ran 24g wire for power. My controllers located at the joints and am driving nominal 3 or 5v motor with 24v, so the current draw is pretty low. Also, with the bigger motors towards the base, most of the current is dropped over shorter lengths of wire. I'm running a 4-wire bus and I'd love to use this cabling (https://www.digikey.com/product-detail/en/alpha-wire/78072-SL005/78072SL005-ND/4988193) which has a jacket diameter of only 0.162". The 2-wire version is only 0.112". Dropping down to 26g (0.102") or 28g (0.094") would save you a tiny bit more, which I'd only do if it was really necessary.

Can I convert the robot arm to a 3D printer? Tolerance doesn’t matter for me!

You could, but it would be a ton of work and it probably wouldn't work very well.

Jeff, my video of your robot arm is going viral on Youtube right now. Wow. I didn't realize how much excitement there would be for a quickie video I whipped up on a Saturady, although, then again, I love your design too. https://www.youtube.com/watch?v=tEbJV32GyYU

The video is excellent. I hope you do more as build progresses as I am very interested in making this arm.

It's an excellent video - thanks for doing it. Would you mind me adding a link to it in the main Thing description? Very interesting about it going viral. I guess you never know what will pique people's interest.

I would love for you to add the link. Yes.

Hi, can the custom firmware support record-replay? Move the arm to record, then replay those movements.

With open-loop stepper motors (no encoders) there is no way to tell where you have moved the arm to record the position. Also, the compound planetary gearboxes are not really backdrivable, so you can't really move the arm around by hand, anyway. What' I'd like to do is put on a 6-axis force sensor to allow you to guide the arm around by hand with the motors actively driven - that'd be the best way to implement record & replay.

hola cuando estará completado este proyecto para poder descargarlo?

You can download the parts now and print them. On a project like this, there will always be some changes with improvements to various parts, but what is posted now is certainly functional.

Full video walkthrough of my assembly of the actuators and robot arm.
https://www.youtube.com/watch?v=tEbJV32GyYU

Excellent video! I'm amazed that you've gotten so far on this project so quickly, especially with your renegade nut mishap. I'll look forward to seeing what you do with for your controller.

Well, your design and description is really slick. I ordered all of the screws and stepper motors based on your specs so it helped that I perfectly mimicked your parts list. I've definitely leaned on the CAD design in Fusion 360 as well to figure out how to put all of it together as well (would still love the latest update of the CAD though. I tried your newest files you said you posted, but there was nothing different in there.) I have been running my printer non-stop for about 10 days to get to this point.

I am writing code right now for my ESP32's which I'm going to put in each joint. Each ESP32 will receive Gcode from ChiliPeppr via Wifi so I will be able to just run 2 wires to each joint for 24v power. I'm pretty excited for how that can come together. A typical chunk of Gcode would look like: "G1 F200 X2000 Y3000 Z500 A234 B111 C222 D300" where XYZ are base, shoulder, elbow. ABC are the wrists. D is the gripper. The units are in steps, not degrees. The feedrate is in steps/s. You would train the Gcode by a joystick I'd attach to each joint talking direct to the ESP32. Then you're training it like a UR3 but of course from a joystick rather than pressure sensing on the joint. The step values are sent back to ChiliPeppr on-the-fly as you train and then ChiliPeppr records the position for each axis to create the trained location.

It's all theory until put into practice, but your design is awesome and it's something I've wanted to do for a long time but never had the time to do the CAD design for.

Comments deleted.

Hi,
How to start the system, please provide wiring diagram for connections, write how to control the robot.
Your movie is very good.

Comments deleted.

Got an actuator and arm going with a hall effect sensor as potential endstop. https://www.youtube.com/watch?v=yCEXC0kEk3Y

I want to know how the previous limb of the arm is connected next arm for the movement of the robotic arm
there is no clue how the motor is going to work or attached

If you look at my Robot Actuators thing (https://www.thingiverse.com/thing:3293562) you will find more details on assembling the motors to the gearheads.

Robot Actuators
by LoboCNC

When You make your full manual, could you aslo add a price-range to see how much 1 of them costs? Because I see some real possible production assembly libes with this, not heavy industry but imagine a 3D-printer assembly line, just the nuts and bolts part of the frame could get you some pre-mounted frames over-night, all you need to do is add the electronics and the wiring, and sell your 3D-printers or anything else that could be repeated indefinitely

Yes, I'll definitely add cost estimates.

This is an awesome project. I'll be following with keen interest. :)

Hi

I have started primt this project, but, i am beginner in electronic, do you have a forum for this project?

Unfortunately, there is no forum for this project yet. Regarding the electronics, I've written up documentation on the modified firmware used for the Tic T500 boards, but the hardest part is actually getting my modified firmware flashed onto the board. You could try contacting Pololu and ask them if it is possible to buy the board with my firmware pre-flashed onto the board. I've talked to them about doing this and they didn't seem interested, but if enough people inquired, they might change their minds.

I am building this arm now. Several parts to print still.

On the electronics side of things.. I designed a very small pcb (more or less the size of a DRV8825 Pololu board basically) that carries a pretty high frequency 8-bit D-type shift register, as well as pin headers for the Pololu DRV8825. The 8 bits are step, dir, enable, m0-2, and 2 LED's (cause why not, I have 8 bits and was only using 6!) Each motor gets a shift register & drv. I'm going to daisy chain them together so that the control board just has to shift out one byte per motor (using the SPI of Teensy) and then toggle the latch pin on the bus.

From my quick math it should be really easy to get >20kHz step rate or more. It just needs 3 control lines: data, clock, and latch. One more wire than tx/rx, but still pretty manageable. Boards will be here in a week, I'll let you know how then turn out.

Just bought all the steppers. About $60 from onlinestepper for the 3 NEMA 17's with shipping. About $80 for the 4 small 35PM048S8-08001 from Moon's. Adds up but excited to get this going. Given that the small steppers don't have flat shafts, how are you attaching those to the plastic? I haven't printed those parts yet.

For the small motors, I used a 3mm drill bit to clean up the bore on the gear and then secured it with a drop of superglue. You have to be very careful, though, not to get any glue in the shaft bushing.

I just printed the base. Looking good. Nice work on this Jeff. I attached a photo of my print with the NEMA 17 stepper mounted.

Hi,
How do you do all the axes homing, do you have any idea?

The plan for homing is to run each joint up against a hard-stop joint limit. However, some of the details of the hard-stops are still listed in the "Stuff Still to Do...." section.

Comments deleted.

Hi! I was wondering what the estimated total cost is for the robot... also, is it compatible with Mac OS X?

Overall, this project will end up costing $300-$400. The rough breakdown is: motors ~$10 ea, controller boards $20 ea, PIC programmer $50, filament ~$25, misc hardware ~$25, shipping and all those other little things ~$50.

The only software that currently exist for running this robot is my very rudimentary TicStepTest program which only runs under Windows, so you'd need to be able to boot into Windows OS on your Mac. I'd love to see someone implement control of this robot using ROS, but that's beyond me at the moment.

could you put a hyperlink to buy each component? I would love to have the right materials, thank you

Kéven

Thanks for the reply! Unfortunately, no Mac support is a huge drawback for me :(

Amazing work, not just visually, but mechanically as well. Thanks for sharing!
I have a few questions:
How much is the payload and repeatability?
Have you heard about the Mechaduino nema17 stepper driver? It has a magnetic encoder and motor current sensing, so you can have torque control; with these you will be able to build a collaborative robot arm, which means you can program gravity/friction compensation, teach mode, collision detection etc.

As for the payload, the shoulder and elbow joints are good for about a pound at full extension. Right now, the wrist joints Are the limiting factor as the little 35mm steppers barely overcome the startup friction of 3D printed gearhead. When the gripper is extended, the first wrist joint (J4) and only lift about 1/2 lb. The tricky part is getting the 40p gears printed cleanly enough for both low-friction and low-backlash. I'm using a 0.35mm nozzle, but I really need to try reprinting with a 0.25mm nozzle. I'm tempted to get SLS versions of the wrist actuators printed, but that takes this out of the realm of a DIY hobby project.

As for repeatability, I haven't measured this with any accuracy yet. However, unidirectional repeatability (approaching a point from the same direction each time) is maybe about a millimeter, and less so for multidirectional repeatability (even with a gravity bias on the joints.)

Hey, thanks!. Yes, I am familiar with the Mechaduino (I've got a couple floating around). I'm definitely a big fan of closed-loop stepper control, but there are a couple of reasons I didn't go that route: I needed something to use with the smaller 35mm tin-can wrist motors that don't have a good backshaft for the encoder magnet, the board is a little bigger than I'd like, I would have had to do a lot of modification to the code to support coordinated motion and 4-wire bus communications, and they are a little more expensive than I'd like for a hobby project.. The bigger thing, though is that the 3D printed compound planetary are non-backdrivable which makes many of the features you mention extremely difficult to implement effectively. (I've used to have a company selling force-controlled robots many many years ago.) For a more serious robot development, though, I'd definitely go to the extra effort of closed-loop control.

Hi LoboCNC, I would love to make a build with closed-loop control for more precise movements than open loop. I have more experience on the software side of robotics and less with hardware. So I have a few questions on modifying the structure of this design.

  1. First off, in your opinion, how much would the "extra effort" to convert this project to using closed-loop control be in terms of structure/motors?

  2. Do you have any recommendations for motors for closed-loop control that would work best with this design with little modification to the structure of the arm? Possibly swapping out the 35mm tin-can wrist motors for more expensive ones with feedback?

  3. You mention that "3D printed compound planetary are non-backdrivable". Is this design by choice? If so, why? And, if I wanted to modify the actuator to allow for backdriveablitiy, do you have any recommendations on doing so?

Good questions:

  1. Mechanically, I don't think it would be too much effort if you used something like the Mechaduino controllers mentioned above. THe bigger issue is cabling. You really only want to run a single cable with as few wires as possible up the arm.

  2. The Mechduino controllers work well with NEMA 17's, so no change there. On the wrist joints, you could use a flat NEMA 14 like this one: https://www.omc-stepperonline.com/nema-14-stepper-motor/round-nema-14-bipolar-09deg-5ncm-708ozin-05a-85v-%CF%8636x12mm-4-wires-14hr05-0504s.html

  3. In theory, the compound planetary gearheads should be backdrivable, but given the high ratio and the relative imprecision of 3D printed gears, you'll probably break teeth before you could make it backdrive. I'd love to have a more backdrivable gearhead, but that's a tall order with 3D printed gears in a small package.

Thank you for the quick response! I will be sure to let you know how the project goes.

Thanks for the detailed answers!
Having a force-controlled robot company sounds awesome, can you share more info about the robots you used to sell?
I'm planning to build a 7axis(4 torque controlled stepper + 3 torque controlled smart servo) open source 3d printable robot arm based on the Barret WAM arm, I planning to use timing belts and differential cable drives, hopefully with this design i can have a fully torque controlled collaborative arm. I have no experience in building robot arms, so what do you think, is this a good direction?

The company was Zebra Robotics, and back in the early 90's I sold a handful of force controlled robots to mostly university and corporate research labs. The arm had a 6-axis wrist force sensor and I used a novel stiffness model approach where I mapped desired forces into deflections of the actuators. Here's a link to an ancient video I did: https://youtu.be/7dl0U3rq9Ss

Regarding your proposed project, designing a robot arm is tricky enough, but designing one for low-level torque control is even more ambitious because you need a full dynamic model of the arm, very low friction actuators and a low-mass arm. A simpler approach is to use a 6-axis force sensor, although this doesn't help you detecting collisions at, say, the elbow.

Thanks for sharing the video, awesome robot arm and demonstration, this tech is pretty advanced even with today's standards.
If I have the time, I'll make the robot arm without the force sensing capabilities, then I'll start figuring out how to add the torque sensors.
Thanks for the advice!

Hi,
I will be grateful for your help in flashing.

Another option that occurred to me regarding re-flashing the firmware, you could try contacting Pololu and ask them if it is possible to buy the board with my firmware pre-flashed onto the board. I've talked to them about doing this and they didn't seem interested, but if enough people inquired, they might change their minds.

Here's a video that might help you get started with reflashing the Tic T500: https://www.youtube.com/watch?v=81ho9Y28dXI. Note you'll also need to refer to my firmware modification PDF file to see where to connect up the pins PGC, PGD, Vcc, GND and Reset.

Thank you very much for the movie.
I still have a question - is Vcc, it means Vin or 5V (outside)? Mark on the Tica board.

When connecting the PICKIT 4 to the Tic T500 board, you should connect the PICKIT's Vdd to the Tic's +5v (out) pin, and the PICKIT's Vpp to the Tic's RST pin. Also connect GND to GND, PGD to PGD and PGC to PGC.

Thanks for the tips.
Now I will know and I will not make a mistake.

After reading your pdf, I have a question about addressing.
Can you write to me punt after point as you approach the addressing of individual points.
I mean, how should the host and other modules be set up. Can you send me an example
print scren settings. I think I can have a problem here, that's why I'm asking. (how to set up the host, and set other modules)?

When I get a little more time, I can work on a tutorial setting up the host serial port, programming and configuring the modules, etc..

In that case, I will wait patiently for your toturial, I hope you will find moments in the near future.

Hi,
Thank you for your response.
I have looked through the files and I have to say that the biggest difficulty for me is loading the tic firmware.
Are you able to write a short instruction for this fragment, how to do it step by step (eg connecting wires, which file to upload?), Or screenshots?

Yes, having to re-flash the microcontroller is unfortunate. Firstly, you will need a PIC programmer - probably the PICKIT 4 (https://www.digikey.com/product-detail/en/microchip-technology/PG164140/PG164140-ND/8536593) is the cheapest and easiest option. Microchip (who makes the PIC processors) has a bunch of video tutorial - I'll have to look around and see if I can find one most closely applicable.

Thanks LoboCnc,
I will post a picture when I build this.

Hi, I would also like to participate. Please post the STEP file.

Hi,
Can you publish an electrical connection, diagram?

Here's a link to a shared Google Drive folder with documentation on the modified Tic T500 controller boards, and also the firmware source code and Windows test utility program. The PDF file in there includes connection information. Let me know if you have any questions.

https://drive.google.com/drive/folders/1rKRuWC4jAOekrds_WGUC7DkwlVsk2zdb

This is a very nice design.
I would also like to participate. Please post the STEP file.

Any chances getting anything more then just STLs? I would love to participate.

Sure! I'd be thrilled to have any help or input on this project. I'm using Solidworks 2011, so I could post those files or I could post STEP files - which would work for you?

Any chance you can upload the solidworks assembly?

STEP will do. I work with Fusion 360 (Solidworks was out of reach financially =) Usually it is good with importing whole assembly thing from Solidworks.

A step file of the entire assembly has been posted. I welcome the shared enthusiasm!

This is incredibly cool.

Have you thought about an approach based on Trinamic drivers-- since they have programmable current per phase and stall detection, so you can detect when you lose steps and also detect when you have reached endstops for homing?

Thanks for your comments! Yes, stall detection would be pretty handy, but the Tic controllers had the right form factor and I had the ability to reprogram them with code to support coordinated motion with distributed controllers.

About the Gripper
What about using a Linear Actuator and a cable (like a bicycle brake caliper)?
In my opinion that would get the noisy stuff off the arm and also might be stronger then any motor you could put on the arm.
Running the cable might be a problem though...
All in all it seems like a well done project, Good Work

A brake caliper gripper sounds like a good idea, although the cable sheaths are really stiff. I could see this working for a particular application but it might be a bit cumbersome for general use.

There are "ceramic bike cables" https://www.vertebr.ae/, maybe 3D printed shell will be elastic and stiff enough ?Just drooping an idea...