Controlling Motorized rigs - Arduino or Raspberry Pi?

Have questions about the equipment used for macro- or micro- photography? Post those questions in this forum.

Moderators: rjlittlefield, ChrisR, Chris S., Pau

bhf
Posts: 5
Joined: Thu Dec 26, 2019 7:38 pm
Location: kirkland, wa

Controlling Motorized rigs - Arduino or Raspberry Pi?

Post by bhf »

Hello, hope everyone is doing well.

My main goal with the post is to figure out what computer platform is going to control these two rigs I have going, but below is general info (& other questions) for those interested & to help determine which one might have suitable code already for my two uses.

Feel free to skip all the detail if you have knowledge about either of these platforms when it comes to controlling stepper motors for photographic applications. I am not a coder and have been assuming I would be able to hobble through altering an existing Arduino sketch or even considered GRBL/gcode cnc applications to control the stepper motors. I don't really know about the options on Raspberry, but saw this post https://www.photomacrography.net/forum/ ... =projector which made me think of the platform


1) I am repurposing a motorized microscope to become a 4x5/smaller film scanner. It has an x/y axis split between a specimen stage and the axis that controls the tube/camera. I replaced the vertical mount that held the original navitar tubes with an L bracket that has an arca swiss clamp on top.

The main reason for that decision was to be able to offset the camera and center the lens so that I still got the extreme edges of the specimen stage in frame. I have a working area a little bigger than 4"x5" so happy my guess that I had enough was correct.

I have been figuring out which lens gives good working distance & a mag range of .75 - 1.5x, and after trying a few arrangements I think a 80mm is going to be the best fit. Going to give the componon-s f4 makro a try soon. If someone has another lens suggestion let me know.

I anticipate not really needing the WeMacro rail in the end and might replace the L bracket entirely and have an arca swiss slamp mounted vertically with a manually controlled rail for z adjustment. If I set this up properly my assumption is I won't really need to stack (?) and will have enough DoF shoot film.

Originally I was going to make this a general purpose rig but found another item on ebay that I decided to adapt :)

(scroll past first rig pics)

**the motors featured in the pictures below, does anyone know if they can be controlled on Arduino or the Raspberry Pi? I am anticipating having to replace them with new stepper motors but it would be great to not have to unmount them and re-use**

Image
Image
Image
Image
Image
Image



2) repurposed inspection device from semiconductor factory. It came with a componon-s 28mm 2.8 housed in a tube with an led illuminator & mirror (collimator? I plan on researching more). I neglected to take pics of both rigs before I started stripping them down, but I will probably post pics of the tube/mirror on this one later because I want to use it as well and I am sure someone here will know a lot about it.

This device also had two rails originally, one to adjust the camera platform relative to the lens (removed top section) and the other I left that was used to adjust camera/subject distance. I am just going to use it for rough manual camera/subject adjustment and pair it with the WeMacro for actual stacking.

Where additional motorization comes in on this rig is the last pic. I want to create an xy platform for the subject by pairing this with an old Edelkrone video camera slider I don't use. The slider would function as an x axis, mount it on two carrier rails and create a longer y axis. The carrier rails will be moved by a lead screw underneath like a cnc router. Orient the vertical column to be perpendicular to the subject platform and I think I'm in business

So just like the film scanner, I am basically only looking to control an xy (I suppose Z if any code/applications worked with the WeMacro rail) axis. I would love to be able to get both realtime control on top of the requirement of being able to run a series of preprogrammed shots to scan the film/area with a ff dslr.

Lenses & tubes:

I am going to use the 28mm and couple it with the makro symar 120mm 5.6 I got https://www.photomacrography.net/forum/ ... ight=120mm

I have some 52mm tubes (both from the Melles Griot machines lenses as well as a Nikon K set) per Robert Otoole's excellent suggestions, but hoping I can find adaptors and clamps for those to mount to an arca swiss rail instead of going the Thorlabs rout here https://www.closeuphotography.com/makro ... lens-stack

Does anyone know if that's possible?

Utimately I want to use this for 1-5x and hopefully up to 20x once I get the objectives. I also have a Mitutoyo 5x APO Plan that I got from the first one, and am going to see if I get decent results to pair it with an older Nikkor 80-200 2.8D (brutally sharp at 135mm & still good at 200mm). Also my prestigious craigslist $10 pickup the Vivitar 75-205mm f3.8, which takes surprisingly sharp pics at 205mm and figured why not see.

Well God Bless You if you made it this far and stay safe!

Image
Image
Image
Image
Image
[/url] :D :D

enricosavazzi
Posts: 1474
Joined: Sat Nov 21, 2009 2:41 pm
Location: Västerås, Sweden
Contact:

Post by enricosavazzi »

If you are considering a choice of Arduino or Raspberry Pi, I think the following are the most important criteria:

Real-time control of stepper motor: The Arduino software runs directly on the hardware (only the built-in system timer is competing for CPU time and resources with your main thread), and precise timings (within limitations of the CPU clock) are easier to implement. It is for example easy to issue a sequence of step signals with the desired timings. The Pi runs a complex operating system (typically Debian Linux) with a lot of other threads competing for CPU time, which means that timings are going to be more irregular and less precise (in spite of the CPU being faster). This means, in practice, that with a Pi you likely need to use a smart stepper controller that does its own timing loops, or add an Arduino to do the timing-critical tasks.

GUI: The Arduino is limited in processing power, and graphic libraries to build an on-screen GUI with buttons, sliders etc. are very basic or not available. In practice, the Arduino is usually limited to a text display of 2 or 4 lines. The Pi is a much better choice to build a relatively complex GUI, for example in C#, and display it on a touch-screen display larger than that of a mobile phone.

My opinion is that if you need a good-looking and comfortable GUI on a touch-screen and want to avoid using multiple physical buttons and joysticks, you must use a Pi to control the GUI. The stepper motor(s) need instead either an Arduino or a smart stepper controller. In practice, you need both a Pi and an Arduino, with the Arduino controlling the motor, camera shutter and electronic flash with a sequence of correctly timed pulses, and the Pi controlling the Arduino via a higher-level communication protocol (higher in the sense that each command from the Pi specifies a sequence of actions to be timed and carried out by the Arduino).

The simpler solution is using only an Arduino, build an UI with multiple physical controls, and put up with the limited graphic output capabilities of the Arduino. This solution usually means that configurability of the device is either limited, or carried out through complex and partly "unnatural" actions that need to be memorized by the user.
--ES

Online
Adalbert
Posts: 2425
Joined: Mon Nov 30, 2015 1:09 pm

Post by Adalbert »

Hi BHF,
Please take a look at the following thread:
https://www.photomacrography.net/forum/ ... c&start=45
BR, ADi

kaleun96
Posts: 270
Joined: Sat Oct 20, 2018 3:47 pm
Location: Stockholm, Sweden

Post by kaleun96 »

enricosavazzi wrote: GUI: The Arduino is limited in processing power, and graphic libraries to build an on-screen GUI with buttons, sliders etc. are very basic or not available. In practice, the Arduino is usually limited to a text display of 2 or 4 lines. The Pi is a much better choice to build a relatively complex GUI, for example in C#, and display it on a touch-screen display larger than that of a mobile phone.

My opinion is that if you need a good-looking and comfortable GUI on a touch-screen and want to avoid using multiple physical buttons and joysticks, you must use a Pi to control the GUI.
I see where you're coming from but disagree that the Arduino is not suitable for a touch screen GUI. If you want a 10" display and a complicated UI and your background is in something like C#, you're right that a Pi is the way to go. But if you're starting out, want something more simple or a smaller display, I think you can achieve a lot with an Arduino.
My main goal with the post is to figure out what computer platform is going to control these two rigs I have going
If you're using a standard Arduino UNO, Nano, or Mega you are going to struggle with the refresh times of a 2.4"/2.8" TFT touchscreen. It's not terribly slow but you would be waiting about a second for the display to fully load the button components and bitmap images. However, this is only when loading a "screen" from fresh, when you're just updating a value on the display it is extremely quick provided you are smart about how you update a value.

Updating a value on a TFT display often involves drawing over the previous value with the button or background colour and then printing the new text. The Adafruit GFX library has a getTextBounds() function that makes this easier as it will find out how big of an area needs to be drawn over to cover the existing text.

How well an Arduino works with a TFT display is also down to the library and the pinout of the Arduino board. For example, an Arduino UNO will be much faster on a 2.8" TFT "shield" (display that plugs directly into the headers of the Arduino board) as the UNO's MCU pinout is better organised (in simple terms) for the TFT display, allowing the library to take advantage of the better organisation to process everything much faster. An Arduino MEGA, keeping everything else the same, will be much slower.

In terms of the benchmark times for the graphictest sketch, in my experience an Arduino mega will take about 18 seconds, an Arduino UNO probably less than 10 seconds. But what happens if we expand our horizons and leave the 16Mhz AVR chips behind for the ARM chips?

I have both an Arduino Due (84Mhz) and an Adafruit Grand Central M4 (120Mhz), these have ARM-based chips and are much faster and have more memory than most Arduinos. These can complete the TFT benchmark tests in about 4 seconds and <2 seconds, respectively, if I recall correctly. This means a TFT screen loaded with buttons and bitmap images loads instantly. To support a new board like the Grand Central on a random TFT display (they have many different controllers and configurations), I recommend the MCUFRIEND_kbv library (I helped the author add support for the Grand Central board recently).

But enough about speeds, what about GUI capability? The Raspberry Pi is of course much more flexible when it comes to this, no question. However, you're not stuck with just limited text displays on a few lines with the Arduino. My own Arduino controller has only one physical input except for the touchscreen - a joystick.

I would recommend you go with a 3.5" TFT display. I used a 2.8" previously (320x240 pixels) and have now upgraded to a 3.5" (480x320) and the difference is immense. You can fit much more on the screen and be more liberal with the spacing and organisation of the GUI. You can have an infinite number of "screens" as well so you can always fit everything you need. You just create a menu system where clicking a button clears the screen and prints a new UI with buttons to interact with. There's only a limit to the number of screens/menus/components you can have in terms of memory available.

As part of my migration from a 2.8" screen to a 3.5" screen, I wrote a button library that works with the Adafruit GFX library. It makes it easier to associate the graphics of a button (e.g. a coloured rectangle on the screen) with the need to interact with that button through touch and have it update values or perform different actions. That library, while still a work in progress and probably a poor representation of C++ programming, can be found here: https://github.com/camdey/gfxButton

An example implementation of that library can be found in my MacroStepper project, also a WIP: https://github.com/camdey/MacroStepper

Here's one of the "screens" for my controller. It's my manual screen which allows joystick control as well as setting the step distance of the rail so I can then move forward/backward in increments of one "step" (step here doesn't mean one step of the motor, rather a multiple of steps to travel a specified distance).
Image


I've recorded a short video here showing the GUI operation. This will give you an idea of the fullscreen refresh time, touch capability, and value update refreshing. I've completely re-written the GUI the past few weeks to use my new library so there are still some bugs and inefficiencies but I'm pretty happy with the value update time at the moment (doesn't flicker too much) and general page load time. The touch sensitivity still needs some calibration but you can only do so much with these TFT screens.

My GUI is still quite basic as it's all I currently need. You can implement a lot of different GUI components (buttons, sliders, images, etc), it's mainly down to how much work it takes. People have built some very impressive GUIs with Arduino, it can just requires more work due to manually having to construct buttons from simple shapes (squares, circles, lines, or triangles) or bitmap images. In my GUI, I have a few bitmap images per page but many of them could be made from drawing shapes and I've done this in the past.

You could replicate most, if not all, of the functionality you see in some of the commercial stacking controllers with an Arduino or Pi. I haven't seen the need to myself yet. I have thought about including DOF calculations based on the particular lens setup (as selected via the GUI) but I'll do that when I settle on a more stable lens setup for different magnifications. I'm also thinking about adding stack and stitch capability given my Y & Z axes are also motorised but at this time I don't need it.



When it comes to driving the stepper, both Arduino and Raspberry Pi will be suitable and I'm not sure whether one is much better than the other. enricosavazzi might have a valid point about the resources and timings but I haven't looked into it myself. I do however find the Arduino easier in that respect, as you know things are executed in the precise order they're called and the processor isn't doing much else in the background unless you tell it to.

The more important aspect is the driver board. If you go with something like a TMC5160 or TMC5130 that have a "motion controller", allowing the driver to control the stepper speed and acceleration rather than the Arduino/Pi, you can get some very impressive speeds. Much faster than anything you'll realistically need.

If you use a driver without a motion controller and control it solely via SPI, you might find the Pi to be faster but you likely could achieve similar speeds with the right Arduino board and code. There's a lot of overhead with some of the core Arduino functions so if you avoid those and have a MCU with a high clock speed, you'll not notice a practical difference between the Pi and Arduino.

If you chose one of the common stepper drivers like the A4988 or DRV8825, the limitation will be the driver itself rather than the Arduino/Pi.
- Cam

mawyatt
Posts: 2497
Joined: Thu Aug 22, 2013 6:54 pm
Location: Clearwater, Florida

Post by mawyatt »

Hi bhf,

That looks like you could produce a really nice setup around what you've shown!

BTW I was at the same position (except nothing to start with) a few years ago and wanted to create my own controller system since what I wanted to do wasn't readily available commercially within acceptable costs.

Long story short, I selected the RPi rather than Arduino for reasons mentioned. At first I used the Pololu Tic500 controller and developed the code in Python, this is USB driven controller. I didn't use or adapt code for other uses (CNC or printer for example) since I wanted things to work without altering to "fit" within another use. Included were optical isolated outputs for camera trigger and strobe trigger which allowed a work around for flash use with some fully electronic shutter cameras which block the hot shoe during this mode.

Later at Mike's Labs we developed things around the Trinamic TMC5130, 5160 and 5072 controllers and expanded the use to multiple axis, XYZ & R for example. This led to the development of custom printed circuit boards that fit the RPi called "hats" for single axis and multiple axis stacking and of fully automated Stack and Stitch systems capable of many thousands of image captures without intervention. I've posted much information here on these developments, just search under author "mawyatt".

Here's an image of a Single Axis controller based on TMC5160

Image

Here's an image of a Triple Axis RPi controller based on TMC5130 & TMC5072

Image

Image of a Quad Axis controller based on dual TMC5072

Image

We also developed a custom circuit & PCB to measure sine and cosine stepper motor currents, these helps with setting up a motor/rail system for optimum performance.

If the motors you've shown are 4 wire stepper motors (dual coil), most controllers should work. The controllers shown above are programmable for various motor parameters to allow smooth, silent & quick responses.

Best,

Here's an example of using the RPi and Quad Axis Controller with wireless VNC from a Mac Pro. You can see the various motor, timing, and multi axis position parameters. These are all programmable and can be setup for stacking within the program or loaded from a user defined text file, the files are also easily edited since they are simple text files.

Image

Part of operating code for S&S in Python and screen from demo test run.

Image
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike

elf
Posts: 1416
Joined: Sun Nov 18, 2007 12:10 pm

Post by elf »

I'm using a Teensy 3.5 (arduino compatible) and a Nextion Enhanced 4.3" touch screen on a rose engine. Basically, it is similar to a 4 axes CNC. The touchscreen has 22 different pages.

My camera setup uses a Teensy 3.2 and a bluetooth connection to an Android smart phone. There are quite a few functions shared between the rose engine program and the camera program.

The interface between the MCU and the display for both of these are serial, so any device which can communicate over serial will work for the display.

All that being said, if you're not a programmer, it would be better to buy an off the shelf controller.

mawyatt
Posts: 2497
Joined: Thu Aug 22, 2013 6:54 pm
Location: Clearwater, Florida

Post by mawyatt »

elf wrote:I'm using a Teensy 3.5 (arduino compatible) and a Nextion Enhanced 4.3" touch screen on a rose engine. Basically, it is similar to a 4 axes CNC. The touchscreen has 22 different pages.

My camera setup uses a Teensy 3.2 and a bluetooth connection to an Android smart phone. There are quite a few functions shared between the rose engine program and the camera program.

The interface between the MCU and the display for both of these are serial, so any device which can communicate over serial will work for the display.

All that being said, if you're not a programmer, it would be better to buy an off the shelf controller.

elf,

Not being a programmer was another reason I went with the RPi since I could program in Python which seemed like and easier method than C. It was difficult enough in Python, but I liked the idea of being to store and recall files and such like with a regular computer, operate different programs from the same controller for testing and different axis controls. The Raspian OS is quite good and has a nice GUI similar to Windows and Mac, which made things easier.

In hind site I would still go with the RPi, that combined with the excellent Trinamic controllers which really works well without imposing any limitations.

Had I chosen the Arduino I doubt my results would have been as successful, my skills as a programmer are weak and ultimately the results would be bound by that limitation. You folks that are skilled programmers can do so much with the hardware, much more than someone with limited skills like myself.

Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike

aidanmoore
Posts: 104
Joined: Thu Sep 24, 2015 8:09 am
Location: Toronto

Post by aidanmoore »

I'm for the Raspberry Pi and Trinamic external stepper controller combo.

I'm using the Mike Labs Trinamic stepper boards (as well as my own prototype 5160 board on another rig) as a hat on a Raspberry Pi:

Image

It all packages together very well, and as a bonus the Bluetooth built in allows me to control the steppers (XYZ) from a standard XBox Controller with joystick movement. All the code for the Xbox controller was found on Github, which is where you can find examples of GUI's for the Pi as well.

So the overall connection count for control is very low if you use the Bluetooth for wireless stepper control on the Raspberry Pi. You can also wirelessly VNC into the Pi to run another GUI on a computer monitor if needed to fine tune things like stack/stitch parameters.

I've used the Trinamic controllers to drive a wide range of steppers, including the old Leitz XY stage from eBay shown below. The motors were finicky to get moving correctly, but they move silently and smoothly with the Trinamic Stelathchop and other drive signal processing on the controllers.

Image
Custom Nikon/Thorlabs Microscope Nikon Z7ii ZCAM E4

bhf
Posts: 5
Joined: Thu Dec 26, 2019 7:38 pm
Location: kirkland, wa

Post by bhf »

Hope everyone is doing well and thanks for all the great responses. I came to the conclusion Raspberry Pi and these Trinamic controllers sound like a pretty compelling potential answer for me.

I picked up some TMC5072-BOB boards & adafruit perma proto pi hats to have on hand.

Mike I am not quite understanding, do you have code, stepper boards and rpi hats that you are making available somewhere? I looked off this site and didn't find anything. If just code, would I be able to use it with a stepper board I got that independently?

I searched your previous posts and there is a lot of information and apologize if I missed those details.

Aiden seems like you have your own separately developed project? I love the idea of using an Xbox controller to control xyz in realtime, so cool.

aidanmoore
Posts: 104
Joined: Thu Sep 24, 2015 8:09 am
Location: Toronto

Post by aidanmoore »

I started with Mike's custom Trinamic 5072 boards as shown in my pic above, and then built a few of my own custom boards to accomodate a more powerful Trinamic 5160 and a single 5072 on a second rig.

startImage

Mike has written code to control the Trinamics on the Raspberry Pi using the pigpiod GPIO library. It is the best place to start as you simply use a keyboard to move the steppers to your desired location.

I modified the code to allow use with two types of XBOX controller; the older controller with a dedicated dongle, and the newer XBOX One BT that uses the RPi built in Bluetooth radio.

The XBOX control code is not quite as straight forward as Mike's stack and stitch code, as it requires the use of a fairly new asyncio library, but the advantage is that there are no hardware modifications needed to get it going once you have the motors running.

Here's a snapshot of the XBOX main loop and the control codes it looks for from the XBOX controller:


Image


async def main():


XFLAG = 0 # 1 = deenergized and target reached 0 = target not reached
YFLAG = 0 # 1 = deenergized and target reached 0 = target not reached
ZFLAG = 0
XNOW = 0 # 1 = deenergized and target reached 0 = target not reached
YNOW = 0 # 1 = deenergized and target reached 0 = target not reached
ZNOW = 0
XPOS = md1.readInt('XACTUAL')
YPOS = md1.readInt('X2ACTUAL')
ZPOS = md2.readInt('XACTUAL')
ZSCALE = 2 #start in fine mode
keep_going = True

while keep_going:

# Read the Joystick values
XNOW = round(remote_control.joystick_left_x,4)
YNOW = round(remote_control.joystick_left_y,4)
ZNOW = round(remote_control.joystick_right_x,4)


if abs(XNOW) >0.1: # if the Joystick is not in deadband
XPOS = XPOS + 20 * XNOW #Change the target
mot1.xgotonowait(XPOS) # Go to the target Motor 1 (Purple)
XFLAG = 1
if abs(YNOW) > 0.1:
YPOS = YPOS + 20 * YNOW
mot1.ygotonowait2(YPOS) # Write position count to Trinamic 5072 #1 Motor 2 (Green)
YFLAG = 1
if abs(ZNOW) > 0.1:
ZPOS = ZPOS + ZSCALE * ZNOW
mot2.zgotonowait(ZPOS) # Write position count to Trinamic 5072 Motor 3
ZFLAG = 1


#
# Now test if the motors have arrived at its target position. If it has, deenergize the motor.
#
if md1.readInt('XACTUAL') == md1.readInt('XTARGET') and XFLAG == 1 : # if the target is reached and the flag is set
XFLAG = 0 # Clear the flag
mot1.xdenergize() # Denergize Motor 1 TMC5072 Chip #1
print (' X target reached ')
if md1.readInt('X2ACTUAL') == md1.readInt('X2TARGET') and YFLAG == 1 : # if the target is reached and the flag is set
YFLAG = 0 # Clear the flag
mot1.ydenergize2() # Denergize Motor 2 TMC5072 Chip #1
print (' Y target reached ')
if md2.readInt('XACTUAL') == md2.readInt('XTARGET') and ZFLAG == 1 : # if the target is reached and the flag is set
ZFLAG = 0 # Clear the flag
mot2.zdenergize() # Denergize Motor 1 TMC5072 Chip #1
print (' Z target reached ')

#
# Buttons
#
if remote_control.button_x: # Super fine
remote_control.button_x = False
ZSCALE = 0.5 #fine mode
print ("Super Fine Mode")
if remote_control.button_y:
remote_control.button_y = False
ZSCALE = 2 #fine mode
print ("Fine Mode")
if remote_control.button_b: # play once strong rumble effect
remote_control.button_b = False
ZSCALE = 30 #coarse mode
print ("Coarse Mode")
remote_control.rumble_effect = 2
if remote_control.button_a: #take picture
remote_control.button_a = False
pi.write (cameraport, 1) # Write 1 to camera port
await asyncio.sleep(0.01) # set pulse width to 10ms
print (" Snap ")
pi.write (cameraport, 0) # Set camera port back to 0

await asyncio.sleep(0)

remote_control = joy(file = '/dev/input/event0')
futures = [remote_control.read_gamepad_input(), remote_control.rumble(), main()]
loop = asyncio.get_event_loop()
loop.run_until_complete(asyncio.wait(futures))
loop.close()
Custom Nikon/Thorlabs Microscope Nikon Z7ii ZCAM E4

mawyatt
Posts: 2497
Joined: Thu Aug 22, 2013 6:54 pm
Location: Clearwater, Florida

Post by mawyatt »

bhf wrote:Hope everyone is doing well and thanks for all the great responses. I came to the conclusion Raspberry Pi and these Trinamic controllers sound like a pretty compelling potential answer for me.

I picked up some TMC5072-BOB boards & adafruit perma proto pi hats to have on hand.

Mike I am not quite understanding, do you have code, stepper boards and rpi hats that you are making available somewhere? I looked off this site and didn't find anything. If just code, would I be able to use it with a stepper board I got that independently?

I searched your previous posts and there is a lot of information and apologize if I missed those details.

Aiden seems like you have your own separately developed project? I love the idea of using an Xbox controller to control xyz in realtime, so cool.
Yes we have developed code at Mike's Lab for various Trinamic controllers including the TMC5130, 5160, 5161 and 5072, this includes use as single axis and multi-axis (Stack & Stitch). Also developed various RPi custom PCBs Hat for single use with TMC5130, 5160, 5161 and 5072, and have triple axis and quad axis controllers, and S&S code has been developed for completely automated "Hands Off" operation with RPi.

A number of folks are using these custom Trinamic controllers including Aidan, as you see Aidan has integrated Joy Stick controllers.

The code from Mike's Lab is text based and written in Python, which allows somewhat easy customization for different preferences/usages.

Some of these RPi based Trinamic custom "Hat" PCBs are still available.

Best,
Last edited by mawyatt on Tue May 12, 2020 8:41 pm, edited 1 time in total.
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike

mawyatt
Posts: 2497
Joined: Thu Aug 22, 2013 6:54 pm
Location: Clearwater, Florida

Post by mawyatt »

aidanmoore wrote:I started with Mike's custom Trinamic 5072 boards as shown in my pic above, and then built a few of my own custom boards to accomodate a more powerful Trinamic 5160 and a single 5072 on a second rig.

startImage

Mike has written code to control the Trinamics on the Raspberry Pi using the pigpiod GPIO library. It is the best place to start as you simply use a keyboard to move the steppers to your desired location.

I modified the code to allow use with two types of XBOX controller; the older controller with a dedicated dongle, and the newer XBOX One BT that uses the RPi built in Bluetooth radio.

The XBOX control code is not quite as straight forward as Mike's stack and stitch code, as it requires the use of a fairly new asyncio library, but the advantage is that there are no hardware modifications needed to get it going once you have the motors running.

Here's a snapshot of the XBOX main loop and the control codes it looks for from the XBOX controller:


Image


async def main():


XFLAG = 0 # 1 = deenergized and target reached 0 = target not reached
YFLAG = 0 # 1 = deenergized and target reached 0 = target not reached
ZFLAG = 0
XNOW = 0 # 1 = deenergized and target reached 0 = target not reached
YNOW = 0 # 1 = deenergized and target reached 0 = target not reached
ZNOW = 0
XPOS = md1.readInt('XACTUAL')
YPOS = md1.readInt('X2ACTUAL')
ZPOS = md2.readInt('XACTUAL')
ZSCALE = 2 #start in fine mode
keep_going = True

while keep_going:

# Read the Joystick values
XNOW = round(remote_control.joystick_left_x,4)
YNOW = round(remote_control.joystick_left_y,4)
ZNOW = round(remote_control.joystick_right_x,4)


if abs(XNOW) >0.1: # if the Joystick is not in deadband
XPOS = XPOS + 20 * XNOW #Change the target
mot1.xgotonowait(XPOS) # Go to the target Motor 1 (Purple)
XFLAG = 1
if abs(YNOW) > 0.1:
YPOS = YPOS + 20 * YNOW
mot1.ygotonowait2(YPOS) # Write position count to Trinamic 5072 #1 Motor 2 (Green)
YFLAG = 1
if abs(ZNOW) > 0.1:
ZPOS = ZPOS + ZSCALE * ZNOW
mot2.zgotonowait(ZPOS) # Write position count to Trinamic 5072 Motor 3
ZFLAG = 1


#
# Now test if the motors have arrived at its target position. If it has, deenergize the motor.
#
if md1.readInt('XACTUAL') == md1.readInt('XTARGET') and XFLAG == 1 : # if the target is reached and the flag is set
XFLAG = 0 # Clear the flag
mot1.xdenergize() # Denergize Motor 1 TMC5072 Chip #1
print (' X target reached ')
if md1.readInt('X2ACTUAL') == md1.readInt('X2TARGET') and YFLAG == 1 : # if the target is reached and the flag is set
YFLAG = 0 # Clear the flag
mot1.ydenergize2() # Denergize Motor 2 TMC5072 Chip #1
print (' Y target reached ')
if md2.readInt('XACTUAL') == md2.readInt('XTARGET') and ZFLAG == 1 : # if the target is reached and the flag is set
ZFLAG = 0 # Clear the flag
mot2.zdenergize() # Denergize Motor 1 TMC5072 Chip #1
print (' Z target reached ')

#
# Buttons
#
if remote_control.button_x: # Super fine
remote_control.button_x = False
ZSCALE = 0.5 #fine mode
print ("Super Fine Mode")
if remote_control.button_y:
remote_control.button_y = False
ZSCALE = 2 #fine mode
print ("Fine Mode")
if remote_control.button_b: # play once strong rumble effect
remote_control.button_b = False
ZSCALE = 30 #coarse mode
print ("Coarse Mode")
remote_control.rumble_effect = 2
if remote_control.button_a: #take picture
remote_control.button_a = False
pi.write (cameraport, 1) # Write 1 to camera port
await asyncio.sleep(0.01) # set pulse width to 10ms
print (" Snap ")
pi.write (cameraport, 0) # Set camera port back to 0

await asyncio.sleep(0)

remote_control = joy(file = '/dev/input/event0')
futures = [remote_control.read_gamepad_input(), remote_control.rumble(), main()]
loop = asyncio.get_event_loop()
loop.run_until_complete(asyncio.wait(futures))
loop.close()
Aidan,

Very nice :D

The integrated Joy Stick is really cool 8)

Awhile back we developed a custom PCB with the Trinamic StepStick which utilized the TMC5160 since the standard TMC5160 BOB is too large to fit with a TMC5072 BOB on a single RPi Hat sized PCB. The idea was to use the smaller StepStick TMC5160 BOB which has higher current capability to control the Z axis, and use the TMC5072 BOB to control X and Y.

The StepStick had the base configuration wired for Dir and Step mode, and could not be converted to the Motion Control mode required for use. We only found this out after designing and fabrication custom Hat PCBs for use with the StepStick BOB and TMC5072 BOB. :oops:

Cam (kaleun96) pointed out the StepStick has been redesigned with the latest version v1.4 which corrected this problem. However v1.4 isn't available in US (DigiKey) now. Watterott is the supplier of the StepStick BOB for Trinamic, hopefully these will show up soon here in US.

https://www.photomacrography.net/forum/ ... c&start=90


We've modified the custom PCB for the StepStick V1.4 and TMC5072 BOBs, but have not had them fabricated, if enough folks are interested we may get a few fabricated.

Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike

Post Reply Previous topicNext topic