Kinetic sculpture; advice on motor setup etc

Status
Not open for further replies.

MartinRos

New member
I am looking to build a Kinetic Sculpture where 500 (or so) motors which raise and lower weights(such as Christmas tree decorations), using thread and reels to visually mimic waves, 3D patterns etc. See an example at https://www.youtube.com/watch?v=NXuQnDeIyY8


There are some technical questions:

1. Motor type
Motors are low-power (20gm weights) but 500 located in reasonably close proximity. Motor selection needs to consider: cost, reliability (24x7 operation), low power (i.e. avoid fire hazard), reliable positioning in response to command (+/-5% including start-up initialisation). Currently a stepper motor (say NEMA 8) seems preferred. By comparison DC motors with encoders have low heat and low(ish) cost, but not sure about reliability and they require a closed loop PID operation, needing more inputs and more complicated. Thoughts?

2. Start-up positioning
An IR Obstacle Avoidance Sensor seems cost effective and practical. I.e. detects when the weight nears the top. But is there a easier method to reel the weight out at initialisations and detect when the load on the motor changes from DOWN to UP (i.e. -torque to +torque). Is it more practical to implement?

Thanks in advance.
 
Interesting project.

Since you aren't going to be able to control all 500 motors directly from a processor, you will need some sort of distributed control. I assume you've already figured that out but it leads to the next point of having control nodes that manage a small number of motors and communications. Communication overhead could be a factor so the nodes should be fairly smart and not need feedback control (i.e. fire and forget). The node cost will be a factor along with the motor cost. Are you planning on making your own circuit boards or cobbling together premade ones? So, to your questions:

Motor type. yes steppers are somewhat easier to use but will require a driver which adds cost. And even really cheap steppers are more expensive than simple DC motors. Also, steppers generally have a lower max speed than DC motors. A DC motor can be controlled via a simple H-Bridge. For feedback you can use index holes in your wire reel with an ir-detector like you would use for limit detection for the "bobs" (not sure the correct term there). So each DC motor would require 4 control pins - 2 for the motor and 2 for the sensors. The size of the motor is a key factor in cost, once you figure out what you need, that will drive decisions about the motor controller.

Positioning. Yes, as long as a stepper isn't driven beyond its limits, you can do simple counting to know position. However, determining initial position is going to require some sort of limit detector. With a DC motor, you simply count revolutions of your wire reel (via one or more index holes) to know position. I'm not sure you really need PID control but it's not that complex. You will need to factor in that the diameter of your reel will change as you reel in/out your bob.

I think you are implying a way to detect fully unrolled. It may be possible to monitor current consumption though I'm not sure it would work that well. In addition, detecting bottom will force you to have reasonably tight control on the suspension wire length. Measuring at the top only requires positioning of the sensor.

Another thing to consider, wire and connector costs will be a significant factor.
 
Its likely to be worth figuring out if some clever mechanism can drastically reduce costs - 500 is 20 x 25 array or so.
Any way to common up the mechanical drive to a whole row may be a winner - a solenoid per reel or similar
then controls whether drive is applied to that reel. Use friction to set the endstops (ie simply home everything in
the row at once by driving all for long enough to hit every endstop. No encoders needed. One digital output per
solenoid.

I'd imagine each reel has friction to hold the weights in place, and the solenoid pushes it against a rotating shaft
powerful enough to overcome the friction.

This sort of arrangement can only drive things in one row in one direction at once of course, and at the same speed(*),
so it is limited, but the cost of 500 motors+encoders is not to be underestimated. 500 miniature steppers would be
very expensive, they cost a lot more than NEMA17 in my experience.

Steppers are very noisy - when there's a whole choir of them you will hear them!

(*) you can slow-PWM solenoids to fake different speeds
 
Sounds like a neat project.

What do you mean by "low power"? How fast do you want the 20g mass to move up? What's your budget?

If you have the power budget, off the shelf stepper drivers can be used and could keep the cost down. With NEMA 8 steppers, just the motors will draw about 2400W continuously. (quick search shows .6A/phase x 2 phase/motor x 500 motors x 3.9V). Your motor drivers and main controller will add to that. Homing and skipping steps are a concern.

Continuous run hobby servos/Dynamixel could be an option, but 24/7/365 operation would be questionable.

Brushless servos would be zero-maintenance, probably the most expensive option, if you can find them small enough.

Brush DC motors, with gear head may be an option to get the power down, if you can gear it properly without being back-driven. For something like this, you have to home the motors, so having an encoder on each motor would be the way to go. Yes, more inputs, but less hassle. Home the motors on power up.
 
As with just about anything, operate the device beyond the rated capabilities and you risk damage. I've smoked a few $800 DC servo motors in my career, possibly the highest quality you can buy, made in Germany, but violated the operating limits and learned a lesson. We had over-temp and over-current protection on the motor drivers, but a stall condition (user error) we didn't forsee caused the failure. Next board rev added thermistors to sense motor temperature. No failures have happened since.

I wouldn't be afraid of using RC servos, but you have to do the engineering and determine your worst case operating condition, margin of safety and find those unexpected edge and corner cases (fish jumps out of water and swallows the 20g weight) and test for that too.

And always test to confirm the manufacturer's rated specs, especially if your margins are close because you are trying to not bust your budget.
 
All

Thanks for the comments. They are helping fine tune the plan.

Comments on issues raised:

1. Systems config
Propose to use Raspberry PI to run simulation software (i.e. breaking wave, water sloshing in a container etc) for the ‘bobs’ in the sculpture to follow. RaspPI then sends ‘bob’ velocity profiles to say Nodes (i.e. Teensy’s) via Ethernet.

2. ‘Bob’ dynamics
Max speed: 1m/sec (i.e. not too frenetic)
Power output required @ max speed: 0.2W using a 20gm ‘bob’

3. Teensy workload
Teensy 4.1 controls 13 ‘bobs’. Therefore need 30 nodes to control proposed 500 ‘bobs’. Consensus appears that DC motor preferred (i.e. need to manage heat and acoustic noise with steppers and the sculpture should be quiet rather than a chattering choir). For DC motor digitals required: 2 PWM + 1 home, + 1 encoder. So for Teensy 4.1: 55/4 = 13 ‘bobs’.

Teensy needs to manage:
a. COMMS via Ethernet for velocity profile: <1kbytes/sec + storage of profile
b. PWM (for 13 motors): need to fine tune the PWM power applied for each motor based on feedback from encoder so that ‘bobs’ are roughly in synch over 5-10min between synchronisation. Presumably a cut-down PID is sufficient.
c. Digital interrupts (for 13 encoders): <2,600/sec
d. Timer: to synchronise all ‘bobs’ say every 5-10mins

4. Budget
$5k start. But depends on how well the pilot of a couple of Teensy’s works AND what the ‘boss’ says …

5. Rotating shaft + solenoid controllers
An interesting thought. Reduces electronic componentry, but requires more hardware. Could adjust speed using cogs such as on a bike derailleur. But change of direction requires two counter rotating shafts and ability to use either, presumably like a reversing gear in a car gear-box. Will give it some thought.

Question:
Is there an expectation that the Teensy 4.1 can handle the load as outlined, before I leap in and start playing around.


Martin R
 
So 1 T4.1 to drive 13 DC servo motors with ethernet?

Figure 42 pins available, not including ethernet.

For a brushed DC servo, 2 wires to drive is minimum, like PWM/DIR or PWM-FOR/PWM-REV.
Perhaps this guy could do the trick? https://www.digikey.com/en/products/detail/diodes-incorporated/ZXBM5210-S-13/4567774. Watch out for drivers that have an enable or brake pin, which you don't have the pins to deal with.
2 pins/motor x 13. Leaves you 16 pins.

Then you need to home, can home on position error (sensorless) or home on limit switch/sensor.
13 pins needed, but you should use a port expander with 2 pins, like this https://www.digikey.com/en/products/detail/nxp-usa-inc/PCAL9535APW-118/3677029. Leaves you 11 pins.

Then you need encoder feedback. You don't have the pins for 13 quadrature encoder inputs. I2C or SPI encoders will be cable length limited. So depending on how long the cable is, you may need to get creative here. You only need to know the encoder position when you are running the PID loop, so you could query, ideally over SPI.

Leaves a few pins for a reset button, blink an LED, measure voltage, temp.

Software wise, I ran 2 DC motors on a T4.0 closed loop PID, on interrupt, T4 didn't break a sweat at 5khz update rate on each motor. I only needed 1khz, but tested faster to check motor performance. That was using the on-board quadrature encoders. SPI will slow you down a bit.

I'd run it all on POE, make it easy connectivity. Watch your encoder resolution, calculate the max frequency based on max RPM. Be sure your encoder can handle that speed.
 
I wouldn't be afraid of using RC servos, but you have to do the engineering and determine your worst case operating condition, margin of safety and find those unexpected edge and corner cases (fish jumps out of water and swallows the 20g weight) and test for that too.
If you do some testing you'll find they are simply not reliable enough, fortunately, as a ceiling fire in a public space is about the
worst-case scenario there is - you do not want to go there, trust me.
And always test to confirm the manufacturer's rated specs, especially if your margins are close because you are trying to not bust your budget.
Have you seen a datasheet for an RC servo? For instance: https://datasheetspdf.com/pdf-file/791970/TowerPro/SG90/1 nothing about
current or power, nothing about whether the housing is flame-retardent, nothing about recommended fusing,
nothing about expected life, and the units for torque are sometimes valid torque units, sometimes spring-rate units!

They are basically toys for outdoor use, not engineered components for reliable/safe indoor use.
 

Of course I don't know how professional you need/want to build that. At about 1:10 they give you a glance at the mechanical/electronical setup. Doesn't look like a bunch of RC-Servos controlled by a few Teensies :). Also doesn't look like your 5k budget will carry you far. Anyway, looks really cool...
 
The Art+Com people who built the Changi installation know what they're doing. But it took them 20 months and it's a superb job, and provides a 'signature' display for the terminal. Still going after 6 years as far as I know. And as they say, it takes a very large budget to do a large job. The budget wasn't disclosed which probably means it was substantial, especially when looking at their setup.

However I am trying to build something with a smaller footprint. To do something extraordinary with ordinary resources. So far there is reason to believe it is a practical proposition.
 
I have been thinking about this idea in the background since you posted it. I am wondering if a custom smart motor controller could reduce your I/O requirements. The idea is each "bob" has a controller board that runs the motor, senses position and communicates with a "node host" that does motion planning and reports to your main controller. The I/O interface could be RS485 which can be robust and inexpensive. The bob controller would take a command and execute it. Maybe it doesn't even need to report back during normal operations to avoid I/O traffic (it would need to be able to report status when queried). RS485 can easily run at a couple of Megabits/Sec over a 100 Meter length when properly terminated and with decent transceiver design. This would keep the wiring pretty simple.
 
If you do some testing you'll find they are simply not reliable enough, fortunately, as a ceiling fire in a public space is about the
worst-case scenario there is - you do not want to go there, trust me.

Have you seen a datasheet for an RC servo? For instance: https://datasheetspdf.com/pdf-file/791970/TowerPro/SG90/1 nothing about
current or power, nothing about whether the housing is flame-retardent, nothing about recommended fusing,
nothing about expected life, and the units for torque are sometimes valid torque units, sometimes spring-rate units!

They are basically toys for outdoor use, not engineered components for reliable/safe indoor use.

Valid points, that's why I said you have to do the engineering for the application, which may not be indoor use. It may be intended for a Christmas display, could be outdoors, exposed to rain and snow, in which case, a seasonal display would be ideal for RC servos.
 
Status
Not open for further replies.
Back
Top