Possible with more commands in mission (more than Set Waypoints)?


In my application we need to set some pixhawk AUXOUT:s during the mission (lights, sound etc). Before I started to use flytbase api we used the mavlink command DO_SET_RELAY to set relays and then configured RELAY_PINs in pixhawk to set the pixhawk auxout1 for instance.

Is there any API available to do this via flytos and especially when using the cloud beta?
I would like to be able to add the commands set relay and change speed, to the mission at startup, but i also need to be able to send the commands separately.

Thank you!

best regards,



FlytOS internally uses mavros to communicate with Pixhawk. You can use this mavros API (command API) to send your mavlink command.


Thank you for your answer. I do not however fully understand your suggestion. Do you mean that I should add scripts on the FlytPi, which communicates using mavros API? And I start the scripts from FlytBase “Execute script” api?

Or is there a Flytbase API that can be used to access the mavros API? (it would be great to have a flytbase API that can add generic mavros commands, so when they are received by FlytOs they are genererated and send to pixhawk.

For our application we need the following mission:Takeoff, WP1,WP2…,WPX. set_relay 1+2, WPX+1, land, clear relay 1.
We want to send this mission completely at startup, incase telemetry is lost during flight we still want this sequance to be performed (safety issue). But the normal procedure is that we have telemetry link, and need to be able to send stand alone commands for set_relay,land for instance.

Best regards,



Unfortunately, the cpp/python API does not include mavros APIs. Hence, you have to write a ros node, using the mavros APIs. You also have to add the ros node to flytos launch(/flyt/flytos/flytcore/share/core_api/launch/core_api_autopilot.launch) file, for it to start along with flytos.

I understand your request and it is in our pipeline, but we never got any such request from our users, and thats why it never got implemented.

So how do you plan to send the waypoints? (Everything except set_relay). Are you going to write an onboard script(cpp/python) or via flytconsole/QGC/MissionPlanner etc. ?


Thanks for your explanations and suggestions.

We send it from our own ground control software, which we connect to the flytbase cloud, and use those APIs.
Our ground control station is a bit different than others, we only choose a destination point, and our software generates a suitable route to the destination depending on obstacles, topogrophy, flight corridores etc.

So we cannot predefine the mission WP onboard, they are generated in our software depending where the AED should be delivered for the patient.
Today i have the Set Waypoint implemented so I can send the positions via the cloud to the drone before executing.
Further more than the set_relay, we also need to rotate the drone towards north before landing, and than land, all this to be part of the mission. Now I have to send separate commands for those after the mission.

A special generic API in flytOS would be great that is possible to send any mavros/mavlink command, do you think it is possible you can do this, and if so when do you think it could be available?

Also a more advanced “Set mission” API, that would allow more different command sequances is also something we would have great use of. If you think you will do it, do you have any estimate when it could be available?

Finally a set_relay API would be preferred for us, that is something we would use for all our applications, this is probably the simplest API to add compared to the previous two.

I will study the ros node concept here and see if I understand how I would implement that in the meantime, I do not know that yet how that solution will be.

We really like the use of the flytos API you have implemented so far, and we think to keep the system implementation as simple=safe and common as possible is always good, so I would like to use only your API, and not add complexity by separate nodes with logic onboard if I don’t really have to.

best regards,



[Assumption 1] Correct me if I am wrong. So basically you DO NOT want any onboard script (cpp/python/ros) to control the drone, and instead want your special APIs available via cloud API. Right?

Why are you sending separate commands for them? You can create a land waypoint and add it to list of waypoints sent to waypoint_set API.

If my above [Assumption 1] is correct, and you want the API in cloud, then i think it is already available. (Let me confirm with my team). The only issue being the API is not documented yet.

What according to you would “set mission” have as compared to “set waypoint” which would make it more advanced.

Moreover, what autopilot h/w and s/w stack are you using?


Assumption 1 is correct, we want to have the full behavior control via the API cloud if possible.

Separate commands issue: You are absolutely right, my mistake I did not seeu the parameter value option for land command. Also I will test the yaw direction parameter also available. Thank you!

Special generic API: Perfect if you can check availability from your team, looking forward to hear about status.

Set mission API: The only thing I miss now, as you pointed out the land command exists, is the ability to control relay at defined position during the mission. I need to turn on Siren and lights when approaching land destination, and turn of sound when landed. Basically that is only what I miss in the set waypoint command. Maybe it can be a command enum that specifies which relay to set or reset or some additional param that defines relay and on/off.

We use pixhawk 2 (cube) with apm, and flytpi as companion computer.

Finally, I really appreciate your fast and helpful responses, thank you!

Best regards Sebastian



Unfortunately it is not available as of now, but could be made available. What is your timeline?

You had earlier pointed out that you were doing this using mavlink. Can you please explain your entire codeflow, of how you were doing this using mavlink commands?



For our previous ground control software not using flytbase APi, written in C#, I did send the relay command in two different ways. One way was to add it as part of the mission, se further down in text, it might actually work with flytbase API after I did some testing today! This is needed for our normal way of executing missions, when all info sent to drone at startup.

Second way is to send it as a standalone message from the operator, this is especially needed for us for demo purposes, to be able to switch on/off lights and siren on demand when we are showing the system on presentations etc.

The stand alone mavlink message was sent like this:

MAVLink.mavlink_command_long_t setRelay = new MAVLink.mavlink_command_long_t()
param1 = (Single)relayId,
param2 = (Single)on,
param3 = (Single)0,
param4 = (Single)0,
param5 = (Single)0,
param6 = (Single)0,
param7 = (Single)0,
command = (UInt16)MAVLink.MAV_CMD.DO_SET_RELAY,
target_system = (byte)1,
target_component = (byte)0,
confirmation = (byte)0,
var d2 = tmp.GenerateMAVLinkPacket10(MAVLink.MAVLINK_MSG_ID.COMMAND_LONG, setRelay);
int ka2 = mUdpClient.Send(d2, d2.Length, mEndPoint);

The command MAVLink.MAV_CMD.DO_SET_RELAY has the value 181.

When I look at the commands in flytbase API for Set Waypoints, I see that the enums in your doc all match , as expected, the commands in mavlink MAV_CMD (http://mavlink.org/messages/common). I tested now to add the value 181 as the command in the flytbase API fo Set Waypoints, and it was accepted. I can not fully verify the functionality yet, but when i read back the mission stored in pixhawk in APM missionplanner, I can see that that command looks good. All correct settings for param1 and param2 are made, I will try to verify the functionality fully tomorrow.

It would like to be able to send the relay_on/off command using the mavlink generic long_command (which is present in the rosapi as you showed me), as soon as possible. Can you fix it within 2-3 weeks that would be very appreciated. If that is not possible within that timeframe, just let us now and we have to adapt to it.

best regards,



As I understand, this is an on-demand type of API. So you have to call this API in realtime, to switch on/off lights. This won’t be able to help you in the scenario that you mentioned before.

where you might want the lights to switch on/off automatically when it reaches WPX. Do I make sense?

Moreover, did you ever try to send waypoints via mavlink, similar to the way you were sending the set_relay command?

Were you able to test it out? I think you have hit the bull’s eye for the case wherein you would want your lights to switch on/off automatically depending upon state of your mission.

I guess you would need this to have a separate manual control over your lights. I am working on it and should be available in few hours.



I have added the mavros command API in our cloud server. Details are as follows:

Name: mavros/cmd/command

“command”: int,
“param1”: float,
“param2”: float,
“param3”: float,
“param4”: float,
“param5”: float,
“param6”: float,
“param7”: float

I hope it helps.


Thank you! Perfect, It works great, now we can demo the drone in a good way to show the communication.

I have not been time to test the 181 command today withing a mission yet, I will let you know as soon as it is done.



Hi @srv!

I tested indoors to to a mission to enable the relay output using MAV_CMD 181 in the flytbase “Set waypoints” APIl and it is working!.
Here is a short film of our drone with the blue lights being switch on via the cloud from our own ground control software :slight_smile: :

I hope to be able to fly outdoors during next week, than I will also test to send other commands like CONDITION_YAW MAV_CMD enum 115) , which i need.
When I test at the bench to generate a mission with this it seems also to work, I have read the mission back with apm mission planner and see it contains correct data.

It is however not working with the Virtual Drone on the cloud for now, I can have the do_relay and do_yaw command in the mission which is accepted, but the actions is not performed (for relays there is no way to see I/O status on the virtual drone, and the yaw is not performed). So I will fully verify the do_yaw using one of our real drones hopefully next week.

Thanks for all help.




Great to hear that the static testing was a success.

Can you please try this again. I had updated the cloud simulator yesterday. Let me check if you can get i/o status data.


I tested but I do not know how to check i/o status in the flytconsole for the virtual drone, can not find any way to see it.

Also do you expect the do_condition_yaw (mav_cmd enum 115) to work?
The Virtual drone does not execute it now, I plan to test it next week on real drone.




Unfortunately I don’t think I/O status is made available by APM. I guess you would have to test it on real drone.

Yes. I had tested ‘the new cmd API’ using condition_yaw itself. Nevertheless, I did test it again and it is working just fine.
Can you check if your parameters match mine:
“command”:115, “param1”:90, “param2”:0, “param3”:-1, “param4”:0, “param5”:0, “param6”:0, “param7”:0

param1 -> [0,360]. make sure it is a positive value and you send the command in degrees

Also, when you run the command, do you get a positive acknowledgement from server? Please share your code, if it still does not work.


Ok i will test io drone.

I tested to add the do_condition_yaw to a mission (Set waypoints) and also using “the new cmd API” which I succesfully use for the relay command. It does not work yet for me, maybe I made some simple mistake…:
Here is the code, i tested with your parameters:
var msgdata={};
msgdata[“command”]=115; //DO_YAW_CONDITION

type: “PUT”,
headers: { ‘Authorization’: 'Token ’ + cloudToken, ‘VehicleID’: vehicleId },
dataType: “json”,
data: JSON.stringify(msgdata),
url: cloudRestPath+"/ros/"+namespace+"/mavros/cmd/command",
success: function(data){

I get the response (console.log): data.sucess = true and data.message = undefined



I see there is some problem with the Virtual drone nav, it is not the specific yaw command. I tested to restart the virtual drone and suddenly it worked to yaw with separate cmd. Tested to add this into mission (Set waypoints) , and did not work. I landed the mission, and made take off again to test more, suddenly not working with separate command either, and the drone commands from navigation widget also is working weird at this stage, the drone is not moving correct directions.

I will investigate more to see if I can present exact flow to repeat problem, and send to you,



What do you mean by this? I hope you understand that the navigation commands are in NED frame and not in body frame. So, we you press front/North drone will move in north direction irrespective of its front/yaw.

Well, there are ofcourse some complications and requirements which must be satisfied before sending the yaw command, without which drone would not respond. That’s where FlytOS comes in. To be sure that vehicle yaws correctly and reliably, please use position_set API.

Just for the sake of testing -> You can make your yaw as a separate cmd work, by following this approach. Takeoff the drone to any height using the takeoff button on cloud console,
Press any navigation button, make sure the mode at top bar says API|POSCTL,
now send your yaw cmd.

Please share the code.


I get back with info about the yaw command later, for now i have tested the Virtual Drone console and no of my code to generate the problem with the direction. (i only use the console and not even conencted my software to the cloud)

Do the following sequance.
Startup Virtual drone
Start virtuyal drone console
Create a waypont north east of the drone, about 20 meter from the drone.
Save to drone.
Press start mission.
Let mission finish.
Press left, up, right, down in that order, letting the drone stop between,…all controls on navigation work correct.
Press land
Let it land and then press take off
Press left,up,right,down in that order, letting the drone stop between…all controls now behave with wrong direction and length,

I have added an image so you can see the path the drone flies: