Newb Questions U Were Afraid to Ask

Okay . . . I’ll go first, but feel free to contribute . . .

  1. Where is the SkyViper wiki?
  2. When you hit EXPORT on the SV app post flight . . . where and what files “export”
  3. What do the numbers mean, embossed on airframe and transmitter? H1417TY & K1617TY (two different SVs)
  4. How many SVs can fly at the same time at the same location?
  5. Why does my SV get hard to control at just 5ft when critical battery level is reached with all the appropriate warnings? Have to hit the power button with the subsequent hard landing.
  6. Can you bind 2 factory transmitters to 1 SkyViper, with the possibility of handing-off mid-flight?
  1. http://ardupilot.org/copter/docs/skyrocket.html and http://ardupilot.org/dev/docs/skyviper.html, see also specific docs linked in there, for anything above and beyond skyrocket’s own documentation on their site.
  2. Don’t know about that one, I don’t use the app
  3. Model or internal factory #s I am guessing (possibly different from different generations). Not serial #s as I’ve got 3 transmitters that have same as yours).
  4. I’ve flown up to five. Not sure how many more would work, I think total bandwith available will be restricting factor.
  5. I haven’t specifically seen this behavior, but I would assume because battery level is critically low
  6. No, can only have one channel at a time. But you can have one transmitter to several skyvipers! Handy if you have a swarm and things go wrong!

Export on an Android is the Document\SkyViper_Logs folder.

Also, Battery level in the app need to be addressed. It is wonky and not accurate at all.

Would be nice (battery level better precision), although I doubt it can ever be achieved with such mass produced and inexpensive hardware.

Perhaps turbulence from the ground being so close? Which requires the motors to provide more thrust, which may be difficult if battery is low, since batteries may not have a perfectly level power curve…they tend to drop off towards the low end, which means you won’t have 100% thrust from all motors, and therefore compensating for turbulence will be more sluggish/unresponsive. Just the low battery in general might do that, for lack of full thrust to compensate for breeze or whatever else causes you a slight wobble.

Versus being 40 feet up, though that isn’t necessarily the happiest place to be when you’re low on battery, either.

Points well taken but at 5-10ft I’m not seeing turbulence as an issue . . . it seems to be more of a control input issue . . . like NONE when the battery gets to a certain point . . . with the false battery percentages and the false warning . . . LAND NOW . . . it’s hard to distinguish which one to believe so I go primarily by the flight time clock. Am I correct in assuming that when the battery gets to a genuine fatal level and RTL is invoked I should still have pitch and yaw control on decent similar to GPS locked RTL?

What R U using to open .bin files?

When FENCE_ACTION is set to 1, RTL or L (what action should be taken when fence is breached)
What has priority, RTL or L?
Also, why will my setting for FENCE_ALT_MAX not remain active? (set to 500) It returns to default value.

I use Mission Planner almost exclusively for looking through my .bin files. While the interface takes a bit of learning (it’s also a bit buggy and has several “undocumented features”), it’s ability to easily plot the .bin on a map and split Y-axes graphing is very useful.

Not sure about the second question, but with Fence_Action set to 1, it’ll RTL if it has GPS, and it’ll LAND if it doesn’t.

After a flight and re-arm, my settings for FENCE revert back to default values.

deleted deleted deleted
20characters

I don’t think that’ll ever work…the Sonix only communicates via UDB as far as I know. The libraries are there, but I don’t think a connection is available. @peterbarker would have to comment, it appears he has the most commits in Sonix.
By the way, why would you want to use TCP? Do you think you’ll get an advantage? The Pros for UDP is that multiple devices can connect without performance degradation (wifi network bandwidth notwithstanding)

Delete

20characters . . .

It’s all right here.
http://ardupilot.org/copter/docs/skyrocket-gcs.html

How about launching? Is it as easy as connecting to the SV via MP, uploading a waypoint file, arming the SV and hitting the throttle? (even if GPS does not lock?)

So, Auto is not an “armable” mode, so you have to do some trickery to
actually get it to take off. What I suggest is taking off manually then
switching to Auto. Map an action button on the controller to switch to Auto.

When you do it’ll fly straight to point 2.

For the map, on the right hand side, switch to Google maps. You also need to have internet connection to download maps. So connect to the internet and go to MP and download the maps in the area you’re going to fly. Then switch back to the SV wifi.

1 Like

Fresh back from my FIRST successful MP mission . . .
Questions . . .
Does MP override the FENCE settings I have modified? The Tx went nuts playing tunes!
The mission was a simple triangle route . . . after launch the SV went to altitude, loitered and then looked east, then looked north, then finally proceeded west to second waypoint. What’s up with that?

Is it necessary to put a TAKEOFF and a LAND argument in a Mission?

Q1: What the craft does when you breach the fence is completely programmable. I think the SV will just keep on for X # of yards. The transmitter will do tones to let you know you’ve breach the fence. I think there is a “second layer” that will eventually RTL. But because my transmitter reception has been so poor, I’ve never gotten that far.
Q2: No idea, you’d have to post your mission commands.
Q3: TAKEOFF and LAND are not necessary. FYI, when the craft gets to the “last” waypoint. It’ll transition to Loiter in place. So if you don’t have it coming home, then it’ll just stay there. I almost always put an RTL command at the end of all missions. And if I decide I don’t want it to RTL, I just override it. TAKEOFF is sticky, because Auto is not “armable” which means your SV won’t go into Auto mode until you arm it. Because the controller doesn’t have an “Arm” button (or switch or whatever) you cannot get it into “Arm” mode in order to then transition into Auto. The way the SV works is when you push the takeoff button, it arms and runs a “script” to perform a takeoff. If you have a GCS (like MP or Tower) up when running the show, then you can push the “Arm” button on the GCS. Then, you can transition to Auto, and if you have a takeoff command it’ll do that. … Not sure what it’ll do if you don’t have a takeoff command lol.

1 Like