Open Solo + Rpi + Gimbal

Joined
May 8, 2019
Messages
16
Reaction score
2
Age
30
Hello everyone,
I have a problem with a gimbal since going under Open Solo (version 4).
The gimbal is controlled from an Rpi with a shield to control 2 servos. The Rpi retrieves information from the connectors of the gopro gimbal via USB.
The camera’s stabilization works correctly but I can not tilt manually the gimbal with the controller. If, when switching on the drone, the inclination of the gimbal is 45 ° on the controller, the gimbal will be placed at 45 ° but I will not be able to change this angle any more. Do you have a solution to control the gimbal manually ?
Thanks

Codes to control the gimbal :
 
Joined
May 9, 2017
Messages
1,354
Reaction score
524
Age
40
Hello everyone,
I have a problem with a gimbal since going under Open Solo (version 4).
The gimbal is controlled from an Rpi with a shield to control 2 servos. The Rpi retrieves information from the connectors of the gopro gimbal via USB.
The camera’s stabilization works correctly but I can not tilt manually the gimbal with the controller. If, when switching on the drone, the inclination of the gimbal is 45 ° on the controller, the gimbal will be placed at 45 ° but I will not be able to change this angle any more. Do you have a solution to control the gimbal manually ?
Thanks

Codes to control the gimbal :
I feel like you're going to need to to supply a bit more info here.
Serial control?
Have you modified any python files?
Did it work initially and now it doesn't?
Have you searched for gimbal tilt on the forums? There are a number of threads about such.

In short, please expound a bit.
 
Joined
May 8, 2019
Messages
16
Reaction score
2
Age
30
The raspberry gets the information by Mavlink. Python files have not been changed. They are found in the raspberry. The manual tilting of the gimbal has never worked under opensolo but works with the original firemware. The topics I found dealing with this problem do not use the connectors of the gopro gimbal. It must be missing a script in the raspberry which reads the value of the camera paddle.
 
Joined
Mar 12, 2016
Messages
3,866
Reaction score
2,560
I can tell you the gimbal control on Open Solo is no different than it was in the old firmware with one exception. The mavlink messages being sent to the gimbal are no longer using broadcast system and component IDs. The mavlink channel is set for private, which means only mavlink messages that match the vehicle system ID, and match the gimbal's component ID will be sent out to the gimbal. Which means system ID 1 and component ID 154 (MAV_COMP_ID_GIMBAL). So, if whatever is running on that rPi is looking for a broadcast system ID (0) only, or looking for a broadcast component ID (0) only, or it has some other component ID not MAV_COMP_ID_GIMBAL (154), it will not communicate.

The original driver for the gimbal in ardupilot used broadcast everything, which was kinda stupid. And we found that the gimbal was being bombarded hard by everything else on the copter also sending broadcast messages, causing the gimbal to lose its mind and twitch. It was a waste of effort for the gimbal to decode and reject a million broadcast messages it doesn't need. So we privatized the channel, making it so the gimbal only gets its own gimbal messages matching the vehicle system ID and the gimbal component ID.

The change is here: Solo: fixed a problem with "twitches" on Solo gimbal by tridge · Pull Request #9875 · ArduPilot/ardupilot
 
  • Like
Reactions: yarrr
Joined
Mar 12, 2016
Messages
3,866
Reaction score
2,560
Correction: The original driver was always using the vehicle system ID and gimbal component ID. So all the existing Solo Gimbal mavlink traffic should still be coming through unchanged. The only thing that changed was blocking any and all mavlink traffic that was not specifically for the vehicle system ID and gimbal component ID.

Are you using some other mavlink messages to control your thing? LIke expecting to receive digicam_control command from an auto mission maybe? Usually those are sent as broadcast so any camera on any gimbal will receive it. But that broadcast will be blocked due to the broadcast component. If you're looking for the gopro shutter mavlink command, that is not currently being triggered by GCS and auto mission camera commands. But I have an update in progress to address that.
 
  • Like
Reactions: Wetstone
Joined
May 8, 2019
Messages
16
Reaction score
2
Age
30
Here's what happens with a sample code :

import ConfigParser
ConfigSolo = ConfigParser.ConfigParser()
SoloSerialPort = ConfigSolo.get("Solo", "SoloSerialPort") #SoloSerialPort : /dev/ttyUSB0
SoloSerialBaudrate = ConfigSolo.get("Solo", "SoloSerialBaudrate") #230400
vehicle = connect(SoloSerialPort, baud = SoloSerialBaudrate, wait_ready=['system_status','attitude','channels'], heartbeat_timeout=30)
while 1:
print(vehicle.channels['6'])

the vehicle.channels['6'] is not updated. The camera paddle in the controller is not read continuously. vehicle.channels['6'] reads only the value when the script starts.

This code is good with the stock firmware.
 
Joined
Mar 12, 2016
Messages
3,866
Reaction score
2,560
Oh, so this actually has nothing to do with mavlink. You're using dronekit python to obtain the RC Channel 6 input, which is the gimbal tilt channel. I don't know why you wouldn't be getting data on that. Try checking parameter SR1_RC_CHAN. It should probably be 5hz. But if it is zero, you'll get nothing.
 
Joined
May 8, 2019
Messages
16
Reaction score
2
Age
30
I thought that the problem came from Mavlink but by testing bits of code I noticed the error. I will look at the value of the parameter SR1_RC_CHAN
 
Joined
May 8, 2019
Messages
16
Reaction score
2
Age
30
In the stock firmware and in OpenSolo firmware, SR1_RC_CHAN = 5
 
Joined
Mar 12, 2016
Messages
3,866
Reaction score
2,560
OK. Well I certainly haven't changed anything in Open Solo that impact Drone Kit getting the RC channel values from ArduPilot. And DroneKit itself hasn't been updated in years too. I'll check some other people on the ArduPilot dev team to see if something changed in there related to how RC values are being sent out on mavlink. In the meantime, can you verify this problem exists with channels other than just 6?
 
Joined
May 8, 2019
Messages
16
Reaction score
2
Age
30
I think the problem comes from the dronekit version. There was an update 1 year ago.
By installing the latest version on my pc, the script works normally.
I am updating the raspberry which is on the drone. I keep you informed
 
Joined
May 8, 2019
Messages
16
Reaction score
2
Age
30
The error comes from the SoloMapper.py script.

This code works on the Raspberry :

from dronekit import connect
vehicle = connect("/dev/ttyUSB0", baud = "230400", wait_ready=True)
while (1) :
print(" Ch6: %s" % vehicle.channels['6'])

But vehicle.channels['6'] is not updated in the SoloMapper.py script.
Strange ...
 
Joined
Mar 12, 2016
Messages
3,866
Reaction score
2,560
So the information is available and coming through. It's a script problem on the mapper?
 
Joined
May 8, 2019
Messages
16
Reaction score
2
Age
30
from MavlinkConfig import MavConfig
# Configure the stream of messages from the drone to the Raspberry (Serial Port 4)
configurationMavlink = MavConfig(vehicle)
configurationMavlink.ConfigureStreamMessage()

if i comment on the last line, the code works, vehicle.channels['6'] is updated.

would there be a confit with mavlink ?
 
Joined
May 8, 2019
Messages
16
Reaction score
2
Age
30
MavlinkConfig.py :

class MavConfig:
droneSolo = 0
def __init__(self,vehicle):
self.droneSolo = vehicle

def ConfigureStreamMessage(self):
msg = self.droneSolo.message_factory.request_data_stream_encode(0,0, 1, 0,0)
self.droneSolo.send_mavlink(msg)

msg = self.droneSolo.message_factory.request_data_stream_encode( 0, 0, 2, 0,0)
self.droneSolo.send_mavlink(msg)

msg = self.droneSolo.message_factory.request_data_stream_encode(0,0, 4,0,0)
self.droneSolo.send_mavlink(msg)

msg = self.droneSolo.message_factory.request_data_stream_encode(0, 0, 11, 0,0)
self.droneSolo.send_mavlink(msg)

msg = self.droneSolo.message_factory.request_data_stream_encode( 0, 0, 12, 1,1)
self.droneSolo.send_mavlink(msg)

## set RC CHANNELS messages frequency
msg = self.droneSolo.message_factory.request_data_stream_encode( 0, 0, 3,20000,1)
self.droneSolo.send_mavlink(msg)

msg = self.droneSolo.message_factory.request_data_stream_encode( 0,0,10,1000,1)
self.droneSolo.send_mavlink(msg)
 
Joined
Mar 12, 2016
Messages
3,866
Reaction score
2,560
WTF, why are they doing all that?? First they are cutting off all the other data streams, which they shouldn't be doing. And then they're setting RC channels one is requesting a stream rate of 20,000hz. The default is 5hz. And setting the extra1 stream to 1000hz, which is also insane. I suggest setting both of those 50 and seeing it is happier.
 
  • Like
Reactions: Wetstone

New Threads

Members online

Forum statistics

Threads
12,324
Messages
142,938
Members
14,351
Latest member
Tom543