Hello, I've got a problem with APM and Raptor 50 heli
I trying to set up APM on Raptor 50 with Glow engine. I connect my JR RC control to APM next variant:
rx in out
1 trotle(pitch) ----> 3 3
2 ailer ----> 1 1
3 elevator ----> 2 2
4 rudder ----> 4 4
my transmitter sets up in "airoplane mode"
servo1 90 (aileron??)
servo2 0 (elevator??)
servo3 180 (pitch??)
ailerons works normal, but elevator and pitch mix some strange.
please help me....
p.s. Sorry for bad English
Oh... the program does not support that type of swashplate control. I think it could be done, but you'll need to modify the code. It is designed for CCPM swashplates.
Precisely. You'll have to modify heli.pde to eliminate the mixing that the ArduPilot does.
I can't help with the specifics, but you'll have to change the pitch and roll factors (or maybe even eliminate them from the code completely because your swashplate is completely decoupled), and you'll have to decouple collective, pitch and roll back to discrete channels again.
I'm planning on going through this process when I transition from my TREX 450 Pro V2 to my Lab's Raptor 90. It's actually likely to be much simpler code, since everything will be decoupled, but I'm certainly not looking forward to the process. I'm hoping whoever developed the original code will hook us up with an option to switch back and forth. If not, It'll take me at least a few days to get the math and code figured out, and I'm an engineer. XD
Actually, I think it will be very easy to do. I'd do it myself if I had the time and a non-CCPM copter to play with. All the numbers you need already exist. You just have to unmix them. Roll, Pitch, and Collective all exist as discrete numbers in the code with sensible names. Only afterwards are they rolled through the CCPM conversion process. You just need to change it so that they don't get mixed, but go out to the servos directly.
With a 90° normal helicopter setup, one servo per control, THR, AIL, ELV, & PITch (cyclic) it will save a lot of code and RAM space!
This will surely be an HELI option soon, I can help with the code changes. the extra space is needed for other options. I don't know how fast this can be done.
It's only a few lines of code doing the actual swash plate mixing, so I dont see much help with space there (although it would likely make the code significantly faster with the Arduino freed from doing those computations in the fast loop).
A better fix for memory issues would be to use a compiler that goes through preprocessor defines and cleans up the code that isn't applicable to the configuration being set up. Visual Studio took my roms down in size about thirty percent using that feature along with the Arduino plugin. They're about 80k or so with VS doing the optimizing.
Of course, I got VS ultimate for free through my IEEE membership, so that may not be super helpful if you don't have a multi-thousand dollar programming environment to work with -_-'
Chris, I should have written "You just have to NOT mix it" Not "unmix" it. The mixing is done after all the PI stuff. So the numbers come through all the control stuff in discrete pitch/roll/collective, then get mixed and out to the servos.
It also won't be too bad trying to make this easy for users. Initially just a #define. Once you have it working, Michael Oborne can probably do something in APM pretty easy.
The real hard part will be implementing the code in a way that allows the user to choose their swashplate configuration the same way your transmitter typically would. Not only would you have to set up the code to allow the user to choose their swashplate configuration, but you'd also have to implement something in the GCS to set it up with a GUI, especially if you would like for the full range of swash plate configurations to be accomodated. That's a ton of work.
It's more than possible to hack the code up and get what you want out of it. It's hard to turn it into a feature that's accessible to the end user.
Ok, taking a look at this now. All in the latest Heli.pde:
Lines 32-39. Those are unecessary in H1 code, but I see no harm leaving them in.
Lines 54-57. The set_range on 1, 2 and 3 might need to be changed to set_angle like the tail servo....
Lines 73-80. Again, unecessary but harmless.
Lines 140-143. roll_out, pitch_out, coll_out, those will be key to this.
Lines 154-157. What if we just set g.heli_servo_1.servo_out = pitch_out, etc.???
I think that's all there is to it. We just have to make sure that pitch_out is a suitable value to feed into g.heli_servo_1.servo_out. If it's not, rescale it. Done. I think.
roll_out and the other variables may need to be scaled, and they may not. If the CCPM swashplate mixing is done before the outputs for each channel are scaled to the servo min and max values (more likely), then you'll need to use the same scaling algorithms that the current code uses to do that scaling, assuming that those algorithms can be adapted.
You'll also have to consider the setup process for establishing blade angles and such for the decoupled swash. If the servo travel ranges are established based on a three point swash with collective coupled into pitch and roll, as opposed to just the input values from each channel, then we'll have to completely rewrite the setup program to accomodate as well, or you'll never be able to set up good blade pitch angles and such.
Again, not impossible, but it require intimate knowledge of exactly what each function being called is doing to the numbers. The original coders could do it in 30 seconds with 100% confidence in the outcome. It's gonna take us a lot of guessing and testing before we can even get an idea of what everything's doing. I strongly recommend making a feature request instead of diving in head-first, just because there are probably ten or fifteen different things we can do to screw it up really badly, that the original devs already know to avoid.
That said, if you really want to go ahead with it, count me in. I don't have huge time to help in dissecting the code with you, just because my courseload is pretty intense this semester, but I'll be happy to offer the Raptor 90 to help beta test, and give you a second pair of eyes.
Well, diving in head-first, that's what this open source thing is all about. We can't all just sit around waiting for the main guys to do everything.
That's how I helped fix the swash plate setup. I dove in, figured out the concept, cocked up the implementation, and then Randy helped finish it up. We can't rely on Randy to do everything.
Honestly, I don't think it will be that hard. I believe that the setup will roll out of the functional implementation.
Ch.3 input is used to create coll_out_scaled in the setup. Coll_out is scaled to fit coll_out_scaled, which then is pumped into the CCPM calculation. We just need to scale coll_out back into the values from Ch.3 setup.
Good deal. Is there any scaling to be done on the pitch and roll values likewise?
Sounds like you know quite a bit about the guts of the code. I've only spent an hour or so looking at this particular issue, so I'll defer to you for the best answers. It's good to know that I won't have to do this solo when I have to have the setup for my Raptor 90. I was NOT looking forward to doing it from scratch myself.