The Solo Gimbal and the Code that Drives it. Hmmm....

[Jubalr]

???? that makes no sense ????

normally the controllers get the actual motor position from the potentiometer and than it regulates to the desired position by sending incremental signals to the H-Bridge in CW or CCW direction.
The only thing is that the H-Bridges could be to weak to switch the higher current to the motors

the controllers are only for position-regulation, power is handled through the H-Bridge (DRV8313)
http://www.ti.com/lit/ds/symlink/drv8313.pdf

That could be where the issue was. I know a lot of people smarter than me have been trying to crack this problem. We gutted the Solo gimbal, even tried using just the controller, and tried modifying the existing gimbal and motors to go bigger. Ended up with building the gimbal with Storm 32, which is very comfortable with mavlink. But at least we have the clearance issue resolved...

That's all Solo in the top box.

 

[hackbard23]

looks like "Big Mama" needs a GPS Shield

 

[Jubalr]

looks like "Big Mama" needs a GPS Shield

Yes, that photo was during testing. There is a top cover and the GPS/Compass on a 4" stand.

 

[just_bruce]

All he did was keep the motors and housing and replaced the controllers to use on another quad. The secret sauce people are looking for is the ability to drive another/larger gimbal with the Solo code to be used in smart shots the same as the solo gimbal. I would pay someone $500 that could provide me with the ability to do that now.

If I understand what is being sought, it's the source code to the embedded TMS320 micrcontroller/DSP ?

Because I think it'd be possible to either brick-wall bang or serial-sniff the MAVlink codes to allow another MAVLINK-CAPABLE gimbal to work.

Or maybe I don't understand what is being sought when people refer to "secret sauce"?

 

[hackbard23]

i think mavlink sniffing is not the answer, as all the calculations are made inside the IM6

correct me if i´m wrong but the gimbal is working like this:

DSP receives desired angles (pitch,yaw,roll) via Mavlink from iM6 and translates them to PWM Signals for the H-Bridges. H-Bridges power the gimbal motors and the potentiometers give angle feedback to the DSP.

USB is only used for the gopro remote
HDMI is for video transmission

this is how i would build it with the given hardware

the "juice" is in the iM6, as it counteracts the angle of the bird detected by the IMU with exact the same angle in the other direction. This information is sent to the Gimbal DSP over mavlink.

now it starts to be really complicated: in smart shots, there is a lot of more calculations than this....
think of the mode "look at me", solo has also to use the altitude information for the calculation and the distance to the controller...... not an easy task

 

[pyrate]

that about sums it up
it is the mathematics that are hidden in the IMX code that we need.
Or have to write from scratch
I have been considering getting an alexmos and start digging around the net for gimbal targeting code to see if there is any out there.
Hard to believe someone somewhere has not worked on it outside 3DR
lots of applications for targeting and positioning servos and gimbals to point them at things

 

[just_bruce]

that about sums it up
it is the mathematics that are hidden in the IMX code that we need.
Or have to write from scratch
I have been considering getting an alexmos and start digging around the net for gimbal targeting code to see if there is any out there.
Hard to believe someone somewhere has not worked on it outside 3DR
lots of applications for targeting and positioning servos and gimbals to point them at things

The mathematics don't, on the surface, seem that complex. Yes, there is some trigonometry involved in things like smart shots, and probably a PID loop as well, but if there is reported attitude from both the bird and the gimbal, it's subtraction.

Or am I over simplifying?

 

[pyrate]

Most likely not if your a math head
I really dont see why it is so mysterious.
Not that I could whip out the code, but the application is such that I cannot believe someone has not done considerable work in this area somwhere already
we just need to find a good opensource library or solution and figure out how to apply it to an alexmos
with input from the FC as parameters of the equations

 

[hackbard23]

mabe we have a math genius here and someone who can translate the math into code and we are done

 

[just_bruce]

Before we get too carried away, shouldn't someone verify that:

1. The gimbal controller is accepting angle requests via MAVlink and that we know what all the appropriate syntax is
2. That the gimbal itself is outputting the angles it is currently holding
3. There isn't an identifier that the gimbal puts out to signal to the companion computer that it is genuine "Made for Solo"

?

I'm quite positive I could could cruft something VERY ugly together based on current available open source firmware if those things hold true. Note I didn't say I could do it quickly.

 

[hackbard23]

ok, i think i will solder some man in the middle cable, as i wanted to exchange the stiff serial gimbal cable to a softer one in the next days.

holding powered solo in hand and dump the communication while rotating solo should be enough to examinate.

pretty sure it is 115.2Kboud and ASCII

 

[just_bruce]

Sweet. Post your logs logs if it ends up being even semi-intelligible?

 

[hackbard23]

@Jubalr:

Did your Storm32 controller work with the other Gimbal on the iM6 ?

 

[Pedals2Paddles]

The communication between the Solo and gimbal is not locked up, hidden, or secret. It's just mavlink serial data. There isn't anything secretive about it The mathematics isn't either. The python code in the companion computer has lots of it. And a lot of it is in ArduCopter too, in the form of C++. What hasn't been released is the source for the gimbal itself.

 

[hackbard23]

yup, i want to collect the data and signals to the TMS320 DSP (aka what the source is looking like)

are the commands send over the mavlink protocol in the python scripts ?
am i right that it is only the desired xyz angle the gimbal should lean to ?

as i can see from the TMS320 Datasheet, 50% of the source code for the Gimbal must be mavlink protocol and i doubt mavlink is fully implemented (TMS320 by nature can´t understand mavlink)

 

[just_bruce]

Nearly any gimbal controller firmware is concerned mostly with high-speed math and a PID loop. This one has Go PRO control, and speaks MAVlink. I guess I'm confused what is considered so special about the Solo's gimbal controller firmware. Hard to know where to direct my efforts if I don't know what I might be aiming at.

 

[just_bruce]

The communication between the Solo and gimbal is not locked up, hidden, or secret. It's just mavlink serial data. There isn't anything secretive about it The mathematics isn't either. The python code in the companion computer has lots of it. And a lot of it is in ArduCopter too, in the form of C++. What hasn't been released is the source for the gimbal itself.

What do you suppose is to be found in that source that is special or different? If all the smart shot math is exposed, and the serial comms are known, my head is a little stuck on what is keeping us from swapping in a separate gimbal that speaks MAVLINK ?

 

[hackbard23]

tried to dump the UART lines now, but i could not find the right baudrate/parity/data/stop combo. i think i will need a scope for finding at least the right baudrate. will get a scope next week and will see what i can do....
seems that 3DR made it extra complicated, or they added extra safety for the gimbal data

 

[pyrate]

go guys go
with all the other things going on, taking the gimbal out of the mix is the last big obstacle to super solos being very common

 

[h8id]

The gimbal acts like its sleep walking until the controller connects.. might just be a part of the way it all ties together, but it seems to suggest the 'magic' happens on the controllers IMX6... maybe to reduce load on the Solo companion computer? I kinda assume the little circuit board behind the Go Pro back port plug on the gimbal is somehow supplying different information then an IMU on a typical gimbal. I thought I read somewhere the stabilization was based on weight distribution as opposed to gyroscopic information... although to me that seemed like a bad idea and is likely not true.