Hoverfly Hoverfly Gimbal Controller?

thijmen5

Member
Ok, haven't seen that. How is firmware 0,96 for 2 axis? What about the scaling issue at the tilt axis in that firmware?
 

Whopis

Member
Yes I did.
I guess I was hoping I would see a pirouette/yaw left and right whilst the cam pointed the same way. That way I could gauge the smoothness and reaction time.

Do you know if it's magnetometer only, or slaved to accelerometer and gyro too to give better head hold?

Thank you

Matt

It was never magnetometer only - but in the latest version of the firmware you have the option to ignore the magnetometer all together.

If you choose to ignore the magenetometer the result will be that the heading value won't be aligned to the actual compass value (this isn't a problem as everything is used in a relative fashion - just a bit of confusion when looking at the setup client heading value), and there will be a small amount of drift over time. The drift will be very minor. The advantage of using this mode is that magenetic interference won't effect the system.

Ideally the craft should be built to isolate the gimbal so that you don't get magnetic problems. Then you can use the magnetometer properly. But if that isn't possible or practical, you can choose to ignore the magnetometer and still get very good performance out of the HoverflyGIMBAL.
 



thijmen5

Member
I actually got it working, and it works pretty well allready! My pots were indeed wrong installed. StillI got some jitter (much less than skyline though), but I think this might be the the gimbal it self? When it is standing on the desk powered on I can see the tilt lifting up and down just a bit every now and then, are there more people having this, or is it just me? To get my footage all straight I will still need some post.

What setting is used for smooth tilt control? I want to control the tilt with a turning knob on the graupner MX20, but it's moving quite abrupt when turning the knob. Smoothness on receiver setup allready is turned all the way, but didn't seem to have any succes(not sure the this is the setting I need)?

How can I minimalize the jitters even more? (AV130, stock savox) without investing even more money?

Saw that they uploaded new firmware, try it out soon as possible!
 
Last edited by a moderator:


DucktileMedia

Drone Enthusiast
yeah, that was the only other thing i couldnt ever get it to do was stay at the given position. it didnt seem to bother my camera operator so i just left it. but i would still like to know the secret to making this mode work. I cant even get it to work while plugged in to the assistant.
 

Forrest12

Member
yeah, that was the only other thing i couldnt ever get it to do was stay at the given position. it didnt seem to bother my camera operator so i just left it. but i would still like to know the secret to making this mode work. I cant even get it to work while plugged in to the assistant.

You can get it to work while plugged into the assistant by activating the pitch servo in the config then selecting all the operating modes one at a time then angle velocity and it works sometimes. Then click save while its working and then next time you turn the gimbal off " POOF it magically forgets"

Angle velocity on tilt still does not work when the pan compensation is switched off via the mode switch!!!!
Also Pan is horrible with the mag switched off, Drifts instantaly even after centering the servo it over shoots then keeps incrementaly creeping to the left.
Also small movements on pitch around center still are compensated excessively, the same as before..


Are you serious Hoverfly? You have not fixed any of the problems users have brought up here and other forums. When we bought this off you Al , you said it worked there would be no problems, only thing you said may be an issue is using an AV200, that it wasnt as good quality as the PSO. That has nothing to do with the issues that weve brought up here before, Is anyone from HF actually listening???? Am I dumb? Am I missing something? Can you fix this? Im over it...........................
 
Last edited by a moderator:

Al, how about a direct response as the tech staff you asked me to contact, "the lead developer" pretty much ignored me as HF has in general.
 

Whopis

Member
You can get it to work while plugged into the assistant by activating the pitch servo in the config then selecting all the operating modes one at a time then angle velocity and it works sometimes. Then click save while its working and then next time you turn the gimbal off " POOF it magically forgets"

Angle velocity on tilt still does not work when the pan compensation is switched off via the mode switch!!!!
Also Pan is horrible with the mag switched off, Drifts instantaly even after centering the servo it over shoots then keeps incrementaly creeping to the left.


Are you serious Hoverfly? You have not fixed any of the problems users have brought up here and other forums. When we bought this off you Al , you said it worked there would be no problems, only thing you said may be an issue is using an AV200, that it wasnt as good quality as the PSO. That has nothing to do with the issues that weve brought up here before, Is anyone from HF actually listening???? Am I dumb? Am I missing something? Can you fix this? Im over it...........................

I am doing some testing right now and will have a more detailed response for you later this morning.
 

Whopis

Member
You can get it to work while plugged into the assistant by activating the pitch servo in the config then selecting all the operating modes one at a time then angle velocity and it works sometimes. Then click save while its working and then next time you turn the gimbal off " POOF it magically forgets"

Angle velocity on tilt still does not work when the pan compensation is switched off via the mode switch!!!!
Also Pan is horrible with the mag switched off, Drifts instantaly even after centering the servo it over shoots then keeps incrementaly creeping to the left.
Also small movements on pitch around center still are compensated excessively, the same as before..


Are you serious Hoverfly? You have not fixed any of the problems users have brought up here and other forums. When we bought this off you Al , you said it worked there would be no problems, only thing you said may be an issue is using an AV200, that it wasnt as good quality as the PSO. That has nothing to do with the issues that weve brought up here before, Is anyone from HF actually listening???? Am I dumb? Am I missing something? Can you fix this? Im over it...........................

OK - there is a new version (1.6r0) out there now that corrects one issue and provides some more information and control to help you fix some of what else appears to be going on with your system. Please upgrade to the new firmware as well as the new setup client.

First, the angle velocity mode issue.
This was a bug in the software - it is now corrected. The angle velocity feature worked properly as one of the modes if you were using the "mode select" switch feature - however (as you saw) it wasn't working when you selected to always use that mode for a servo channel. In the latest version, this is corrected.

Regarding the pawn problems that you are experiencing. There appear to be a couple things going on here. Let's look at the drifting to left first.

Is this happening when you are in heading lock (switch in mode 1 or 2) or when you have heading lock disabled (switch in mode 0)?

If it is happening with heading lock disabled (mode 0), then it has nothing to do with using or not using the magnetometer. In this case, what I would suspect is that either the servo center position is not correct or the yaw stick from your radio is not sitting at the same value when it returns to center. These are the only two things that can effect the yaw servo in this mode. I know you said the servo center position was correct - so perhaps it is the transmitter stick.

When the gimbal board starts up, it looks at your stick positions and assumes that they are centered. Whatever value it gets at startup it will use as the center value - so make sure your radio is on before starting the gimbal and the sticks are centered. Then the firmware has a deadband range around this center where it will ignore small amounts of motion. This is to account for the mechanical slop that is present in transmitters. It is possible that this deadband range is not wide enough for your transmitter. In the new version (1.6r0), we have added the deadband width as a user-configurable parameter. You can find it on the Receiver Config page. There is a button marked "Set Bands" for each receiver channel. In addition to the deadband, you can also set the ranges at which it considers a switch to be in position 0, 1, or 2. You don't have to set the switch band values for a channel that you are using as a stick, or vice-versa.

If the drift is happening when heading lock is enabled, there are two possibilities as well. Again, the problem could be the yaw stick. In heading lock mode, the yaw stick works a bit differently. Instead of just sending a pulse width directly to the servo, it actually moves the heading value which the gimbal is trying to lock onto. This value is now displayed on the main screen of the gimbal configuration utility, labeled "Heading Lock". If you set up the gimbal and it begins to drift in heading lock mode, have a look at the "Heading Lock" value. If it is drifting, then the yaw stick must be sending a value that is outside the deadband range and causing the lock position to move.

If the heading lock value is not changing and it is drifting, look at the heading value. Is this value changing at all? It should not be moving very far away from the heading lock value. If you are seeing drift, and this value is not moving away from the heading lock value, then there must be a problem with the heading estimate. The most likely cause of this is temperature based drift on the gyro. If you are seeing this, repeat the gyro temperature compensation procedure and try again.
 


Whopis

Member
To eliminate the Tx/Rx in the equation, can this board be used standalone with Rx off?

Currently heading lock does not work without the transmitter. We could configure it to work in this mode if people want that. The reason that we avoided this initially was that most of the gimbals that we were working with that had yaw capability have the landing gear attached to the gimbal. This means that when you are in the air, the gimbal and landing gear will rotate with yaw, but when you are on the ground, the body of the craft will rotate with yaw.

So when you land with that type of setup, if you have any slight disturbance or error between where the board wants to be and where it actually is (which there is always a slight difference), it will start trying to rotate itself to that position - however it can't rotate itself and will instead rotate the top of the craft and keep doing so because it never gets to where it wants to be.

That's why we set it up so that you have to use a transmitter with a mode switch to use heading lock - so that you always have a way to turn it off for take off and landing.

With that said - the other axes work fine without a transmitter. So does yaw control for that matter - just not heading lock.

As I said, if it is a desired feature, we can make heading lock work without the transmitter - just be aware of the physical limitations and issues with your setup.
 

yeehaanow

Member
That makes sense. I wouldn't want heading lock to work without the TX. I would only use it for a one-man operation, and yaw the craft for panning.
 

What about the tilt issue?

OK - there is a new version (1.6r0) out there now that corrects one issue and provides some more information and control to help you fix some of what else appears to be going on with your system. Please upgrade to the new firmware as well as the new setup client.

First, the angle velocity mode issue.
This was a bug in the software - it is now corrected. The angle velocity feature worked properly as one of the modes if you were using the "mode select" switch feature - however (as you saw) it wasn't working when you selected to always use that mode for a servo channel. In the latest version, this is corrected.

Regarding the pawn problems that you are experiencing. There appear to be a couple things going on here. Let's look at the drifting to left first.

Is this happening when you are in heading lock (switch in mode 1 or 2) or when you have heading lock disabled (switch in mode 0)?

If it is happening with heading lock disabled (mode 0), then it has nothing to do with using or not using the magnetometer. In this case, what I would suspect is that either the servo center position is not correct or the yaw stick from your radio is not sitting at the same value when it returns to center. These are the only two things that can effect the yaw servo in this mode. I know you said the servo center position was correct - so perhaps it is the transmitter stick.

When the gimbal board starts up, it looks at your stick positions and assumes that they are centered. Whatever value it gets at startup it will use as the center value - so make sure your radio is on before starting the gimbal and the sticks are centered. Then the firmware has a deadband range around this center where it will ignore small amounts of motion. This is to account for the mechanical slop that is present in transmitters. It is possible that this deadband range is not wide enough for your transmitter. In the new version (1.6r0), we have added the deadband width as a user-configurable parameter. You can find it on the Receiver Config page. There is a button marked "Set Bands" for each receiver channel. In addition to the deadband, you can also set the ranges at which it considers a switch to be in position 0, 1, or 2. You don't have to set the switch band values for a channel that you are using as a stick, or vice-versa.

If the drift is happening when heading lock is enabled, there are two possibilities as well. Again, the problem could be the yaw stick. In heading lock mode, the yaw stick works a bit differently. Instead of just sending a pulse width directly to the servo, it actually moves the heading value which the gimbal is trying to lock onto. This value is now displayed on the main screen of the gimbal configuration utility, labeled "Heading Lock". If you set up the gimbal and it begins to drift in heading lock mode, have a look at the "Heading Lock" value. If it is drifting, then the yaw stick must be sending a value that is outside the deadband range and causing the lock position to move.

If the heading lock value is not changing and it is drifting, look at the heading value. Is this value changing at all? It should not be moving very far away from the heading lock value. If you are seeing drift, and this value is not moving away from the heading lock value, then there must be a problem with the heading estimate. The most likely cause of this is temperature based drift on the gyro. If you are seeing this, repeat the gyro temperature compensation procedure and try again.
 

Adidas4274

Member
Here is my 2nd video from my AP trip to Alaska.

Aerial video is done with the HF G
 
Last edited by a moderator:

Whopis

Member
What about the tilt issue?

This isn't a fix - but it may help figure out what is going on...

If you can, try swapping the roll and tilt servo outputs. Obviously the gimbal won't work properly when you do this - and you will have to be a bit careful as the motion will be counter-intuitive.

Just do this with one axis at a time. Connect the roll output to the tilt servo (leaving the roll servo disconnected). Then try again with the roll servo connected to the tilt output and having the tilt servo disconnected.

It is very odd that the tilt and roll would be producing drastically different results on different setups - the control for those two axes is really identical - just a different input variable (unlike the yaw which has a totally different type of control system).

It will be a bit hard to tell how well it is performing since the tray will not move counter to the motion of the gimbal - but see what result you get. I would expect to see one of two results by doing this. Assuming that in the original setup, the roll axis was working well and the tilt axis was not, you should see either:

1) The tilt axis continues to not work well while the roll axis continues to work well
or
2) The tilt axis works well when connected to the roll output and the roll axis performs poorly when connected to the tilt output.

I don't have a gimbal in front of me to try this on right now - but I believe that you could even go into the mounting configuration and change the mounting direction so that the tilt and roll axes were swapped (then the output would be appropriate for the motion). You would probably have to reverse direction on one axis or another to get it to work right. As soon as I get a chance, I will try this with a gimbal I have and see if I can come up with better instructions...
 

Adidas4274

Member
strange... in all the firmwares on my HF G with my gimbals i have not seen any issue with tilt. Definitely nothing drastic.
 



Top