Thanks for your response @rmackay9
I think you’ve answered at least one of my questions so thanks for that. I was trying ‘Retracted’ to see if the gimbal motors would turn off to check if the ‘Set Mount’ command had any effect.
Do I need to look further into the missing MAV_COMP_ID_GIMBAL or is that what you’d expect with the current software/firmware?
Hi
Using a ground rig I have just been testing the Gremsy gimbal improvements using a Pixy-U gimbal Firmware 7.7.1, Orange Cube V4.3.0-Dev and a Taranis X9D, but I’m having limited success.
Setting the Mount mode to “RC Targeting” the gimbal moves correctly with RC input except for the following.
Yaw and Pitch are connected to the Left and Right Sliders on the Taranis X9D but are difficult to control. I.E., after moving the slider enough to just move the pitch or yaw it then will move quickly to full deflection. It seems the same with Expo applied.
The “Mount Lock” switch works however Follow sets the gimbal about 30deg right of forward. This does not occur when connected and controlled via gTune
In Follow and lock the Yaw channel is smooth and responsive when connected to gTune.
When connected to the Cube via MAVLink the Yaw channel is slow and juddery.
Setting the Mount mode to “RETRACTED” does not relax the gimbal but it looks as if this hasn’t been implemented?
MNT_JSTICK_SPD parameter is missing in the parameters.
Right-mouse-button-click on the Mission Planner map and select “Point Camera Here” brings up a window asking for an altitude. Once this is entered and OK is selected the gimbal doesn’t move.
Some more information on the Mission Planner Actions options would be helpful.
I include my parameter file in case some of the setting are in error?
I’m not sure if this of any help but I would be interested in some fed back especially on controlling the gimbal pitch and yaw rates.
Peter
PixyU Test Parameters.param (17.9 KB)
This is an huge improvement for arducopter. Kudos to Randy and Gremsy!
Hi @Peterarnold,
Thanks for testing and reporting back.
MNT_JSTICK_SPD has been replaced by MNT_RC_RATE. This new param is slighlty more intuitive as well because the scaling is in deg/sec.
“Retracted” doesn’t relax the gimbal with gimbal version 7.7.1 but it does in 7.7.2 (but there are other issues with 7.7.2 so I’d recommend sticking with 7.7.1 for now)
I wonder if maybe the vehicle doesn’t have a position estimate (aka GPS lock)? To be able to properly switch between “body frame” (aka “follow”) and “earth frame” (aka “lock”) the gimbal needs to know the vehicle’s attitude and for the “Point Camera Here” the vehicle must know its position…
Hi Randy @rmackay9
Thanks for your reply. MNT_RC_RATE works well but I am still having problems with Yaw. When in Lock or Follow and the rig the gimbal is mounted on is moved the gimbal is very slow and juddery when it tries to correct its yaw position. The only setting I can find is the Follow speed in gTune which doesn’t help. I have compared this to when using SBUS connection and when using that the gimbal corrects normally so it has something to do with the Mavlink connection settings I have??? I also cant get the select “Point Camera Here” in the Mission Planner map to work. I have a GPS 3D Fix and HDOP 1.42. I’m not sure how to fix that.
If you have any suggestions it would be appreciated.
I’ve updated the Gremsy setup instructions here on the wiki.
There are GCS developer focussed instructions going into the wiki soon (see PR here)
MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW does work (make sure you’ve got Copter/Rover/Plane-4.3.0-DEV installed of course) although I have not tested it on an upward facing gimbal. Do you have an onboard log file you could share? You might need to set LOG_DISARMED = 1 in order to create a log while the vehicle is disarmed.
The real-time attitude of the gimbal is available in the GIMBAL_DEVICE_ATTITUDE_STATUS message. For the moment at least these are only in Quaternions and always in body-frame regardless of whether the target has been provided in body-frame or earth-frame (aka “follow” vs “lock”).
I have been planning to add support for GIMBAL_MANAGER_SET_ATTITUDE in case that would be helpful.
Hope that helps.
Thank you for your swift response.
Yes, we are testing out the 4.3.0
Just switched LOG_DISARMED to 1. Will share it as I get some data.
MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW gives the
COMMAND_ACK {command : 1000, result : 3, progress : 0, result_param2 : 0, target_system : 255, target_component : 0}
As I understand it reports it as unsupported command.
Could you please share the message example, maybe we are doing it wrong somewhere.
On the GIMBAL_MANAGER_SET_ATTITUDE side we have no immediate use to it.
ok great. The wiki page describing the format of the MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW message is here. I suspect if you compare this to what’s being sent you’ll find the issue but… I can’t be sure of course.
Here is the log. 230MB!
msg = the_connection.recv_match(type=“GIMBAL_DEVICE_ATTITUDE_STATUS”, blocking=True).to_dict()
message, does not update, what is received when the scrips starts keeps rolling, with slight changes on second and later decimals. If gimbal is held in certain way it will register it on the script start, keeping almost the same values even it moved to another position. Computer is connected to CUAV X7 pro via USB cable, if that makes any difference.
Hi @naturobotic,
I suspect the issue is a configuration issue.
Txs for the logs and giving this new driver a try.
Gremsy has the latest firmware - 7.71
Telem2, regarding the communication, there DO_MOUNT_CONTROL works and GIMBAL_DEVICE_ATTITUDE_STATUS sends at least one message. However I’ll try to look into the communication further.
I do not use the RC, this pixawk is dedicated only to the Gimbal.
Gimbal does work with DO_MOUNT_CONTROL with Tilt avoiding comanded angles between -40 and +40 deg, that is why DO_GIMBAL_MANAGER_PITCHYAW came to mind.
Yeah, checks are off as the other pixawk flies the drone. Would you suggest to activate some?
If DO_MOUNT_CONTROL works then DO_GIMBAL_MANAGER_PITCHYAW should also work assuming these messages are being sent to the autopilot and not directly to the gimbal.
I noticed also that SERIALx_OPTION hasn’t been set to 1024.
I think it might be a good idea to:
master.mav.command_long_send(
master.target_system,
master.target_component,
#msg = vehicle.message_factory.command_long_send(p, y)
#1, 1, # target system, target component
mavutil.mavlink.MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW, #command
1, #confirmation
60, # param 1, yaw in degrees
5, # param 2, yaw speed deg/s
float("NaN"), # param 3, direction -1 ccw, 1 cw
float("NaN"), # param 4, relative offset 1, absolute angle 0
0, 0, 0) # param 5 ~ 7 not used
# send command to vehicle
# vehicle.send_mavlink(msg)
msg = master.recv_match(type="COMMAND_ACK", blocking=True)
print(msg)
gives out result 3 again.
mavproxy works well with DO_MOUNT_CONTROL with ±40 ignorance.
It appears that communication from the PX4 is the issue, as it doesn’t update the compass either, it takes more than 2 seconds to update the North.
It is communicating with Win 10 over the COM port.
Gimbal commands are responsive, feedback from the PX seems to be the issue.
What do you propose?
Would the companion RPI4 maybe solve the communication issue.
I’m sorry to repeat myself but I think it would be good to do these 3 things:
Thanks for you assistance,
Unfortunately we do not own RC controls at the moment.
Further, the MAVproxy console gives:
message COMMAND_LONG 0 0 1000 0 float("NaN") float("NaN") 0 5 0 0 0
We are seriously confused, replicated it on another X7 pro with another T7 with the same results.
DO_MOUNT_CONTROL works well on all axis, until it has to go between -40 to +40. Solving this would solve our issue. Do you have any ideas why is it happening?
4.2.3 does not talk to T7 at all, with 7.7.1 firmware.
We also noticed you had 7.7.2. can we maybe test it?
Look at the title of this post: T7 7.7.1 requires ArduCopter 4.3-x.
Hi @naturobotic,
Re MAVProxy’s message, did you type in “module load message” first?
On the wiki page linked it says this:
The example commands below can be copy-pasted into MAVProxy (aka SITL) to test this command. Before running these commands enter:
- module load message
Maybe the formatting of this was not clear? Maybe I should move the “module load message” up so it’s not a bullet point.
By the way, I think investigating in getting an RC transmitter/receiver is a good idea. flying a drone without any RC is somewhat dangerous especially if you haven’t flown it before. It will also make the setup much easier.
Hello I test following this post upgrading gimbal t3v3 and autopilot with 4.3beta. It works relly better than before in auto mode and in speed mode.
Just for this who want to use rc in angle mode with rc pot, the gimbal still not reacting proportionality to the pot for pitch for example.
Can you check this feature for feedback?
Hi @kuspower,
Txs for testing the new Gremsy gimbal driver. So you’re saying that the gimbal’s actual pitch is not reaching the limit you expect? I suspect the issue is a mismatch between the gimbal’s internal pitch range and the MNT1_PITCH_MAX parameter. I have added this to the 4.3 issue list for investigation and I will test on my own vehicle but if you have a log file that might also be useful.
Txs again.
Hello Randy, no is not this behavior.
The gimbal achieve min max angles so no issue on this sides.
Pitch Min max are 90. -90.
Pot is set on Rc8 1000-2000us no dead band.
So pot set to 1500 gimbal is at 0 perfect
If pot is set between 1500 1750 or 1250 1500 nothing.
If pot is set to 1751 or 1249 gimbal axes ±45deg directly.
Over this values we have expected proportional behavior.
So its impossible to pitch between 1 to 44 or -1 -44 deg