Rc_override mavlink with cube orange

Hello all,
I am useing Dronekit rc_override to ocilate my plane in a sin wave motion for roll pitch and yaw while the plane is in auto mode. Dronekit runs on a RPI connected to the cube orange with a buadrate at 57600. Sometimes the plane will do the sin wave manuvers as expected but others it dose not. I am sending mavlink messages at 25 hz to the pixhawk. So sometimes the pixhawk is not accepting my rc_override messages. Dose anyone have any ideas on how to fix this?

There is also this option, but that isn’t in a release version of ArduPilot yet. I skipped over the companion computer route for doing this as I wanted to have my real servos and SITL servos do the same things.

Hey @TunaLobster I am not sure I follow you on how you skipped over the Companion computer. I currently can get the compaionin computer to send a mavlink message RC_OVERRIDE and can move servos both real ones and in SITL sim_vehicle.py

My problem is sometimes my rc_overide command is not excepted by the cube orange. Note the red line in the pictures below. When it a smooth sinwave it maneuver as it should but when its not smooth it did not work

.

Oh I didn’t know dronekit could do SITL! Are your mavlink messages being received consistently? Also what mode are you doing this in?

The nice thing with the Lua scripting and “set_output_pwm_chan_timeout” is that I can command the servo output for a certain amount of time. After that time expires, the servo safely goes back to whatever if was doing before. I was going to do by mavlink messages from the ground station before Lua support was added. The other nice thing is that the RCOUT.C1 curve would be smooth rather than RCIN.C1. Either version could be preferable depending on what you are looking at.

Donekit it self is not the SITL but you can connect to SITL sim_vehicle.py. Use 127.0.0.1:14550 as the connection string to connect to the sim_vehicle.py My mavlink messages are being sent to the pixhawk consistently but I dont now how to tell if the cube is receiving them consistently.(any ideas here) The flight mode is AUTO when I do this.

So is set_output_pwm_chan_timeout something you wrote? I am not fimilar with Lua scripting. Hveing the RCOUT.C1 smooth would be nice for what I am doing. I will look into this.

Thanks

I wrote set_output_pwm_chan_timeout with help from tridge. May I ask why you are doing a sin wave in auto mode? You would be looking at tracking of the commanded theta (RCIN) to the output theta of the aircraft. In that case, RCOUT.C1 would be the output from the PID. If you want the control surface to follow a sign wave set_output_pwm_chan_timeout would be the way to go. Keep in mind that the throttle will be changing based on the output from TECS in auto throttle modes. Using a different mode or taking control of the throttle would be ways to work with that.

There is a ton of information about Lua scripting here.
https://ardupilot.org/plane/docs/common-lua-scripts.html

Okay thanks this looks interesting. I understand I will just be looking commanded theta vs. output theta in auto modes. This is okay. I am just trying to oscillate the plane in a repeatable fashion for now. This Lua scripting looks promising.

Thanks for the help

1 Like

@TunaLobster do you know if Lua scripts still use mavlink messages then?

Thanks

I’m not sure what you mean by use mavlink. It is possible to receive mavlink messages in a Lua script. Michael starts going through receiving a command long message here by doing LIVE coding. I don’t think sending them as been added. I created set_output_pwm_chan_timeout exactly for the case of doing a doublet. I’ve gotten a little carried away with adding little bits and pieces to it. I just tested that it ran today and pushed to share it here. Still need to test in SITL and on the ground.

I mean how dose Lua script communicate with the pixhawk? Ie mavlink messages or something else?

I have been doing some debugging and with plane sitting on the ground sending rc overide looks good. I run into the problem when flying though. Sounds like a processor loading issue. I have a feeling the Lua script will have the same problem as it’s at the bottom of the priority list. Have you flown with your Lua script yet?

Thanks

I’ve had it running armed an on the ground for now with the prop off. I haven’t had a chance to get to the airfield. I’m sure I will find some issue when I get it in the air, but I’ve had it running just fine on the ground with a CubeOrange. Lua scripts running on the autopilot interface directly with the C++ methods. So there are no issues with packet loss or packet processing queues as with a ground station script send commands over mavlink.

got ya thanks , all my scripts are on the RPI in the plane with hard wire mavlink communication to the cube orange at 921600 buad.

I will give this Lua script a shot. It looks neat. Have you seen this before? I am just trying to run hello world


image

You need to reboot with the script in the directory to have it there at start up. If that is the script I think it is, it will send the message very soon after boot. Try the looping “Hello world!” example script. It is a better indicator for if you have scripting up and running.