The video below (enable audio!) shows a detailed overview of the new Pixracer flight controller.

It is the 4th generation of the Pixhawk flight controller family (make: FMUv4) and like the first generations designed by the Pixhawk Open Hardware team in collaboration with an international dev team. It supports the PX4 and APM flight stacks. If you like to try PX4 on it, follow the user guide.

Views: 20476

Comment by Thomas Butler on January 20, 2016 at 12:05am

@PX4 What is a "low cost racing system"?  Another attempt at creating a market niche?

As I said, the designers lack fundamental knowledge about resonance that should have been considered five years ago. To  " isolate the whole board and the connecting wires are high-flex silicon" is only a cop-out because of poor mechanical design in the mounting of the sensor. Only the accel & gyro need to be isolated. Why the intransigence on the issue of proper isolation of the sensors behooves me. 

The manufacturers are only copying; not innovating. Monkey see monkey do. The "new" 9250 sensor is merely the MPU6000 on the same die as the magnetometer; nothing really new.

PX4, to really advance the technology of flight controllers you need to stop cow-towing to the status quo. The idea that software can "fix" the vibration by using tremendous amounts of CPU power is a software engineer's typical canned response and is just ignorant when all it takes is proper mechanical mounting and dampening of the accelerometer and gyroscope.

The fact is that the APM with an Atmel2560 can easily handle the flight controller processing when the accel & gyro are properly mounted. The STM32 based controllers only need the Kalman filter because of the deficiencies in the hardware mounting of the sensors. Unfortunately, poor design gets propagated because "that's the way we designed it" and the Chinese do not innovate that merely steal designs and propagate the flaws.

In addition, the STM32 software development environment is an archaic nightmare. Visual Studio with the Atmel2560 works like a charm. Perhaps the use of the AtmelS70 (ARM CortexM4) is in order which is supported in VisualStudio. No reason to keep using the STM32 and its archaic heterogeneous development environment. 

The real cost in computers is the software. Not the hardware.

Comment by crayfellow on January 21, 2016 at 4:49pm

On topic: My Pixracer arrived today! As an R&D engineer working to put as many sensor packages as possible in the air for scientific research, I'm excited to explore the opportunities this tiny new board affords! We have a Blackout Mini H that I think will really appreciate the new capabilities. Great work guys!

Somewhat off topic:

@Thomas Butler with all due respect, I have no doubt you are a skilled ME but your reference to Visual Studio as something other than an archaic nightmare demonstrates a lack of connection with modern software/firmware development. I personally do not ever run Windows unless absolutely forced to do so, since there are still embedded dev tools which are Windows-only. I have never used Windows for any kind of serious development, software, firmware, or hardware. My favorite IDE is SublimeText which to many might look like 'just a text editor', but it gives me the productivity advantage I need without the cruft. I like the command line and know many skilled developers of all ages who feel the same. I don't mind decent high-level tools either (such as Xcode).

So - I applaud you for speaking with authority as an ME, but ragging on GCC-based development with the IDE of your choice is simply not accurate.

Comment by gervais on January 23, 2016 at 4:22am

I´m an vibration damping addict as well, but that´s not a problem with the Pixracer which arrived with nice flexible silicone wires.Since my case,which AUAV designed with a barofoam enclosure is not ready yet, I mounted it on top of a carbon plate which squeezes the barofoam on one side and is providing a nice surface for HK Orange Latex foam on the other.

For my first build I took a Robocat 270, which is not small, but offering lots of space even at the basement for the ACSP4 Power Module with distri board. Nice fat great to solder pads, not the usual micro contacts,close to each other...I love that.

Naked look,nearly fully assembled, GPS and telemetry still missing :

With HK GNSS which is not that bad as the former Hextronik were and (temporarily) a 3DR radio, not available anymore, too big anyways, will be replaced by the 8266 ESP-01 WiFi radio as soon as possible.

Almost ready to fly (here with a U-Mite radio..still too big and too close to the GNSS):

Waiting till the snow goes away:

Lots of improvements possible and probably required as well :-)

Comment by Thomas Butler on January 23, 2016 at 8:35am

Sorry this is so long folks, but it is too cold outside and I have nothing to do! Most is a rebuttal to posts by others.

Hey @gervais!    It’s amazing far the quadcopter technology has evolved over the past five years (compare this to an Iris).  Your compact integration is excellent. However, I’d like to see: 1. What happens when there is a hard crash and the flight controller breaks loose from the sticky pads, 1. How well the copter can hover/loiter. I realize that this is a “racing” copter, but just want to see how stable this little bee  is(I assume with ArduCopter 3.2 or 3.3). Thanks.


Hey @dave!   The bailout (RTH) capability assumes the flight controller has not gone haywire. A better solution would be a completely independent hardware based kill switch; transmitter & receiver; probably a mandatory device in the future which can also be controlled by the FAA and defensive installations to “kill” a copter.  Just as with GPS which the military can easily jam if it wants to since it is on a single non-encrypted frequency.

Additionally, do you know how many flight controllers I have bought which do NOT work? Many. Think of how much energy (manufacturing, materials , etc.) has been wasted and is now sitting in the recycle bin or dump. You probably bought a 25 foot roll of silicone wire, yet you only need six inches. R&D and tooling can be spread over the entire production of a product.  Additional ancillary items (silicone wire, special rubber isolators) add to the cost and complexity of every item produced.  The manufacturers will NOT stay in business providing you with your toys if they cannot make money.  Look at what is happening with 3DR; bailing out of the DIY product paradigm.  If the engineers involved with flight controllers had done their R&D in both software and hardware, we would have a PixRaptor/Pixhawk2 type design five years ago. There is a reason the Pixhawk2( and Pixhawk3) are dumping the ST sensors; the proven Invensense sensors are superior.

Hey @crayfellow!   I only mention using VisualStudio because it is one of the few completely integrated development environments that actually works with AuduCopter firmware AND APM; with VisualMicro and AtmelStudio(custom copy of VisualStudio).  Just when this integration became possible (less than two years ago) APM in ArduCopter became unsupported because of the “lack of memory and CPU power” (FYI the first PixHawks, and probably all manufactured, only can access the first MB of flash memory for code space because of a bug in the CPU, so no doubt the “PixHawk 2/3 or Pixracer” will be running a superset of ArduCopter requiring more than 1MB code space flash) which will not run on the PixHawk. Look at how much “cruft” is in the current ArduCopter firmware; helicopter code, optical-flow, high level autonomous control (which really should NOT be in the base flight controller.) The ability to click on a variable or function name and have the IDE jump to the code , the ability to watch a variable’s value and change it on the fly, to track changes, to step through high level code are all hallmarks of efficient development; which translates to higher productivity, more WORKING code developed,  all translates to lower cost.  I do prefer VS because it is a commercial product which works because the developers are PAID to make it work. Fixes do not appear “someday” as is the case with most open-source doe. Installs are effortless and integrated. DIYers who want to get into the code don’t have the excruciating amount of time required to learn the archaic command line commands of a command line driven development environment.  I would never want to put my developer staff through the agony of using 1960s era development methodologies which is essentially what the original Arduino

environment is and where the PixHawk/STM32 environment is, nor would I pay them to waste time learing something they will never use if they leave my company.  

In closing, this “Pixracer” controller misses the boat. It is another compact flight controller that has its sensors onboard; a fundamental design flaw in flight controllers. It uses the STM32 which does not have a state-of-the-art (aka easy to use) development environment. The Quanton flight controller is basically the same but a few millimeters bigger.  I am working on an Atmel S70 (same ARM M4 processor core as STM32F4xx) based controller which will use the AtmelStudio(VisualStudio) development environment, so I am not merely ragging, but am actually doing something substantive about the mess

Attached is a schematic of my STM32 flight controller design (PX4 compatible) which I am porting to the Atmel S70 CPU. It eliminates most of the cruft which exists in the Pixhawk/PX4 design. It will allow anyone to easily create code using the AtmelStudio IDE.

Happy flying!

Comment by Thomas Butler on January 23, 2016 at 8:50am

Forgot to add; the use of the on-board accel &g gyro on my board is for comparison to see how well the isolation/dampening is working with the off-board sensors during R&D and could be left off of the production controller. My board design utilizes up to two IMUs isolated though FFC connectors; could even be more using the integrated MPU92xx chip.

Comment by Scott W on January 23, 2016 at 9:21am

Can anyone give me specifics on hooking up minimOSD to pixracer with PX4?

Which serial port, where do I set up the parameters, etc?  The config is not the same as arducopter, and I cannot find instructions.

Comment by PX4 on January 23, 2016 at 9:23am

Use TELEM1 (TLM1 on the board I believe). Its the usual pinout:

Comment by Scott W on January 23, 2016 at 9:34am

Thanks! And, no software settings?  In APM, I have to set up specific serial port settings, or I don't get a display.  And what about MinimOSD firmware?  Does MinimOSD Extra 800 work, or is there a specific PX4 firmware?  (I found uncompiled px4 minimosd code from about 6 months ago, but very little info about it)

Comment by PX4 on January 23, 2016 at 10:37am

So I just pushed a new binary to clean up port mappings: TLM2 is recommended for OSDs (it has the right MAVLink messages enabled) TLM1 for Telemetry radios.

PX4 runs four MAVLink instances: One on the Wifi socket, one on TELEM1, one on TELEM2 and the last one on USB. If you get the wiring wrong it will still work, but your OSD might not get all messages it needs.

Please flash the latest development version for Pixracer - its so new that using the cutting edge makes sense. I have attached a screenshot that explains how to do this:

Comment by PX4 on January 23, 2016 at 10:37am

And we generally recommend the DAILY BUILD of QGroundControl for that purpose. Tons of improvements going in every few days - e.g. the latest version does auto-connect and doesn't require you to fiddle with serial ports at all.


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service