Noob need help Re: Storm32 w/ APM 2.6

Hello all, I am sorry for asking if this is a stupid question but I can not find documentation for this anywhere and i have been looking for 3 days. I can find specifics for a Storm32 BGC to a Pixhawk, but I dont think that will apply to my config. Can anyone help me to do this? I just basically want to have control of the pitch via channel 6 “vr knob” on my Futaba radio. It is a T7C. Also, when I see the version numbers up to 3.5 or so, i believe that is reffering to the firmware version is it not? So the module I bought is the 3DR APM 2.6, however, wouldnt the firmware version be the same considering it is updated? I think I have just been trying to learn too much in the last week and I am burned out now. My brain hurts but its worth it because I have had a couple successful test flights all be it only at about 10 feet. (: starting slow… THank you!

Brady, I’m about where you are as far as experience in the drone world is concerned. I, too, have a copter that uses the APM 2.6 Flight Controller. I am having concerns about which firmware version I should be using - A C 2.8 or A C 3.5 (the two versions which Mission Planner shows are still available for download). I am currently running A C 2.8 (original release) but have not solved all the control problems I am having with this new copter, so I haven’t had any flights with it yet (that and there’s been up to two feet of snow on the ground for the past month…)

Just because I am curious, why do you want to control the pitch via the channel 6 “VR” knob on your transmitter? Do you mean you want to trim the pitch angle with that knob?

Im sorry I must have explained something wrong. What I was trying to control was the pitch of the Storm32 Gimbal for the camera. I have just bypassed the APM completely though as I dont see much need currently for having the APM for the extra functionality it may offer as I have not learned enough yet. My first few flights went fine as I had mentioned but now I after I mounted my compass in the “correct” location, I tried to re calibrate it and it fails every time. I was instructed to update the firmware and run the wizard again but nets the same result. Now when I try to fly it will just tip over every time… frustrating!! )=

Hope the weather clears up for you and you get some fly time. I am still not sure about all the version numbers hehe I know that when I open the terminal it shows ardupilot version 3.2.1b…

Okay, now I’m getting the picture about the pitch control - you were talking about pitch control of the gimbal and my mind was thinking about pitch control of the whole copter. My bad!

All of the versions of APM 2.9 thru 3.5 support control of the camera gimbal via a dedicated channel on your radio transmitter. The documentation for your transmitter should tell you how to configure the transmitter and your ground control software (like Mission Planner) will allow you to use that dedicated channel to control pitch, roll, and yaw on the gimbal through the Flight Controller. Doing so should not affect how the Flight Controller affects the actual flying of the copter.

As for the “undesired” tipping over of the copter - this is a common problem with new builds, but the solution is not always so easy to find. You have to make sure you have checked EVERYTHING to insure the build was done properly, that electrical connections are all tight, motors are aligned and properly secured, and your weight-and-balance are good. Insure that you have everthing properly calibrated (radio, compass, accelerometers, etc., and especially your ESCs (if you have tried the “all-at-once” ESC calibration method and things still don’t work right, try the “one-motor-at-a-time” method. Both are covered in some of the YouTube videos, as well as in the APM firmware documentation that is on-line.)

As far as the APM/Flight Controller firmware versions are concerned, the version of the firmware does not always coincide one-to-one with the version of the hardware you are using (i.e., you may have an APM 2.8 Flight Controller installed on the copter, but that Flight Controller may be running firmware version A C 3.5.1. The version numbers are independent of each other.) Having said that, it is always a good idea to read the documentation that accompanies any new firmware version to insure that the firmware is intended for use with the version of the APM that you are using.

Hope some of this helps…

Definitely helps thank you, I have also since found out that the last firmware upload to any 2.x hardware is Copter 3.2.1… so even though mission planner says there is higher firmware versions available and let’s you select update firmware, in the background it is recognizing your board version and installing the firmware respectively.

I have solved the tipping issue, when reassembling after adding gimbal, I mixed up motor 2 and 4. Glad it was something free to fix… however now I am still having a problem with thrust. Full power and not taking off… :disappointed: just gotta keep trying.

Glad to hear you got things up and running so far as the tip-over situation
is concerned… and, as you said, it was for free! Can’t beat that, can
you?

Last night I ran into a head-scratcher problem of my own. My APM 2.8 was
having problems arming, both through Mission Planner and via the radio
transmitter. It would arm okay, but the motors would automatically spin up
to almost take-off speed. The MOT_SPIN_ARM parameter was factory-set at
70, and I read on another thread that setting it to 0 (zero) would allow
arming without any automatic motor spin afterwards. I set it to 0, wrote
the new setting to EEPROM, went into Flight Data on Mission Planner, then
back to Config. I checked to see if the new paramet had been set for
MOT_SPIN_ARM had been updated - and found it had not. I tried a couple
more times to change it, but it never updated the the desired value of 0.

When I went to arm the copter again, first through Mission Planner and then
via the radio remote, the APM light would signal that arming had taken
place, but then it would quickly go back to non-arm. Not only that, the
motors would give just a little “stutter” when the light would show it
being armed, but then they wouldn’t do anything else at all. Moving the
throttle up and down does nothing (it previously would rev the motors up to
full throttle). I re-set the MOT_SPIN_ARM parameter back to 70 - no dice.
I re-loaded the firmware that I had been originally running - same results.

The next thing I am going to try is to reset the EEPROM, reload F C 3.2.1
and give it a go. If that doesn’t fix it I don’t know what to try.

Hey whats up man, been a few days but just seen this message and thought id share some of my experiences in this in case you have any issues still. When you select write params, it saves the params but doesnt actually write them to the board. So unless you have the option selected to refresh the params every time you disconnect, you wont ever save your modified params to the board because next time you plug it in, it will refresh and your back to where you started. So to make sure you are saving what you want, everytime you hit write params, just hit refresh params right after if it is something you are wanting to change right then. Also, a better way to fix the motor spin AFAIK, or at least the documented way, is to adjust the throttle dead zone instead. In the docs it shows to use the test motor function and adjust the throttle all the way down to 1%, try spinning the motors, they shouldnt spin at 1%, then keep bumping it up +1% at a time until they start spinning, this will give you your accurate dead zone. Then once you are getting a steady hover without problem, download your flash logs, and check your throttle out data. Whatever your needing to set your throttle to to achieve a steady hover is what you should set to your mid throttle parameter. After doing those things and also the auto-trim, I am getting perfect steady hovers with all of my gimbal equip and camera and now a bunch of new LED’s hooked up to the corresponding pins so as to give the indicators for GPS, ARM status, and motor status. Only thing I am lacking still is the way to be able to know when my battery is going to die, I cant afford the telemetry kit yet but I did find a piezo buzzer on an old board that I am going to try to remove and then wire to the speaker pin. I think that will give me a low battery warning? Anyways, hope all si going good for you and your having fun with it. We should keep in touch so we can keep sharing info since we on same track.

Thanks for your reply. And, yes, I just might have to replace the whole
GPS/Compass module, but I have a couple more things I want to check before
I shell out more money on this copter. I’m already into it for about $600,
and I still have yet to have more than about 10 minutes of flying it…
total!

I’ve been going back over what you sent yesterday and have a couple of
questions.

When I am on the Config/Tuning - *Full Parameter List *page, I see load
from file, save to file, write params, refresh params, and compare
params
options
listed in the upper right-hand corner of the screen. I understand what *load
from file *and save to file do - respectively, they read a file that you
select which is stored on your computer’s hard drive, or they save to a
file on the hard drive the parameters you have showing on the list on your
screen. I get that.

What I don’t understand is when I select write params, where are the
params being written to? If they don’t get sent to the flight computer
until I hit *refresh params, *they must be somewhere - maybe in volatile
memory in the computer itself?

And, when I hit refresh params, the flight computer is getting parameters
from… where? Wherever they went when I hit write params? From the
location in the computer where the data on the screen is being pulled from?

So many questions!!! (But, the people want to know!)

Different subject: I have on my copter a monitor that connects to the
battery data wires. This monitor has a digital display which sequentially
displays *number of cells in the battery, *then, in order, the voltage
value
of each of those cells, and the total voltage of the battery. It
has a feature which allows you to set a low-voltage limit which, when the
battery goes below that limit, sets off a loud, audible alarm. As I recall
this module cost about $5 or $6 on Amazon. (I would give you the
identifying info on it, but the unit is mounted on the copter in such a way
that I can’t see that data!)

This module does not interface with telemetry units - it is a stand-alone
unit only. But it does do the job if the copter is close enough for the
pilot to hear it. I have not been able to test it out for distance it can
be heard - the only time I’ve been able to fly this copter was a single,
tethered flight in which a prop tangled with the tether line, bringing the
copter down very rapidly. MAJOR DAMAGE! (broken frame, damaged flight
computer, broken props, etc.)

Yes you have got it right as far as I am understanding. Basically, an easy way to think about it is, the params you have showing on your Mission Planner (On your computer(GCS) ) is your primary parameters. The parameters on your APM module, are your secondary. So, when you hit refresh, it is really the same thing as uploading to the APM module. When you write, it is writing it to the file that is saved on your computer for your primary parameters. Same thing as when you hit save to file, but it is saving it to a file somewhere that you will never really see in typical use. (probably somewhere in app data folder if on windows or similar.) If you haven’t written first, before hitting refresh I am not sure about. I just know that I always do it in that order to make sure it uploads to the module. I will test that though and get back to you. I hope I have not made this more confusing for you instead of helping. If I have just let me know and I promise I will think of a better way to explain it when it is not so late. lol

AFA the battery monitor, I know that the power module that comes with the APM is capable of reading the power and will in turn initiate a fail-safe at designated voltage, the problem I have with that is that in the set up it asks for the battery size in volts and mah and cells and all that, well I dont have one size of battery and in fact dont have any two batteries the same… LOL Kind of a poor mans battery collection. I understand the thinking behind this is that of a pilot like you see on the youTube videos flying a DJI Inspire or Phantom and having 6 proprietary batteries that they bought all at the same time. haha unfortunately that is not the case here so I am just needing to research more what those variables will have an impact on and if I can set a mid range and have that work for all of them or if I need to redo the set up every time I switch battery. O well, just one more thing.

Honestly, I am hoping to upgrade to a whole new set up for aerial photography and possibly one other idea I have been thinking about lately to go along with cyber security, another hobby of mine. An X8 with RasbPi3 and Navio2, but by the time I save up for the FC it will probably be something else that is better and these are obsolete.