SkyViper Versions

I recently purchased a “SkyViper Journey Pro Video Drone”. It’s the one listed here: http://sky-viper.com/journey/

I believe it’s the same as the v2700 that I see mentioned, and that is sold byTarget, but, from what I can tell it has a part number of v1849. It appears to have all the functionality of the original v2450, but I’m not sure that it’s 100% compatible.

I’ve compiled the v2450 firmware from ArduPIlot github. Is it okay to flash that?

I’m one step ahead of you, was trying to build Ardupilot Master last night

And as I understand it the Journey is skyviper-f412 board.

Johno

And for what it’s worth I’m having issues building Ardupilot for that target. It errors out like this…

[7/96] ChibiOS: Compiling chprintf.c

In file included from ../../modules/ChibiOS/os/hal/ports/STM32/STM32F4xx/hal_lld.h:33:0,
                 from ../../modules/ChibiOS/os/hal/include/hal.h:122,
                 from ../../modules/ChibiOS/os/hal/lib/streams/chprintf.c:31:
../../modules/ChibiOS/os/hal/ports/STM32/STM32F4xx/hal_lld_type1.h:1776:2: error: #error "STM32_PLLI2SVCO outside acceptable range (STM32_PLLVCO_MIN...STM32_PLLVCO_MAX)"
 #error "STM32_PLLI2SVCO outside acceptable range (STM32_PLLVCO_MIN...STM32_PLLVCO_MAX)"
  ^~~~~
make: *** [modules/ChibiOS/obj/chprintf.o] Error 1

When I try to build that target I don’t even get as far as you. I get:

Waf: Entering directory `/home/webbb/projects/ardupilot/ardupilot/build/skyviper-f412’
Checking for env.py
env added DEFAULT_PARAMETERS=Tools/Frame_params/SkyViper-F412/defaults.parm
env added MAIN_STACK=0x400
env added PROCESS_STACK=0x2000
env added APJ_BOARD_TYPE=STM32F412Rx
env added APJ_BOARD_ID=9
env added BUILD_ABIN=True
env added FLASH_RESERVE_START_KB=48
env added CHIBIOS_BUILD_FLAGS=USE_FATFS=no MCU=cortex-m4 ENV_UDEFS=-DCHPRINTF_USE_FLOAT=1 CHIBIOS_PLATFORM_MK=os/hal/ports/STM32/STM32F4xx/platform.mk CHIBIOS_STARTUP_MK=os/common/startup/ARMCMx/compilers/GCC/mk/startup_stm32f4xx.mk
env appended CPU_FLAGS=[’-mcpu=cortex-m4’, ‘-mfpu=fpv4-sp-d16’, ‘-mfloat-abi=hard’, ‘-u_printf_float’]
env added IOMCU_FW=0
env appended DEFINES=CONFIG_HAL_BOARD_SUBTYPE=HAL_BOARD_SUBTYPE_CHIBIOS_SKYVIPER_F412
[7/7] Linking build/skyviper-f412/modules/ChibiOS/libch.a
[1/96] ChibiOS: Compiling crt0_v7m.S
…/…/libraries/AP_HAL_ChibiOS/hwdef/common/chibios_common.mk:251: recipe for target ‘modules/ChibiOS/obj/crt0_v7m.o’ failed

arm-none-eabi-gcc: error trying to exec ‘cc1’: execvp: No such file or directory
make: *** [modules/ChibiOS/obj/crt0_v7m.o] Error 1

Waf: Leaving directory `/home/webbb/projects/ardupilot/ardupilot/build/skyviper-f412’

What compiler / OS are you using? I’m currently trying Ubuntu with the latest lauchpad compiler, which worked well on the other skyviper target.

Make sure you made updates of modules
git submodule update recursive

And take note that building new firmware for the Journey breaks the receiver. I opened issue but no answer yet. You can fly using joystick connected to Mission Planner or you cam revert to skyviper firmware

Thanks for the additional info. I"m not seeing the same error as @John_Orthoefer by using the default arm compiler installed in Ubuntu (rather than the lauchpad version).

That’s strange that the receiver would be broken. I’ve read in places that it’s a standard DSM receiver. Is that right?

My next step was to try to use a standard Tx,…

Edit: I should add that this is a fresh checkout of the repo, so the submodules should be up to date.

I build on CentOS7.

It looks like your compiler (gcc) needs to be installed.

Did you install build-essential?

Build-essentials was the first think I thought of, but I use this machine for development, so, of course, that wasn’t it.

It would be good to figure out which compiler to use, since I had to install the lauchpad compiler to get the v2450 firmware to build. I don’t know why that compiler doesn’t work for the f412 target.

That seems to be the issue… cc1, which is one of the compiler phases, isn’t being found, at least not where it’s expecting to exec it.

Turns out I was using a old/broken copy of the toolschain. Re-downloaded the latest I I’m now getting to the same error with both toolchains.

I’m on UBUNTU 16.04 and installed according to wiki
http://ardupilot.org/dev/docs/building-setup-linux.html#building-setup-linux
And

I’m still unable to build skyviper-f412. Still erroring out at…

[6/95] ChibiOS: Compiling chprintf.c

In file included from ../../modules/ChibiOS/os/hal/ports/STM32/STM32F4xx/hal_lld.h:33:0,
                 from ../../modules/ChibiOS/os/hal/include/hal.h:122,
                 from ../../modules/ChibiOS/os/hal/lib/streams/chprintf.c:31:
../../modules/ChibiOS/os/hal/ports/STM32/STM32F4xx/hal_lld_type1.h:1776:2: error: #error "STM32_PLLI2SVCO outside acceptable range (STM32_PLLVCO_MIN...STM32_PLLVCO_MAX)

"

I did the following-

cd Repos/ardupilot
git remote update -p
git merge --ff-only @{u}
git submodule update --recursive
./waf configure --board skyviper-f412
./waf copter

Okay I’ve had some time to debug the issue… And I’m not sure where to go from here.

in modules/ChibiOS/os/hal/ports/STM32/STM32F4xx/hal_lld_type1.h

STM32_PLLI2SVCO for f412 seems to be defined as ((STM32_I2SCKIN_VALUE / STM32_PLLI2SM_VALUE) * STM32_PLLI2SN_VALUE) which have values of ((0/4)*192) which means it is infact out of range as defined by STM32_PLLVCO_MIN and STM32_PLLVCO_MAX

now tracing down why STM32_I2SCKIN_VALUE is zero I get to the following…

/**
 * @brief   I2S external clock value, zero if not present.
 * @note    Not all devices have this setting.
 */
#if !defined(STM32_I2SCKIN_VALUE) || defined(__DOXYGEN__)
#define STM32_I2SCKIN_VALUE         0
#endif

Do I open the ticket against ChibiOS or Ardupilot code base? I know enough about building software to track down the issue, but I don’t know enough about Skyrocket f412 architecture to know how to fix it.

Yes confirmed , master is broken , you can go directly in the chibios room
https://gitter.im/ArduPilot/ChibiOS and report
Note that I already reported = I will update here

Thank you the patch @tridge posted (enabling the check if there is an external clock) did the trick and it builds clean now.

I’ll load it on my journey and “bench test” it tonight if everything looks good I can give it a test flight later this week (based on weather).

Johno

1 Like

Please confirm if you still can control via RC,

as I wrote before,
… note that building new firmware for the Journey breaks the receiver. I opened issue but no answer yet. You can fly using joystick connected to Mission Planner or you cam revert to skyviper firmware

1 Like

Yep same issue. The RC Controller will not bind to 3.7.0-Dev (539000d). I tried a couple of different things to get it to bind, and it never did.

I have no issues using stock Firmware.

I don’t know if this is helpful, but this is in the log…

21:59:24 Check BRD_TYPE: INS: unable to initialise driver
21:59:27 Check BRD_TYPE: INS: unable to initialise driver
21:59:30 Check BRD_TYPE: INS: unable to initialise driver
21:59:32 Initialising APM

JohnO

For what it’s worth the issue with the remote only seems to be on the f412 board, the v2450 seems like it binds okay.

Yep, Journey use a different chipset, more here

Yea I saw that. that is why I said “For what it’s worth” :wink: