[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 )

[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?

[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]

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]

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.)

[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).

[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]

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.

[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 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 🙂

[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 🙂

[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]

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!

[Author]

Posts