I need help Interfacing 3DR solo pixhawk with RPi

Hi ,
I have a 3dr solo that I am currently trying to interface with a Rpi 0 for telemetry.I have connected the 5V GND TX RX of the Pi to 5V GND serial2TX serial2RX of the solo’s accessory port. Ref:(https://3drobotics.github.io/solodevguide/hardware-accessorybay.html). I made sure to change the SERIAL2_PROTOCOL to Mavlink (1 on Mission Planner) and SERIAL2_BAUD to 115 as per my mavlink router command. However, I am unable to connect to Mission Planner over UDP.
I have an Iris+ which seems to connect to MP easily with the same Raspberry Pi. On the Iris+ I connected the telem2 of the pixhawk to the Pi 5v,Gnd,Tx,Rx with the SERIAL2_BAUD and SERIAL2_PROTOCOL same as the Solo.

Is there anything different in the Solo that I should take into consideration?
Any suggestions would be appreciated.

Thank you

Serial 2 should work on Solo. You have APsync installed on the RP0 right?
Then check the cable connection inside Solo between the motherboard and the accessory bay. Those cables often and easily break off the main board.

Question, what is your use case if I may ask?
Other than a Iris, Solo has a full fledged companion computer on board, and by connecting to the Solo wifi network you have full access to all telemetry and parameters via mavlink. On the other hand, If you want to develop some new stuff you can do it directly in Python on the IMX companion computer.

Hi @mtbsteve! Thanks for your help :slight_smile: I’m working with Niharika on this.
We don’t actually have ApSync – just Raspbian (Stretch Lite) configured to connect to our network and stream its Pi camera over UDP.
We’ll have a look at the cables but last we checked we were getting ~3V on the TX and RX so I’d assume they’re still soldered on.
We have the stock cube but updated to Open Solo – if that makes a difference.

As for our use case, it is related to this other post.
TL;DR: we aim to operate multiple drones as a swarm over a network and we need all the UAVs to be connected to that same network as clients as opposed to our GCS connecting to wash UAV network.

I imagine we could tinker with the IMX code but it seemed easier to slap a RPi on it to start out. We will also want to connect a Flir One or Seek thermal, and one person reported no being able to build the Flir loopback driver on IMX due to kernel compatibility issues.

Alright- nice project!
You may then also check BRD_SER2_RTSCTS: Serial 2 flow control
normally it is set to 2 (autodetect)
As said, Serial 2 works, I have a Lidar connected on Serial 2 on one of my Solos which worked instantly after setting the right baud rate.

Hi @mtbsteve thanks for your response. I just checked the BRD_SER2_RTSCTS and it was set to 2 as you mentioned. I set it to 1 and tried again but there was no difference. However, it looks like that parameter is set when we connect the RT and CT pins from the accessory port. I am connecting the serial2RX and serial2TX pins of the accessory port to the rx and tx of the pi.
We also updated to open Solo 3.0.0 for the Stock solo. I don’t know if that needs something different to enable the Serial2 . We noticed our Gimbal is not detected after the update but we are yet to investigate if that is because of the update or a faulty hardware.

There is nothing different to enable Serial 2 with Open Solo.
The gimbal is connected to Serial 4. Likely something went wrong during the update if it was working before.
Just to make sure, you need to cross the Tx and Rx lines, connect Tx on the RPI with Rx on Solo.
If all doesn’t help, I would test Serial 2 with another device or a logic analyzer to rule out any hardware defects.

2 Likes

@mtbsteve you’re right the gimbal issue turned out to be an error in the update itself. We fixed it by doing a factory reset.
For the serial2 communication, We figured its probably an issue with the way we do our mavlink router. I’m yet to find out what exactly is going on but it dint work with mavlink router initially then we tried it with mavproxy, it worked. Then we re tried with mavlink router and it magically seemed to work. So I’m not sure if running Mavproxy enabled something or its just a co incidence and the cables were loose. But we have 2 solos and they both behaved the same way. My initial set up of connecting 5V GND TX RX of the Pi to 5V GND serial2TX serial2RX of the solo’s accessory port is what I maintained so my TX and RX was connected correctly.
Anyway, thank you for your help :slight_smile:

1 Like

@mtbsteve We just figured that the gimbal not working is related to changing the SERIAL2_PROTOCOL. I did a full factory reset and checked the gimbal - it worked fine. Calibrated the Accelerometer, Level and Compass and checked the gimbal - it worked fine. I attached the Rpi to the Serial2 of the accessory port and checked the gimbal worked fine. I then changed the SERIAL2_BAUD to 115 and SERIAL2_PROTOCOL to 1 for Mavlink and then ssh into the Pi and ran this command

root@raspberrypi:/home/pi# mavproxy.py --master=/dev/ttyS0 --baudrate 115200 --out 192.168.1.200:14550 --out 192.168.1.202:14550 --aircraft MyCopter

to start Mavproxy, Mavproxy started, I was able to connect to it through Mission Planner on port 14550 at Baud 115200 but the Gimbal stopped working. The controller says “Solo Gimbal not found”. On further investigating we figured changing the SERIAL2_PROTOCOL to 1 for Mavlink seems to be the issue. I noticed SERIAL4_PROTOCOL is Mavlink as well. @mtbsteve @Pedals2Paddles would you have any recommendations to work around this?

Hmm hard to tell. I always use mavproxy with APsync.

Can you connect when you try in an RPI terminal:
sudo -s
mavproxy.py --master=/dev/ttyAMA0 --baudrate 921600 --aircraft MyCopter

You may check also the —mav10 option.

Last idea I have is a potential conflict of mavproxy ID’s with the gimbal.
Try to change the id with option
--source-system 217 (that’s what I have set on my TX2)

@mtbsteve, thank you for your response. I tried with another solo. I did a factory reset which reset it to Open solo defaults. I calibrated and then just changed the SERIAL2_PROTOCOL to 1 , rebooted and the solo gimbal stopped working without even connecting it to a Pi and starting Mavproxy.
In your setup do you also have Open Solo? We just want to narrow down what the issue might be. If its Open Solo, or the stock cube , firmware or hardware itself.

@mtbsteve we just checked putting SERIAL2_PROTOCOL to 9 for Lidar and the Gimbal seems to work. So its just setting it to 1 or 2 (Mavlink 1 or Mavlink2) which breaks the Gimbal.
@rmackay9 do you know if this is fixed (changing SERIAL2_PROTOCOL to 1 or 2 for Mavlink on the Solo breaks the Solo gimbal. Controller says ‘Solo gimbal not found’ ) We are planning to move to Arducopter 3.7 once it is released as we currently don’t have a green cube but was wondering if its been fixed.

@NiharikaPatel, I’m afraid I don’t have much experience with the Solo gimbal. There’s an issue here re some issues faced with using it with Copter-3.7 but the issue seems to be that it’s not performing well, it is at least connecting though.

@rmackay9 thank you for your response. The gimbal works fine if serial2_protocol is flipped back to 0. Its just something interfering when its set to 1. I found more people who had this issue but no one seems to figure it out. https://github.com/3drobotics/solodevguide/issues/292#issuecomment-523239004
https://3drpilots.com/threads/serial-2-and-gimbal.5196/

@NiharikaPatel This sounds weird.
Just for the records, I am not using OpenSolo but this issue should be unrelated to it in my humble opinion. I have a stock Solo setup with currently Arducopter 3.6.7 Nuttx directly installed. I can confirm that Serial2 is working with SERIAL2_PROTOCOL set to 1 on my 2 Solos along with Gimbal since Arducopter 3.5 (thats when I tried Serial2 the first time). If it helps, here is one of my Solo param files as of AC 3.6.0 with Serial2 enabled.
https://1drv.ms/u/s!AnKeW8KMoCcymAJY9g4AihKKShjJ?e=1dN9MX
Maybe its in some other param settings, or I still wouldnt rule out a hardware (cabling) defect.

@mtbsteve thanks for sharing the Param file – we’ll compare with ours!
A hardware/cabling issue is not impossible but rather unlikely I’d think, since the same behavior is observed on both Solos. We have a third one that is not yet on Open Solo, we’ll see how this one behaves.

Side note, to clarify, you straight up flashed “regular” AC firmware on the stock Solo with stock 2.0 cube? Is that not supposed to put the Solo at risk of dropping from the sky because of the 3V vs 5V signaling ? Did you DIY a voltage step up to the ESCs or change the ESCs altogether?

@rmackay9 Thanks for chiming in. As Niharika mentioned, the issue is present when the SERIAL2_PROTOCOL is set to 1 (Mavlink) or 2 (Mavlink 2), setting to other values does not seem to interfere. Our understanding is that the gimbal is on Serial4 and our default Parameter List how SERIAL4_PROTOCOL set to 1 with a baud of 230. So it feels like the serial 2 Mavlink is somehow interfering with the serial 4 mavlink. It might be an issue with the Solo-Ardudopter or gimbal firmware.

@rmackay9 @mtbsteve We just updated our Solo to AC 3.7 dev and can confirm that that the Serial2_PROTOCOL issue is sorted. The Gimbal works fine with Serial2_PROTOCOL set to 1. On another post @Pedals2Paddles said it might just be a bug in the older firmware.