flytPi+ 3DR Solo Parameters


I have a flytPi and a 3DR Solo drone.
The flytPi is connected to drone, however when I issue takeoff command, I get this message:
Could not communicate with autopilot, make sure these parameters are set correctly: SERIAL2_BAUD=921, SYSID_THISMAV=1 and SERIAL2_PROTOCOL=1

Can you tell me what the values of the parameters have to be?
Also it says no GPS lock even when the remote does get a lock. I had the GPS lock message also, but that got resolved by placing the drone right next to window. (propellers are off, I’m just testing communication for now).

(but in this case it couldn’t take off because of the parameters).

Thanks for the help


Few more details - I did manage to spin the rotors using calibration screen (but they don’t seem to be in the correct order).

On the frame selection screen there is a red message saying - not available with APM. (but there I can see an option to select 3DR Solo as a frame).

Please advise on the parameters issue.

Also the GPS doesn’t seem to say GPS lock even if it has 9 satelites connected and the remote control shows: press FLY to takeoff. (we are indoors, so maybe this would work outside).



Can we get a reply on this thread? How do we solve this message:

Could not communicate with autopilot, make sure these parameters are set correctly: SERIAL2_BAUD=921, SYSID_THISMAV=1 and SERIAL2_PROTOCOL=1

When trying to takeoff? (3DR drone + flytPi)


Hi @aluca,

Sorry for the delayed response.

FlytOS throws this error if it does not get ATTITUDE message from the Autopilot. GPS Lock issue could also be related to FlytOS not receiving LOCAL_POSITION or GLOBAL_POSITION message.

Please send us the last few FlytOS runlogs, so that I could debug this issue for you. Click here to know how to fetch runlog.


Thanks for the reply - I will be able to send logs tomorrow only. I will try takeoff again, and provide fresh logs. I will take the drone outside to make GPS signal better also.

The message’s meaning is that those parameters should have that value? I checked and they did except for SERIAL2_PROTOCOL which was 0. I set it to 1 and used the Upload feature. Did that save the parameter in flytOS memory, or did it do some changes to the drone autopilot also?

I’m asking because after this we had issues with the 3DR connecting to the remote. The remote is saying waiting for solo, and the drone doesn’t connect to it. (tried factory reset and still the same).

That’s why I’m asking if the Upload parameters does anything to the drone?
Or just updates parameters of flytOS. (got message that Parameters were saved in EEPROM).



Well, the upload feature does configure the autopilot’s parameter as well. it gets saved in EEPROM on autopilot.

Unfortunately unlike other autopilots, for Solo SERIAL2_PROTOCOL should be set to 0. I would request it to reset it to 0. Moreover, you do not need to edit any other paramter. Please send the runlog and we will debug from there.


Do you know if doing a factory reset + software upgrade should also reset the parameters at their default values?

I did the above and I believe the SERIAL2_PROTOCOL should be reset to 0 right? How could I check this if drone is not connecting to remote?

I managed to SSH into the drone - IP, and default credentials. Is there a command I could run to check the parameters? There are also some python scripts in /usr/bin , maybe running one will output the parameter values?

Thanks. (didn’t get to re-try takeoff today).


Hi @aluca,

I am sorry, but I have not done a deep dive into Solo before, or atleast I do not remember how to reset it to factory settings.
I would rather request you to ask this question in a Solo/APM forum.


Hi, I did manage to reset the parameters, got some help on this forum, all the details are here if anyone is interested:

Now back to flytPi + 3DR solo integration - I will try takeoff again tomorrow and outside. If anything fails I will send the logs.

I do have another question - I know the drone should be in GUIDED mode (read about this somewhere).

Do I need to change some settings for this, or does flytOS set that MODE via mavlink?

I see these settings in QGroundControl, and I’m asking to know what if anything I need to change. If I need to assign remote buttons to changing flight modes and things like that.

Thank you for the help.



Usually this is the flow ->

  1. User configures his RC to have GUIDED/OFFBOARD mode.
  2. When user wants to allow FlytOS to take control of drone, he changes RC mode switch to GUIDED/OFFBOARD position and makes sure drone has indeed switched mode.
  3. If user wants to revoke FlytOS access, he simply shifts RC mode switch to anything other than GUIDED/OFFBOARD.

In case, your RC does not have GUIDED/OFFBOARD switch (I guess in case of Solo), or you DO NOT want to separately configure one switch as the same, then follow this course:

  1. To allow FlytOS access of your drone, Call Access Request API which internally sends drone to GUIDED/OFFBOARD mode.
  2. To revoke FlytOS access, simply shift RC mode switch to anything other than GUIDED/OFFBOARD.



When trying takeoff - remote saus GPS locked, 8 satelites available, flytOS doesn’t say GPS locked. (but show the same number of sattelites). Attached are flytOS logs also - startup and runlogs. From logs:

DEBUG in flask_views [/flyt/flytos/flytcore/lib/python2.7/dist-packages/rostful/]:
calling service /flytos/navigation/access_request with msg : {‘enable_access’: True}

e[0m[ INFO] [1523521332.920953548]: Nav: API access request command receivede[0m
e[0m[ INFO] [1523521332.921253131]: Nav: SetMode command received: API MODEe[0m
e[31m[FATAL] [1523521332.921406984]: Nav: API access not granted by vehicle. Try again.e[0m

flyt_runlogs (2).log (160.5 KB)
flyt_startup (1).log (4.9 KB)

I tried enable access request, I get this message:

"_format": “ros”,
“message”: “[FATAL] API access not granted by vehicle. Try again.”,
“success”: false

(postman screenshot below)


I switched to guided using qGroundControl, but takeoff doesn’t work via flytConsole, says it’s waiting for GPS lock. In QGroundControl it says 3D lock, 8 satelites. See below screenshot:

Also QGroundControl said there is some pre-arm check - the PreArm Need 3D fix - I assume this is also related to GPS position right?

If I disable all safety checks from QGroundControl, I am able to issue takeoff command (from QGroundControl). (luckly I have the propelers off, I don’t want to fly without GPS fully locked).

Do you think this is still a GPS signal issue?


For GPS lock we tried again with a clear sky view. QGroundControl had a lock - and was able to takeoff with the pre-arm check being satisfied - and enabled. Also I will provide latest runlogs since we were able to test a takeoff (without propelers), and while the drone was ‘flying’ flytConsole showed GPS as locked. After land, GPS no lock was again displayed.

Latest logs attached. There is this message in the logs, not sure if helpful:
flyt_runlogs (4).log (220.9 KB)

Could not process inbound connection: [/flytos/rostful] is not a publisher of [/flytos/mavros/payload_adc]. Topics are [[’/flytos/mavros/global_position/global’, ‘sensor_msgs/NavSatFix’], [’/flytos/mavros/mission/waypoint_achieved’, ‘std_msgs/Int8’], [’/flytos/mavros/rc/in’, ‘mavros_msgs/RCIn’], [’/flytos/mavros/imu/data_euler’, ‘geometry_msgs/TwistStamped’], [’/rosout’, ‘rosgraph_msgs/Log’], [’/flytos/mavros/state’, ‘mavros_msgs/State’], [’/flytos/navigation_server_pos/result’, ‘navigation_util/NavigationPosActionResult’], [’/flytos/mavros/home_position’, ‘mavros_msgs/HomePosition’], [’/flytos/mavros/extended_state’, ‘mavros_msgs/ExtendedState’], [’/flytos/flyt/state’, ‘mavros_msgs/State’], [’/flytos/mavros/radio_status’, ‘mavros_msgs/RadioStatus’], [’/flytos/mavros/local_position/local’, ‘geometry_msgs/TwistStamped’], [’/flytos/mavros/battery’, ‘sensor_msgs/BatteryState’], [’/flytos/mavros/vfr_hud’, ‘mavros_msgs/VFR_HUD’], [’/flytos/mavros/global_position/raw/fix’, ‘sensor_msgs/NavSatFix’], [’/flytos/mavros/imu/data’, ‘sensor_msgs/Imu’]]{‘message_definition’: "std_msgs/Header header\nfloat32[2] adc_voltage\nuint8 adc_updated\n\n

GPS lock below


Hi @aluca,

FCU: PreArm: Need 3D Fix
The above error suggests that Solo does not have a GPS lock. The ‘3D Lock’ of QGC seems misleading.

[I think]:
Solo RC should give you a better information if the vehicle has attained GPS lock or not. Moreover, with GPS lock Solo LEDs should also change their colors.

FlytOS does not detect a valid GPS lock, unless it is receiving both Local Position (NED) and Global Position data from autopilot. In QGC, open Mavlink Inspector and verify if you are indeed receiving both the data.

There might be the case (as SOLO has older APM F/W), it might not be sending Local Position Data unless it is ARMED. So, in your next trial follow this:

  • Make sure you are NOT getting this error:

FCU: PreArm: Need 3D Fix

  • If FlytConsole still suggests, NO GPS Lock, try arming (NOT takeoff, just arm) the drone and check FlytConsole’s status.


Also, the Runlog that you had shared, also suggests that the link with Solo is not at all healthy and keeps breaking quite often.

Look out for this error in Runlog, and the number of times it gets called.
heartbeat timeout called.. check serial connection to autopilot.. restarting mavros

Can you connect QGC to Solo directly, and make sure its connectivity stays good for a significant duration of time.



We tested some more today - and you are right, when the drone is armed - propellers spinning, the flytOS is instantly showing GPS Lock also, and we can takeoff / land using flytOS.

Is this something that can be fixed / worked around (enable_access not working, GPS lock not showing until drone is already armed), or this is all related to the old ArduCopter version on Solo drone? It has ArduCopter 1.3.1 running on it’s pixhawk flight controller. I know this is old from like 2016.

We can work around these, by arming via QGC, just asking if this is how it will remain.

Also - what is a (budget friendly) drone that works with flytOS out of the box? What do you use for testing?

Regarding the link quality, I will check that also.



GPS Lock issue is indeed related to old f/w of APM. It is solvable problem if we work on it.

But enable_access not working correctly is related to poor link connectivity with Solo.

Well we build drones from scratch for testing PX4/APM based drones and otherwise use DJI Matrice / Mavic for DJI based drones.


Regarding RaspberryPi wireless connection - is there an external antenna we could add to improve drone connection?

Also related to DJI Mavic - is that one also connecting wirelessly to the flytPi?



There is no provision for an external antenna. Instead, you have to attach an external wifi module, similar to this.

We currently do not have a product which links DJI Mavic and RPi. FlytOS running on RPi or any other CC can connect to DJI Matrice / A3 / N3 and other DJI onboard SDK supported vehicles.


Can you please also help by reading this runlog, do you think this failure to multiple times upload the waypoints to drone is because of poor connection?

Poor connection between the remote and drone maybe? Because we bought a adapter for the raspberry pi, installed all the drivers, and we still have the issue with the waypoint failure.

Log attached - thanks.

flyt_runlogs_2018-05-11_13-21.log (473.3 KB)