Make sure your rc9_function is not set to zero.
These are my SERVO9 settings, If I alter SERVO9_MAX it resets servo movement OK.
If I alter RC9_max, it does nothing, so SERVO9 is the active settings. Still the REVERSED does nothing. The servo is running the right way in V3.4.5, and reversed in 3.5.rc1
You connect to the USB port. There’s a MAVLink connection going on there so it’s not the easiest to catch these debug messages, but you have two ways (both using Mission Planner, probably other GCS have their own ways):
- active Console in the MP options. These shows these debug messages but also MP debug
- connect via telnet to port 2300: MP outputs everything coming from your autopilot that isn’t MAVLink messages in this telnet port
But after all this I finally figured out what you are doing. In beginning I thought you were actually testing the output and weren’t seeing the servo move in the higher channels. I realized now that you are just looking at the Status output - that’s only going to work if you are using MAVLink2 since the message for MAVLink1 only has information for 8 output channels. I couldn’t actually get it to work with MP but I confirmed with MAVProxy that the values are correct even for channels above 8 when using MAVLink2.
@OAPpilot Please, keep on topic.
Ooookkk, so I think I’m getting this, mission planner can neither command nor status the upper servos…this is why I can’t get the pwms to come out or see the results on status. I totally missed that, but I remember the servo groups when looking at mavlink. Unfortunately I’m on a work trip and won’t be able to check this until probably next week. Thank you guys for all the help
It can command since the used command doesn’t have the same MAVLink1 limitation. But you won’t see it in the status unless you use MAVLink2 - I’m not sure if I couldn’t get MAVLink2 working with MP or if there’s a bug, but I was also not testing with latest version.
I believe that there is still a problem then, no pwm signal comes out, im checking it on an oscilliscope.
Ok, that’s different. So you are saying using the Servo tab in MP you have output in 1-8 but not in 9-14? I don’t have hardware with me to test, but it would be good to try it using passthrough.
I have to apologize to you guy’s I went back through all versions with the scope and verified that indeed the channels do work on all versions when commanded, but the status back doesn’t work for 9-14. I must have mixed up the tests I did with and without the O-scope.
Thank you all for the input, there appear to be no issues, just user error.
I hope you will answer this even though its not a new topic, I found further issue, when there is RC or a joystick in the loop the PWM output by DO_SET_SERVO is undone, reset to NO output, I am verified this by turning on the joystic in MP and commenting out the send of RC_CHANNELS_OVERRIDE
I can make both things work together, just by commenting out SRV_Channels::output_ch_all(); on line 127 of radio.cpp, but that doesn’t seem correct. It might work for me as I have no RC passthrough, but it isn’t the real fix, I think that the problem is that since the Servo function is set to nothing, the DO_SET_SERVO cmd works, but when it comes time to RC passthough, it then get reset.
I’m moving further down the code to try and find a completely appropriate solution.
OK, I think I see the issue here, its looks like:
libraries/SRV_Channel/SRV_Channel_aux line 56:, the PWM that comes from a do_set_servo is not in the SRV_Channel Class.
I think there are a couple things possible, like if the function == k_none, then perform hal.rcout->read(ch_num) in order to get the PWM value.
I’ve done a test with AC3.5-rc1 and master using the Mission Planner’s Flight Data’s Servo tab with a quad and octaquad and it seems to be functioning properly. I actually missed that @jfint had tested and confirmed it was all working… but in any case, it seems fine.
I don’t quite understand the question regarding the do-set-servo working in conjunction with the pass-through…
I’m with Randy here, I don’t quite understand what you are doing. You say you are using a joystick but commented the send of RC_CHANNELS_OVERRIDE in MP, which would mean you aren’t using a joystick…
It looks like RC_CHANNELS_OVERRIDE is the mavlink message used by the joystick, The bottom line is that when a new set of RC controls comes into the autopilot, a servo command that was created by DO_SET_SERVO is cleared. This is why I thought it was broken in my previous testing. I have it working now for me with the code change in SRV_Channel_aux.cpp, I’m just trying to decide if that fix is for anyone else.
To be honest I don’t like the fix, what should really happen I think is that AP_ServoRelayEvents should set the SRV_channel output_pwm value, instead of just writing directly to the HAL.
When I tested this I was seeing it staying at the set servo value in the MAVLink message (which should get the actual PWM value being output). But I can see that the code you are talking could override it. I’ll need to talk to @tridge about it.
So what I ended up doing was creating a new function in SRV_Channel_aux and call it from the handler in the servo events file to set the pwm value inside the appropriate channel object.
This touched more files, but seemed way more appropriate than what I described above, as it might muck with something else.
I do have some mild ambitions to get involved in the developer group, so let me know if this is something I should try and push. I can work up a diff of some sort for you also if you like.
This is now fixed in 3.5-rc3. @jfint let us how your testing goes with it.
Will do, those toys are at me desk t work, so I’ll let you know this week hopefully!
@OXINARF Actually, it has the opposite problem now, it only works when there is an RC transmitter present, and doesn’t work without one. I did find the code change that was supposed to fix this, and I’ll go over it, but I still would not call this working completely. Is there a bug entry where I should put this test result?