Skycam/SpiderCam

[VanDerSloth]

Hi everyone!

First of all: Thanks for the open source Skycam-Software, Dan!
I’m trying to build a Skycam for a University project, and I’m starting to get somewhere, but now I’m stumped:
My best results I have achieved with the Makelangelo dev branch firmware set to machine type “Skycam”. After tinkering with some options (for example, I had to set the CLOCK_MAX_STEP_FRQUENCY way down, and I’m not sure why) I’m at a point where I can kinda move the EE around as desired, although the dimensions are off (even though I set all the settings in config.h and robot_skycam.h to the best of my abilities) and the EE gets pulled upwards if I move it toward the edges of my box (this might be related to the weird dimension issues?).
The worst problem, however, is that the motors make terrible noise and stutter when I move them over longer distances. They will jump wildly in speed, but if I move them back to the previous position it will go back right, so if the motors are losing steps they’re doing it very consistently.
I have installed the old Skycam-Firmware and that makes the Motors run much more smoothly and I have no idea why. The problem with that is, that whatever coordinates I send it, it will just pull upward with 3 motors, even though I have set the dimensions.

So I basically want the functionality I get out of the Makelangelo-Firmware with the smoot motor operation of the Skycam-Firmware and hope that the dimensional problems will sort themselves out once the motors know what to do.

I hope you can understand this jumbled mess of a description and point me in the right direction!

[Dan]

T is the distance from the tool aka end effector (EE) to corner A.

[Dan]

Hi VanDerSloth!

I’ve never adjusted CLOCK_MAX_STEP_FREQUENCY, ever. If you are using a RUMBA or a mega 2560 then you should *not* change it, as it is used to calculate timing frequency of the Interrupt Service Routine (ISR) that fires step commands to the motors.

Can you show video of the problem? then I’d understand the sound and motion you are experiencing.

I wonder if this is at all related to the fun I’m having with the Zarplotter…

[VanDerSloth]

Hi Dan!
Thanks for the quick reply!

I’m using a RAMPS 1.4 on an Arduino Mega with DRV8825s.
When I first tried the Makelangelo-master firmware the motors wouldn’t move at all and only make beeping noises, until I adjusted CLOCK_MAX_STEP_FREQUENCY. That was before I adjusted all the appropriate settings (PULLEY_THREAD, MICROSTEPS, etc.) and now I’ve changed CLOCK_MAX_STEP_FREQUENCY back and they still move. However, they also still make terrible noise in half-step mode (which they don’t in the skycam-firmware). When I set them to 1/16 steps they became much quieter, but I also can’t run them quickly at all and on longer distances they kinda start slowing down and accelerating again every half second or so. I’m gonna upload some videos and post them here, to show what I’m talking about.

[VanDerSloth]

Here you can see the movement. The second movement was supposed to just go sideways, but when it approaches the center it also moves downwards.

Here is just the motors running (still in half step) with the makelangelo firmware and the default value for Max step frequency. In the second half you can hear/see the intermittent speeding up.

Hope this helps 🙂

[Dan]

The noise is very troubling, but I see lower hanging fruit here:

Winding cable around a drum is trouble. cable never winds the same way twice. The amount of cable pulled changes as the drum fills and empties. You’ll never know how much cable you are actually moving in a single step. Also the drum diameter effectively weakens your motor. Better to have a very small toothed or friction pull from the motor of consistent diameter, and then some other mechanism that manages loose cable behind the motor.

I have four motors running here on a zarplotter and they’re more quiet. Have you adjusted the current to each motor for the rated torque? are you sending lots of very short line commands? If I overwhelm the system with tons of short line commands the parser is slower than the stepper control. new lines cannot be queued and optimized before the queue runs empty. net effect, the machine starts and stops in a stuttering motion.

I would also try lowering your top speed. with the newest firmware try a maximum feedrate of 90mm/s and max acceleration of 200mm/s

[VanDerSloth]

I see your point regarding the cable, but I doubt it’s responsible for the huge deviation, as the cable itself is very thin (~1mm) and only winds around the drum a maximum of 2 or 3 layers. We decided on that method early on because it’s very cheap and we can live with slight inaccuracies. Now it’d be too late to change the system anyway, as we’ve already spent all of our budget (and only have about 3 weeks time left).
The current of the motors is adjusted according to the datasheet, and the second video shows them reacting to a single GCode command sent over serial. I don’t think it’s hardware related, as with different firmwares we get the motors running very smoothly – they just usually don’t support 4 motors (let alone skycam IK).

We’ve only sent commands with a specified feedrate (I think for that video we sent F500, but I’m not sure rn), so I don’t know whether a different value for the maximum would help? I tried to set it, but in my firmware version the Maximum Feedrate as defined in robot_skycam.h has a default value of 15000 and it doesn’t say what unit, so I doubt it’s mm/s?

Thanks again for your help, it’s really nice of you to give such extensive support for a freeware product 🙂

[Dan]

I don’t make many sales, so I have time to support everyone who asks.

I also don’t have one of every robot or an automated way to test every robot. I see now that the acceleration and feedrate defaults for skycam are way out of date.
The system USED to be motor-steps/s and now they are mm/s.

I just went through the header files and updated all default speed values. Please update your version to the latest from the development branch: https://github.com/MarginallyClever/Makelangelo-firmware/tree/dev

Also please let me know if the LCD panel is more responsive for you. I’ve been working on making it ess painful.

[VanDerSloth]

Thanks for the new version. I had a chance to test it today and I’m afraid the motors still act weirdly.
This is their reaction to “G00 X500”: https://youtu.be/RZ666z6K6p4

Sadly I can’t help you regarding the LCD, since I’m not using one. We’ll be operating the skycam exclusively by serial communication from a PC and thus don’t need one.

[VanDerSloth]

I just tried commenting out SUBDIVIDE_LINES and now the motors run really smoothly. I don’t know what’s wrong with the subdivision, but we’ll be able to set up the whole thing again on the weekend (we’re just checking motor movement right now) and see wether we need the subdivided lines at all.

[Dan]

That’s… odd.

Let’s say you want the tool to move from A to B. The software used to calculate the belt lengths at B and then naively turn towards that goal. Because this is a hanging plotter the movement created is an arcing motion. To minimize this effect I added SUBDIVIDE_LINES, which breaks long moves into short ones …~5mm each, by default. You make the subdivisions bigger if the precision is still acceptable. SEGMENT_PER_CM_LINE (0.5) would be one every 2cm.

Turning off the feature will mean less calculations from the firmware but also reduce fidelity.

Maybe I should turn this into SEGMENT_MAX_LENGTH_CM so it doesn’t become a crazy fraction?

Can I see a video of the new behavior?

[Dan]

I have updated the firmware dev branch to reflect the changes.

[VanDerSloth]

So, I’ve had the chance to set it all up again, test the new version and here’s some video for you:

First up: The setup is about 1.4 x 1.4 x 2.3 meters. I’ve set the dimensions like that: (-700.0,-700.0,0.00) (700.0,700.0,2300.0) and start with the EE at the ground in the middle of the square.
I’ve greatly increased the Feedrate again, because I found it to be very slow with your new values, so I set them like this:

#define MAX_FEEDRATE         (15000.0)  // depends on timer interrupt & hardware
#define MIN_FEEDRATE         (0.0)
#define DEFAULT_FEEDRATE     (500.0)

#define MAX_ACCELERATION     (5000.0)
#define MIN_ACCELERATION     (0.0)
#define DEFAULT_ACCELERATION (1000.0)

In configure.h I’ve set:

#define DEGREES_PER_STEP     ( 1.8)
#define MICROSTEPS           (4.0)
#define PULLEY_PITCH         (188.0)

The Pulley Pitch value is the circumference of my drum. Is that the correct interpretation? I’m a bit at a loss there, because I’m not using belts.

The new dev-branch-version is still making problems that disappear when I disable path subdivision.

This is the new version reacting to “G00 X400” at a Z-Height of 1000:

This is it with subdivision enabled and the same command:

as you can see, the EE moves too far towards the edge (if I use X500 it will be right between the stands, where X700 should be) and it also moves upward toward the edges.

Thanks again for your diligent support 🙂

[VanDerSloth]

Doing further tests I also noticed, that the EE will move less for lower Z-Values. Z1000 moves it up maybe 50cm, while Z2000 moves it about a meter (as you’d expect).

[Dan]

Yes, pitch is the drum circumference.

The robot has a belief about the we position, right? The smallest difference between the actual and believed position creates a big warping effect on movement. It’s a problem with all polargraphs, zarplotter, and skycams.

So with subdivision ON it runs smoother? Mission accomplished! 😎

[VanDerSloth]

Oh, sorry, I meant to write “disabled”. So it’s still smoother without subdivision.
I’m wildly trying out different values for the axis-limits right now and it’s not helping at all. I’ve tried manually setting the home position, but I don’t seem to get it. When I just set the dimensions and restart the machine M114 will read something like this:
17:23:44.903 -> > X0.00 Y0.00 Z0.00 F500.00mm/s A1000.00
17:23:45.353 -> HX-700.00 HY2200.00 HZ0.00

I would have expected the home position to be HX0 HY0 and HZ0, but when I set that with D6 it moves completely wrong. So I assume it’s some kind of offset? But why does it put HY to 2200? The Y-Axis doesn’t go that high…

Is there a better way of calibrating it without using end-switches (I have not yet implemented those, I’m hoping to use magnetic switches for that.)

[Dan]

The axis limits should be in mm. Impressive you can run at F500 and A1000 with 1/4 micro stepping. I’ve never tried it.

I would also expect HX0Y0Z0. Something might be going wrong in the firmware? I’ve only built two skycams before, and that was long ago.

If you start in the bottom center at the origin and say G0 Z10000 (1m up), does it go 1m up? does it go more or less? does it go sideways at all? you may also be able to test with shorter movements if it feels more safe to start small.

[VanDerSloth]

I’ve now set the height a little differently to account for the cables not going all the way to the ground in the start position, so I just subtracted that difference from the total height (and all height measurements I’m giving in this post)

M101 gives me: 15:10:43.532 -> > (-700.00,-700.00,0.00) – (700.00,700.00,2150.00)

M114:
15:10:26.831 -> > X0.00 Y0.00 Z0.00 F500.00mm/s A1000.00
15:10:27.477 -> HX-700.00 HY2150.00 HZ0.00

G0 Z1000 moves it straight up to 48cm
G0 Z1500 to 98cm
G0 Z2000 to 173cm

Then I used D6 to set home to X0 Y0 Z0, so M114 reads:
15:16:07.370 -> > X0.00 Y0.00 Z0.00 F500.00mm/s A1000.00
15:16:07.751 -> HX0.00 HY0.00 HZ0.00
Without restarting it yields the same results.

After disconnecting and reconnecting the Arduino, G0 Z1000 moves it up 53cm and a little bit in the positive Y direction.
In tests I did yesterday, but didn’t document well, it would sometimes fly off to the side when I was just giving Z-Axis commands after I had fiddled with the dimensions and/or home position settings.
This is… puzzling.

[VanDerSloth]

When I move it along the X or Y axis, the behaviour also changes according to the Z-Position.
At Z1000 it will move to 130 mm for X100 and about 400 for X300.
At Z2000 it will move about 100 mm for X300.
In both situations it will also move upwards somewhat for higher differences to the middle, but moreso at the higher Z-Position.

I also noticed that it will change the dimensions in M101 when I restart after using D6.

[VanDerSloth]

Okay, so we changed the following line in skycam.h:

dz = z;

to

dz = limit_zmax - z;

Then we plugged the motors into the shield the other way around to reverse direction, and now the measurements hold up across different heights! The EE also doesn’t move upwards towards the edges of the box.
It seems like you had the coordinate system turned upside down? Did we overlook some setting?

[Dan]

It’s possible I got the original wrong, or that z- is up? That would be odd.

I’m delighted you got it working!
Feel free to send a pull request with you change(s) and that’ll get your name in the github logs. Credit where it’s due.

[VanDerSloth]

I’m delighted as well! I might just put it on github, thanks 🙂

Now the “only” thing that’s not working is smooth movement with subdivision enabled. What we’re actually trying to do is to move the skycam live in sync with a VR headset. Right now we can actually kinda do it, but it’s rather choppy because it will try to accelerate and decelerate to get to every coordinate it was sent. Any chance you have an idea how to make it always try to reach the most current position, disregarding all intermediate coordinates?

(Btw. here’s how it currently looks in action: https://youtu.be/cjt7VnGJwrs )

[Dan]

you’d need a way to cancel whatever existing motion is in action and then setup a new one. this would still cause a brief pause while it recalculates.

If you had all new code maybe you could set up some kind of PID and a target position and always work towards whatever the target is. A radical approach I haven’t thought too hard about.

I think the swing in your end effector would reduced if the cables all met at a single point rather than the edges of the cube. another way is a gyroscope on the effector to reduce swinging.

[Author]

Posts