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

[hackbard23]

ok, i finally towed away a scope from work and found the baudrate of the Serial bus: it is 230400 as the shortest signals are around 4.4µs

but at this baudrate i could not identify any real data, tried every combination of stopbits and parity and data length, so if anyone is able to read some data out of my dumps (maybe LSB and MSB are turned around or who knows what 3DR did) here they are:

MEGA

dumped @ 230400 8n1

 

[hackbard23]

ok, checked more of the data on the serial bus, thought this is normal ascii, but it isn´t as this scope screen shows:





it constantly spits out packets every 10ms consisting of 221 bit of data, the first 21 bits in the packet are always the same (identifier ?)
so, actualisation rate for the gimbal angle must be 100Hz

this is not a normal RS232 bus, it is homegrown by 3DR

added csv files from the scope for RX and TX lines to download (you can open them in Matlab, or similar)

MEGA

 

[just_bruce]

My brain is triggering on the 21 bits and the repeat interval... is that ModBUS or ProfiBUS? I'm on my tablet now so can't really do much with the provided dumps at the moment.... and that data is from steady state or moving the Solo about?

Thanks for this by the way...

 

[hackbard23]

data is from steady state
edit: uploaded one dump while in the move in every direction

 

[pyrate]

Nice work, somewhere in there are the keys to the remaining locked doors

 

[hackbard23]

if you have only 200 bits of information for 3 axis, and there are some start/stop and parity bits also, you will have about 6 or 7 byte for each axe @ 100 Hz

 

[just_bruce]

if you have only 200 bits of information for 3 axis, and there are some start/stop and parity bits also, you will have about 6 or 7 byte for each axe @ 100 Hz

There is probably a CRC byte tagged on the end if this is in fact MAVlink, which means 6 bytes. This actually seems to line up well with the protocol spec if we assume those first 21 bits contain the packet start and the header bytes....

As soon as I get time on a real computing device (non-tablet) I think I'll try extracting data on the assumption it is hex instead of ascii...

 

[hackbard23]

i doubt you can find something in the hex or ascii files as i dumped them with a normal rs232 port at 230400@8n1

but you can use the csv files from the scope with matlab, just wipeout the headerinfo

 

[hackbard23]

ok, i think i got it: it is Mavlink and it is transmitted like this:

startbit,8bit Data(LSB first),Parity(Even),stopbit = together 11 bit for one byte

made an error as the first 22 bits are the same, not 21....


edit: naaah, it is normal 8n1.... and first 21 bits are same (start byte, payload length)

 

[just_bruce]

Nice work.

But you're Makin the rest of us look bad.

 

[hackbard23]

it revealed itself by the start byte 0xFE
did you look inside the csv´s ?

 

[just_bruce]

it revealed itself by the start byte 0xFE
did you look inside the csv´s ?

Not yet. I haven't made it back in range of a real computing device and probably won't until monday, unfortunately.

 

[hackbard23]

Do you speak Mavlink ?

read some of the data in one single packet:

0111 1111 0xFE ;Packet start sign
____________________________________________________________
0101 0100 0x2A ;Payload length
42 Decimal
____________________________________________________________

1001 1100 0x39 ;packet No.
57 Decimal
____________________________________________________________
1000 0000 0x01 ;Sending System ID
____________________________________________________________
0101 1001 0x9A ; ID of the SENDING component
154 Decimal
____________________________________________________________
0001 0011 0xC8 ;ID of the message
200 Decimal
____________________________________________________________
Data


0A D7 23 3C 56 9F A1 B8 C8 C6 58 39 1F 20 15 B9 40 80 17 BB 37 D2 FE 3A 64 5F C5 BD 2F E3 4D 3D 8B 2E 58 BC 01 92 A8 BD 01 00 71 9E

last 2 bytes should be the CRC hash


Data stream is not ASCII, in ASCII it is:

×#<VŸ¡¸ÈÆX9 ¹@€»7Òþ:d_Ž/ãM=‹.X¼’¨½qž

if this is data is it 8bit ? 16 bit? signed ? unsigned ?

 

[just_bruce]

Okay, it's late, but I've been perusing Solo's python and believe the answer is unsigned 16 bit [ UINT16 ].

Will continue investigation when sleep has caressed my weary brain.

 

[hackbard23]

ah, good then in Big Endian it would be:

0 0A D7 2775
2 23 3C 9020
4 56 9F 22175
6 A1 B8 41400
8 C8 C6 51398
10 58 39 22585
12 1F 20 7968
14 15 B9 5561
16 40 80 16512
18 17 BB 6075
20 37 D2 14290
22 FE 3A 65082
24 64 5F 25695
26 C5 BD 50621
28 2F E3 12259
30 4D 3D 19773
32 8B 2E 35630
34 58 BC 22716
36 01 92 402
38 A8 BD 43197
40 01 00 256

in case of little Endian:

0 D7 0A 55050
2 3C 23 15395
4 9F 56 40790
6 B8 A1 47265
8 C6 C8 50888
10 39 58 14680
12 20 1F 8223
14 B9 15 47381
16 80 40 32832
18 BB 17 47895
20 D2 37 53815
22 3A FE 15102
24 5F 64 24420
26 BD C5 48581
28 E3 2F 58159
30 3D 4D 15693
32 2E 8B 11915
34 BC 58 48216
36 92 01 37377
38 BD A8 48552
40 00 01 1


will inspect some more pakets as i saw there are 3 DSP´s in the Gimbal.
Will see if the sending component or message ID´s are repeating

 

[just_bruce]

.....pakets as i saw there are 3 DSP´s in the Gimbal.
Will see if the sending component or message ID´s are repeating

The gimbal will definitely be sending back data. I'm pretty sure that I've discovered I was wrong and there is an accelerometer in the GoPro bracket somewhere. Or maybe on each in the arms.

So there should be a minimum of two sending component IDs

 

[just_bruce]

And on further investigation (now that I'm awake), that message is being sent by the gimbal [Component ID 154] .

Also, there may be mixed types. Might not be straight UINT16. Still reading....

 

[just_bruce]

Okay. Found it. Message ID 200:

Field 1 - UINT8_T System ID
Field 2 - UINT8_T Component ID
Field 3 - FLOAT Delta Time
Field 4 - FLOAT Delta Angle X
Field 5 - FLOAT Delta Angle Y
Field 6 - FLOAT Delta Angle Z
FIeld 7 - FLOAT Delta Velocity X
Field 8 - FLOAT Delta Velocity Y
Field 9 - FLOAT Delta Velocity Z
Field 10 - FLOAT ROLL joint angle
Field 11 - FLOAT ELEVATOR joint angle
Field 12 - FLOAT AZIMUTH joint angle

If we can gather the message IDs then I'll put together a spreadsheet to allow for decoding them.

I think getting another gimbal to work with SOLO might just be a matter of getting it to speak the correct dialect of mavlink.

 

[hackbard23]

Okay. Found it. Message ID 200:

Field 1 - UINT8_T System ID
Field 2 - UINT8_T Component ID
Field 3 - FLOAT Delta Time
Field 4 - FLOAT Delta Angle X
Field 5 - FLOAT Delta Angle Y
Field 6 - FLOAT Delta Angle Z
FIeld 7 - FLOAT Delta Velocity X
Field 8 - FLOAT Delta Velocity Y
Field 9 - FLOAT Delta Velocity Z
Field 10 - FLOAT ROLL joint angle
Field 11 - FLOAT ELEVATOR joint angle
Field 12 - FLOAT AZIMUTH joint angle

this is working with the data:

Field 1 - UINT8_T System ID = 10
Field 2 - UINT8_T Component ID = 215
Field 3 - FLOAT Delta Time = 1.02098432e-17
Field 4 - FLOAT Delta Angle X = -1.25214693e-18
Field 5 - FLOAT Delta Angle Y = 8.1417333e14
Field 6 - FLOAT Delta Angle Z = 7.482267e-26
FIeld 7 - FLOAT Delta Velocity X = 1.20986828e-24
Field 8 - FLOAT Delta Velocity Y = -6.1939391e+37
Field 9 - FLOAT Delta Velocity Z = -6053.9858
Field 10 - FLOAT ROLL joint angle = 198750944
Field 11 - FLOAT ELEVATOR joint angle = 1.6537194e15
Field 12 - FLOAT AZIMUTH joint angle = -2.09836488e-14

 

[hackbard23]

The gimbal will definitely be sending back data. I'm pretty sure that I've discovered I was wrong and there is an accelerometer in the GoPro bracket somewhere. Or maybe on each in the arms.

So there should be a minimum of two sending component IDs

would be nice if someone who has a broken gimbal, would make some photos of the IC´s on the PCB of the arms and the GoPro Plate PCB