Servers by jDrones

Questions about pixhack v5

pixhack-v5

(cuavle) #1

pixhack%20v52
A few days ago, Luisvale published an article on Pixhack V5 in the blog, which aroused heated discussion. It brings troubles to ArduPilot. We are sorry about that, but we also thank the developers who support us. To reduce misunderstandings, let’s introduce CUAV first.

As an important partner of ArduPilot, CUAV has always supported the development of ArduPilot and has been contributing to it. We complimentary Pixhack V5 to thank the ArduPilot team for their selfless dedication and no additional terms.

Let’s make a more systematic understanding of Pixhack V5.
Pixahack V5 is an advanced autopilot designed and manufactured by CUAV. The motherboard is based on FMUv5(open by the PX4 team) and is completely different from the FMUv3 open hardware design.
Quick Summary
Main FMU Processor: STM32F765
32 Bit Arm® Cortex®-M7, 216MHz, 2MB memory, 512KB RAM
IO Processor: STM32F100
32 Bit Arm® Cortex®-M3, 24MHz, 8KB SRAM
On-board sensors:

Accelerometer/Gyroscope: ICM-20689
Accelerometer/Gyroscope: BMI055
Magnetometer: IST8310
Barometer: MS5611
Interfaces:

8-14 PWM outputs (6 from IO, 8 from FMU)
3 dedicated PWM/Capture inputs on FMU
Dedicated R/C input for CPPM
Dedicated R/C input for ppm/DSM and S.Bus
analog / PWM RSSI input
S.Bus servo output
5 general purpose serial ports
4 I2C ports
4 SPI buses
2 CANBuses with serial ESC
Analog inputs for voltage / current of 2 batteries
Power System:
Power: 4.3~5.4V
USB Input: 4.75~5.25V
Servo Rail Input: 0~36V
Weight and Dimensions:
Weight: 90g
Dimensions: 44x84x12mm
Other Characteristics:
Operating temperature: -20 ~ 80°C (Measured value)

Pixhack V5 boldly adopted a new STM32F7 processor with up to 216MHZ main frequency and contains 2MB FLASH/512K RAM. Higher frequency, larger RAM and better performance bring more possibilities. And more stable ICM-20689, BMI050 and IST8310 were used to improve the adaptability of different temperatures. More external interfaces provide wider space for more hardware access and secondary development. In order to meet the highly integrated trend of the times, Pixhack V5 adopts a new V5 core platform, which opens up the imagination space for users’ personalized customization needs and the integrated external devices.
Finally, let’s talk about the most controversial appearance.
pixhack%20v52pixhack_v5pixhack%20v51

Some netizens say “isn’t it cloning COBE?”. But we think the more accurate expression should be inheritance of Pixhack V2/V3.It inherited the design of pixhack flight controlor, placed the main interfaces at the left and right sides, and put the new interfaces on both sides of the front and back. CUAV has been designed with independent IMU and built-in shock absorber since 2014,until now. The jst_gh connector was used earlier than the Dronecode pinouts standard, so that Pixhack V5 could only use the standard protocol on a completely new interface. If you look closely, you will find that pixhack v5 is different from cobe on either the baseboard or the core platform.
CUAV has established a good connection with the Pixhawk trademark holder Lorenz Meier, and maintains communication and cooperation in the development of px4fum-v5_default firmware. But we do not stop here. we has a large number of ArduPilot fans, so we also hope to call ArduPilot for fans and contribute to ArduPilot.
Thanks again for the contribution of the ArduPilot team, for the fans who have always supported us, and for those who have different voices.
Learn more about pixhack v5: https://docs.px4.io/en/flight_controller/pixhack_v5.html
Learn more about cuav: www.cuav.net


(chris rey) #2

Hi, available for testing?


(ppoirier) #3

Units have been shipped to developpers, that is the reason why @tridge has release some code already.


(Chris Olson) #4

Basic support is in master running ChibiOS. In the future there’s a lot of optimization that can be done for the M7, since it has hardware FPU that supports single and double-precision instructions. More efficient than using a software floating point library, and makes more sense than over-clocking the M4 core.

As developers take advantage of its features it will deprecate older hardware. But the advantages are undeniable and it is 100% binary backwards-compatible with the M4.

CUAV has indicated production units available around July timeframe.


(chris rey) #5

Oh! I just think that a developer would not test it the same way as a lambda user will…


(tridge) #6

A small clarification. The F4 has hardware single precision float. The F765 and F777 have both hardware single precision and hardware double precision float.
Right now there are very few places in ArduPilot that use double precision floats. We deliberately avoid them to make it fast on the F4. In the future we may see new features that make more extensive use of double precision floats (eg. a new state estimator from Paul). When that happens it will probably be a feature that is only enabled on boards with hardware double support (so that would be F7 boards and all the Linux based boards).
Cheers, Tridge


(tridge) #7

fmuv5 firmware (for both PixHackV5 and for Pixhawk4) is now in our auto-build system, so you can load firmware using the ‘latest’ build in MissionPlanner, or download firmware from http://firmware.ardupilot.org


(Matt) #8

Will MP auto-detect it and select the proper FW?


(Luís Vale Gonçalves) #9

Not yet, as some of the newer boards that have been added to the supported list with ChiBios


(Chris Olson) #10

I had to flash mine for heli with waf using the command line yet. I couldn’t get Mission Planner to recognize the board. QGroundControl recognizes it no problem but it will only load the PX4 stack, and not ArduPilot.

There is a still a problem with the LED on the module not indicating correctly for ArduPilot but I think @tridge is aware of that and working on it.


(tridge) #11

I’ve asked Michael Oborne about that

I hadn’t actually noticed, sorry. I so rarely have the LEDs setup on my aircraft that I didn’t notice the colours were off. I’ll have a look at it.


(tridge) #12

can you give me some more detail on what is wrong with the colours you are seeing? It gets detected as a ToshibaLED, and seems to display the right colours for me.
I’ve tested it with the MAVLink LED_CONTROL message and it does display the colours I ask it to display.


(Chris Olson) #13

I don’t usually use Mission Planner unless I’m testing something, as it is not my favorite choice of ground stations. I run it on Linux with mono and trying to get the latest updates thru the MP interface doesn’t work. I had to download the latest and install it, and then I got it to install the firmware for the V5:

All the colors flash with ArduPilot on the initial bench tests. With PX4 pre-installed it was flashing blue after boot. This initially faked me into thinking the board wasn’t booting ArduPilot as I was not able to connect to it with MP, APM Planner2 or QGC. Creating a manual link in QGC connected to it and identified the vehicle type as heli and firmware as 3.6-dev. All the colors flashing didn’t seem right, but it is because it is not initially configured.


(tridge) #14

yes, yellow flashing just means it isn’t armable. I think that is the same colours you would get on the built-in RGB LED on a Pixhawk1.


(Chris Olson) #15

I am still testing the components on the bench before installing in a helicopter. I was curious about the range of the WiFi telemetry radio. I powered the unit and walked across the field with my tablet connected with QGC. At 400 meters I still had a decent signal. I assume that radio could be used with a standard WiFi repeater with a high-gain or directional external antenna.


(tridge) #16

that’s better range than I expected.
Please watch out for R/C interference though. You’ll probably be OK, but some WiFi adapters interact very badly with some R/C protocols.


(Chris Olson) #17

I tested that this morning and there does not seem to be any interference between the two systems. I also tested the CUAV WiFi telem radio with a standard off-the-shelf WiFi repeater, and it works fine. But I’ll know more about the capabiilties of this system when I begin flight testing it, which will be later today.


(Chris Olson) #18

The Pixhack V5 is proving to perform flawlessly in a helicopter.

I’ve never had a chance to experiment with a WiFi telemetry radio before so the CUAV PW_Link radio is quite interesting. I tried a more extensive experiment. CUAV advertises the practical range at about 400 meters. But using a standard off-the-shelf WiFi extender at the ground station equipped with a high-gain patch antenna I connected to the helicopter with two different laptops, plus my Android tablet, all simultaneously thru the WiFi extender. I set up the WiFi extender to connect to the helicopter’s PW_Link radio.

I flew the helicopter out to 864 meters downrange distance and never lost the link on any of my three ground station computers. The helicopter was at an altitude of 33 meters. The external antenna on the PW_Link radio is stuck to the bottom of the helicopter frame with the included foam tape on it. The WiFi extender indicated a signal strength of 31% at 864 meters. The antenna I was using is a cheap Cisco AIR-ANT3549 9dBi gain directional type.

I have experienced no interference with my 2.4GHz RC radio whatsoever.

I haven’t been able to get the Pixhack V5 to mess up in the electric. So we’ll put it in the Raptor 716 gasser next. The PW_Link radio continues to impress me. I wonder if FPV video could be put on that WiFi link? It has typical MavLink latency. But it has me interested enough that I might get a CUAV Hack Link and try it, plugged into the HDMI port on a GoPro.


(Jakob Schmidt) #19

The wifi-link performance is interesting. I got one with my Pixhack V3 and A) was concerned about 2.4ghz interference and B) didn’t expect it to have any sort of range.
Given it’s small form factor, I may actually try to install it!


(Chris Olson) #20

It was designed to make it simple to connect to the vehicle with a mobile phone or tablet over short range. But a ham radio friend and I have played with wifi routers before to see how much range we could get with both commerically made and homemade antennas without dropping packets. In an environment with a lot of RFI it usually won’t get too far. But when you have LOS with antenna height and a relatively clean band the range can be a couple miles or more reliably with 5-10mW at the final amplifier stage of the transmitter with a good antenna. DJI’s Lightbridge system uses 2.4GHz at less than 20dBm with pretty good results so I’m not done playing with it yet to see what it can do :grinning: