Copter: RCMAP doesn't use correct RCn_MIN and RCn_MAX

[rmackay9]

If users use RCMAP to remap the roll, pitch, yaw, throttle, the RCn_MIN and RCn_MAX values do not come from the correct channels.

The work-around is for users to set the RC range for all four to be the same but really we should take the min and max from the correct place.

[SteveKeep]

Hi Guys, wass talking to Tridge last night, and this sounds like what killed a large octo of mine a few months back, was demonstrating RTL to a customer and it climbed a little, yawed at full rate then turned over on its back and plummeted around 300 feet, fortunately no gimbal on board and soft ground. Damage was very minor considering! I did analyse the logs at the time and came to the conclusion that the falisafe was incorectly set, (Spektrum radio on pixhawk) I was under the illusion that RCMap was fully functional. I had been using this copter on a Jeti radio and needed to swap to a spektrum system (had spektrum mode 1 and 2 available,... only had 1 Jeti radio available..) which required using RCMap.
It would be nice if this function was fixed as a fair few of my customers use spektrum gear and do not want to change.
Cheers
Steve

[SteveKeep]

Me again,.. It should also be noted that the work around requires you to centre ALL sticks, ie leave throttle in the centre otherwise the centre position gets all screwy for the other channel... not sure of the implications of the throttle centre position actually being in the centre on other functions?

[evildean]

Hello,
I am also limited to RCMap with my JR X9303 radio and PPM. I have considered taking note of the actual Min/Max numbers so I might manually enter them for each channel in the full parameter list. This would not help much for FailSafe but atleast the channels would have the correct Min and Max value? Anyone else tried it yet? Also, assuming my ppm out is TAER... after I make RCMap edits the APM assumes my elevator, now on CH3, is the throttle. What if I set my receiver to output very low elevator Upon connection loss? Would RTL override the extreme elevator input? How difficult is a proper fix within the code? Can anyone provide a working version for testing?
Dean

[evildean]

If I understand correctly there are some throttle control parameters automatically set while in flight? Something like throttle mid based on hover while in stabilize mode? Are these parameters considered by the RCMap settings?

[evildean]

Manually entering Min, Max, and Trim values worked for me. Essentially I swapped these values one to the other within the full parameter list. RC1 values on RC3. RC2 to RC1. RC3 to RC2. RC4 remains un touched. Performing radio calibration again resets these edits obviously! Radio Calibration does not honor my RCMap values. Calibration leaves the trim value of RC3 set very low as it assumes this the throttle channel. My RCMap values have elevator on CH3 so the trim value set via radio calibration would give full pitch forward all the time. FLIP! A low trim value on any other than the actual throttle channel is scary stuff! A lot of band wagoneers getting involved for this kind of bug!!!

Failsafe does appear to respect my RCMap values. I attempted to invoke radio fs with low pwm inputs on CH3 without success... Thank Goodness! However when applying low pwm input to CH1 I can invoke failsafe. Perfect!

Dean

[rrr6399]

Has this been addressed in 3.3 yet?

[andyp1per]

The big problem here is actually the trim values recorded by mission planner. If I do a standard spektrum remapping of all the channels then it will read throttle trim as pitch trim etc. This would not matter if all the trim values were centred but of course the throttle trim is basically the same as throttle min. On ArduCopter 3.2.1 this causes a hard right roll as soon as you raise the throttle.
I believe the current approach of remapping the radio values is broken. The problem is that there is a disconnect between the external config mapping of RC_* and the internal code hardcoding of throttle -> RC_3 etc. I don't think this can be fixed properly without either (a) not hardcoding the channel mapping in the firmware or (b) not hardcoding the channels in mission planner (i.e. mission planner should refer RC_THROTTLE rather than RC_3 for example). Personally I think (a) is the right solution. The channels are the channels as determined by the TX, the firmware should cope.
I have tried implementing this and it seems to work, but I am hampered by the fact that channel mapping doesn't appear to work in the simulator at all. With my fix I can at least take off, but I'm not sure whether the issues I am seeing are because of an issue with my change or because the simulator itself is assuming a hardcoded mapping of RC3->Throttle etc.

[andyp1per]

My fix works in the simulator. Was able to fly the copter mission. You have to be careful to set inital RC values appropriately before doing anything as they are hardcoded to defaults (e.g. RC3 to 1000, RC1 1500). Will now try on a real vehicle (gulp). I'm guessing this is all unnecessary as Rob has a fix in hand (?), but I had fun getting to grips with the ins and outs of firmware debugging and I understand the code a bit better now.

[R-Lefebvre]

I don't know if I have the fix for this yet. Part of the problem is my fix
totally breaks compatibility with plane. But I see that as being
necessary. Seems to me, doing it any other way actually makes things more
complicated.

Do you have yours in a branch somewhere, I could see what you did?

On 30 March 2015 at 14:42, Andy Piper notifications@github.com wrote:

My fix works in the simulator. Was able to fly the copter mission. You
have to be careful to set inital RC values appropriately before doing
anything as they are hardcoded to defaults (e.g. RC3 to 1000, RC1 1500).
Will now try on a real vehicle (gulp). I'm guessing this is all unnecessary
as Rob has a fix in hand (?), but I had fun getting to grips with the ins
and outs of firmware debugging and I understand the code a bit better now.

—
Reply to this email directly or view it on GitHub
#1661 (comment)
.

[andyp1per]

Here you go:

andyp1per@1279f92

[andyp1per]

Any good? I will try the patch on my Quad at the weekend if it will help (assuming these 100mph winds die down), but will probably skip it if you are going a different direction.

[dominicmarmont]

I am running 3.2.1 on my quad, and was having an issue where the copter was rolling hard on takeoff.
I have a spektrum set-up, so I have an RCMAP setting to change the channel order.

I eventually discovered that the issue was due to RC1_TRIM being applied to the roll channel despite having a RCMAP_ROLL = 3 and RCMAP_THROTTLE = 1

Would this be considered the same issue?

[andyp1per]

Yes, exactly the same issue.

[andyp1per]

What's the status on this? Do you need any help? I've laid off my fix because I thought this was in hand, but Randy seemed to indicated 3.3 was cooked now without RCMAP being fixed :(

[elias5000]

It would be awesome if 3.2.1 could also be fixed and not only new versions. As I understood what I read 3.2.1 is the last firmware that will fit onto my APM2.

[rmackay9]

It'll make it into AC3.3 for sure. There aren't many more changes going into AC3.3 but I guarantee this one will be in it. Rob Lefebvre's going to add it.

[andyp1per]

Super!

[rmackay9]

This is fixed in master and will go out wit AC3.3-rc6.

[npope]

Any chance of getting this fixed in a 3.2.x release so we can use PPM + RCMAP in an APM without the workaround?

[andyp1per]

It's a huge change - no chance of it going in 3.2.x