Actually, this product is well-documented from PX4. I’ve had it apart and looked at how it’s built and what’s in it. It is no more of a “clone” than a Honda Accord is a clone of a BWM E-series. Kinda looks the same - otherwise not even close.
I wanted the pinouts to hook some different stuff up to it - no problem. It’s all in the PX4/DroneCode standard hardware design where most of these boards have come from. And I got the pinouts for it from CUAV’s docs. In English.
Yeah, CUAV have typically done a better job than the cloners. I never really even considered them a cloner in the past. I just think it’s a pretty crap move what they did with the styling of this, and some of the language used in the marketing material.
Taking Philip Rowse’s files, which is 100% proven, and removing/changing his license, removing attribution to him, putting their own name on it, and their own license, is a total dirtbag move.
You still haven’t pointed out a single thing that CUAV have done to support the Ardupilot developers, other than selling hardware for their own profit.
Compare that to the Ardupilot team’s VERY quick response to the discovery that there were license violations within the F4Light HAL code. As much as it is painful to remove such an important feature, they still, correctly, respected the license rights of the owner of the IP.
I don’t think there’s a comparison to the F4Light HAL code; I don’t think that ardupilot developers are responsible for policing hardware. Code license violations directly affect ardupilot and its ability to continue to operate, and it was handled appropriately. The hardware is licensed by hardware manufacturers, and it’s other hardware manufacturers that have an issue with it. I do not think we should be asking ardupilot developers to judge and act based on an accusation of IP/licnse violation between 2 other parties. If there’s a conviction, then that that may open up some more discussion.
Overall, I’m sad that this discussion has turned very negative over bringing on new partners that have given a donations and competitive free hardware to the developer team. It appears that this is not a public release yet, any maybe things will change (attribution, external appearance change, etc.). As @rmackay9 stated, we should really hold off jumping to conclusions.
Are you crazy? This is the Internet!
From Proficnc’s github
The Cube shape, the 30mm pitch with 80 pin connector are patented. These are NOT to be coppied without permission from ProfiCNC. Permission is granted to use this pattern for anyone building a carrier board to suite either the ProfiCNC / Hex Cube, or the 3DR Pixhawk 2. No use for any other purpose is licenced.
I suspect someone from ProfiCNC should challenge them.
I had no luck finding those patents filed anywhere.
Yeah…that may be the case.
If it does exist it would be fun to read in the patent filing how unique a cube shape could be, that would be patent-able.
Seems to me Apple already tried that with the PowerMac G4 Cube around the turn of the century. Didn’t work. Can’t patent a common shape. But they did manage to get a European patent on that glass cube with the white apple in it.
So I’ve been putting the Pixhack V5 thru its paces in helicopters and am able to provide a review of how it actually performs. The first thing that’s kind of amazing is the range of the WiFi telemetry radio (CUAV PW_LINK). It’s better than I thought it would be with my Android Tablet - 400 meters is not a problem at all without using a directional antenna.
The second thing that’s very impressive with this controller is the IMU accuracy and consistency. I have it mounted to the Raptor 716 gasser’s ESC tray with velcro and two small tabs of Scotch outdoor mounting tape on the sides to keep it from coming loose from the velcro, no other vibration isolation at all.
I have yet to get the IMU’s in this controller to alias at all. At 930 seconds into this flight, since the heli has a pretty stout landing gear, I banged it into the ground twice so I could look at the log to see if would alias the IMU’s. 51 m/s/s (5.2G impact with a 14.7lb helicopter) on the Z axis and neither one budged - they still perfectly agree on all three axes even during the impact.
It also flies very nice auto missions and has FBL unit quality handling in manual modes. With the end peripheral rail that makes the wire routing quite neat, what is obviously exceptional build quality, and the precise and accurate “feel” it has flying manually, it has become my controller of choice for helicopters. One wouldn’t think simply swapping out controllers would make that much of a difference in how the heli handles, but it does. In the past, going to my CGY750 gives the heli that “dream machine” handling, accuracy and “feel” on the controls. This controller matches it. For heli pilots it better not have any extra twitches or impromptu dance moves in it from sloppy or improperly damped gyros or we’re not impressed. This controller matches or exceeds any of the best I have flown.
ChibiOS and Copter 3.6 (I’m running the latest dev build, not rc2) is also performing quite nicely.
The Cube shape, the 30mm pitch with 80 pin connector are patented. These are NOT to be coppied without permission from ProfiCNC. Permission is granted to use this pattern for anyone building a carrier board to suite either the ProfiCNC / Hex Cube, or the 3DR Pixhawk 2. No use for any other purpose is licenced.
I feel I must be missing something, because this seems like a community hostile policy. There’s no valid reason to prevent inter-compatibility between suppliers for open source hardware.
There is no problem to have products that looks alike … unless one company said it is its original layout/product without any acknoledgement of the real original product (or doesn’t share back modifications). ProfiCNC restriction is the quite the same as the one on Pixhack V5 (open but prevent to clone it)
Open hardware isn’t a big deal for community as most don’t make their own FCU, but it is open door to any company to copy other products …
The main issue with CUAV is that they’ve obviously used the ProfiCNC design files as the basis for the PixHack v5, but have not adhered to the license requirements regarding attribution, or non-commercial use. This is something they need to address before I would consider buying their products, and it’s something that I think ArduPilot developers should consider before supporting and promoting CUAV.
By my understanding, the FMUv3 design is licensed CC BY-SA 3.0 from the original reference design, of the PX4 hardware project: https://github.com/PX4/Hardware
This license type explicitly allows commercial use.
Specifically, the design files for the FMUv3 Rev.D are located here.
From the last time I pulled up the design in Altium Designer Viewer, the reference design is very close to the final commercial product that ProfiCNC produces. Flat-flex IMU assembly and all.
Furthermore, CUAV had published the full design files of the Pixhack v5 on their hardware GitHub, prior to all of this having set them on edge.
Is there something in the timeline between the PX4 original reference design and the ProfiCNC development & release that made the original license of the FMUv3 invalid?
Edit: I’m reinstalling Altium Designer Viewer to double check the design files. Its been a while, so I have to make sure I’m not blowing hot air, here.
Edit v2: I rechecked the PX4 Hardware design files. The IMU is in a separate folder. See images below. The design below I believe is commercially usable with attribution and share-alike. Otherwise there needs to be a clarification of design licensing.
Top view of Reference Design FMU Main Board (bottom part of “the cube”).
Bottom view of the same.
View of the Flat-flex IMU assembly. This gets sandwiched in damping foam, folded up into the upper part of “the cube”. Top-right-ish connector mates to receptacle in bottom left frame of first image.
All that said, it does not appear that there exists a reference design for the carrier board. I do believe the stepped height of the carrier board is a technical necessity given the differing heights of the Molex CLIK-Mate power connectors (as compared to the lower profile JST-GH accessory connectors).
The Cube has no external USB port or LEDs option. In fact you can not fly with the usb cable installed in the cube unless you own a Spektrework custom board like I do. This is a issue in my opion. The LED on the here GPS are not visible during flight. Looking at the image I see what looks like they have a option for leds and usb for this hardware. BTW having any cube glow one color is worthless if they are not error colors like GPS calibration pre flight errors and flight modes. Naturaly in applications with enclosed frames the leds and usb needs to be moved to the outside of the frame…
.
Gentlemen, where is this? I have both products here in my hand. I have all the design files here and have studied them. These are both PX4 based boards. One is PX4 FMUv3, the other PX4 FMUv5. They are not even remotely the same. I have had both of these products apart to study how they’re built. One is totally incompatible with the other. They can’t even run the same firmware build. If anybody thinks they can unplug a Cube from its carrier and plug it into the CUAV I/O board I’d sure like to see it done. Because upon my examination the two are TOTALLY different.
What happened here is somebody yelled “CLONE!” and ran with it without knowing what direction they’re running. If somebody thinks there’s an issue here please take it up with Lorenz Meier and PX4, not ArduPilot. ArduPilot is not in the hardware business.
In the mean time we have a new board that ArduPilot runs on. Thanks to ChibiOS and @tridge efforts it was very easy to support. And it is a very, very good board. It is compatible with Pixhawk 4 on the software end. But for folks who don’t like the idea of all those SMT connectors coming loose on the face of the board and want a built-in servo rail that can handle 36v, this one provides a pretty nice FMUv5 alternative that is more robustly built.
Yes it does. It’s that little port on the side that look like a USB port. LEDs are visible in the same manner. And the HERE GPS has external LEDs.
Matt, Philip said 100% do not use connection to the small usb port in the cube during flight.
Led on the here GPS are not visible during line of flight when craft is above eye line.
" LEDs are visible in the same manner." I see no option to do this. hacking a cable disables the Cube leds according to everyone i have talked to. Please advise and submit a wiring diagram on said. Thanks.
@Quadzilla may have been referring to the Pixhack V5. The V5 does not have a USB port on the core/module. The Pixhawk Cube does.
Perhaps that’s the confusion.
