Pixracer Feedback Thread

I have them hard mounted to both a Spedix 180 and Spedix S250 Agility . I am able to fly both using default gains of one of the profiles, Iā€™ll have to look it up at home. Vibration has never been an issue for me.

I stuff a little bit of foam under the board between the baro and frame.

I am still waiting on my Pixracer at this time, but Iā€™ve started playing around with the PX4 stack on a spare Pixhawk intended for another project, and the first questions have came up :slightly_smiling:

  1. How does one enable OneShot? I donā€™t seem to find the option anywhere in the configuration. Is it only available on the v4 hardware (Pixracer)?
  2. How will FrSky telemetry work on the Pixracer? Since it has pins labeled ā€œFrSky_INā€ and ā€œFrSky_OUTā€ on the wiring diagram, I presume the previously required UART-TTL converter is not necessary. But how exactly does this work? And is S.Port telemetry for X-receivers supported, or only ā€œold-styleā€ D-receiver telemetry?
  1. PX4 always operates in OneShot mode (its a reactive design). Just set PWM_MIN to 125 and PWM_MAX to 250 to set the right pulse length. It should be accepted by your ESCs then.

  2. I donā€™t understand the question. The FrSky port will have software running for the telemetry protocol and yes, the inverter is onboard. Regarding FrSky versions: Weā€™re still tinkering with the implementation and aim to focus on the protocol generation on the Taranis.

1). OK, I see. Does changing these values increase the PID loop frequency? Other racing flight controllers (Cleanflight and especially Betaflight) run at up to 2KHz using Oneshot.

  1. There are two FrSky telemetry protocols: the older D-receiver protocol (supported by PX4 and described in the old user documentation; 9600 baud with separate TX and RX leads), and the new SmartPort protocol (aka S.Port; single wire, 57600 baud). The newer X-series receivers only support SmartPort, hence the question if it is now also supported natively by the Pixracer.

The rate at which your rate control loop runs says absolutely nothing about your latency. The latency is not the reciprocal (Kehrwert) of your update rate. A typical racer still has a latency of 15-30 ms, despite having an update rate of 0.5 ms.

Take smartphones as an example: What you as user care about is the responsiveness (latency) of the UI. If that would be linked to the GHz of your smartphone CPUs, iOS would be slower than Android, but yet the opposite is true (iPhones have lower clock speeds than Samsung models). The reason is that iOS has a good software and hardware fit because they design both, and the same is true here: Pixhawk and PX4 are sister projects run by the same people. And if you really, really care about GHz: Pixracer can deliver its sensor output at 4 KHz. Not that this would help you anythingā€¦

We will be focusing on the latency, not on the update rate. Because latency is what you as user care about.

Telemetry: We will support S.PORT.

Thanks for the detailed answer, that makes perfect sense. Quite excited to try out the Pixracerā€™s acro performance now :slight_smile:

Keep in mind that this is our first venture into racing. So I would not be surprised if you find things that we could improve. But because of the reasons laid out earlier it should be easy to do that very quickly.

Got my Pixracer earlier today.

Very happy with the hardware quality - everything feels and looks solid, quality soldering, no visible mistakes of any kind. JST-GH cables are indeed great - definitely the best mini connector Iā€™ve used so far; as compact as Micro-JST and DF13, but much safer and at the same time easier to connect and disconnect thanks to the mechanical latch. Also, AUAV supplies quality flexible silicon cables instead of the typical thin plastic wiring that melts away instantly when near a soldering iron.

PX4 software seems to work as wellā€¦ though there needs to be a big notification somewhere (preferrably straight in QGC) that a micro-SD card is necessary! One is not included with the Pixracer, unlike the ā€œoriginalā€ and most Chinese Pixhawks. As a result, PX4 firmware can be flashed no problem, and there are no errors - but QGC will not connect to the board. Got it to work once I remembered about the card, formatted an old 2GB ĀµSD to FAT32, inserted and then reflashed PX4 via QGC - only then did it autoconnect a couple seconds after finishing the flash, and now reliably autoconnects on plugging in the USB cable.

Next step is installing the whole thing into my QR400, then calibrating and setting up the software before maiden flight. Will report as new findings come in! :slight_smile:

1 Like

Got my Pixracer too :grin: Iā€™m impressed. Very good quality and compact size. Silicone cables are perfect. Loaded PX4 stack and successfully configured via QGC 2.8. Starting now to build my 450 size quad.

Btw. need some advice regarding OSD and 3DR telemetry radio. Where to connect both device? There are two ports:
USART3 -> TELEM2
USART2 -> TELEM1

Which one is better for OSD and which one for 3DR radio?

Thanks
Rgds
Mariusz

By default the Telemetry goes in TELEM1. OSD goes in TELEM2.

Thanks for clarification :smile:. Btw. I successfully flashed ESP8266 module and now I can use it with Pixracer. It is working like a harm :grin:. Flashing WiFi module was a bit complicated for me, because I never tried this before. But found a nice toturial for Windows platform and seems it was a good shot. Next week will get a new tablet and will check WiFi with QGC Android version too.

Is there a way to increase the update rates for TELEM2? I have a PlayUAVOsd connected there (essentially a next-gen MinimOSD with full-graphical display, MAVlink-compatible). It works fine, but the artificial horizon updates really slowly. In the APM firmware, there are parameters to set update rates for certain data types on serial ports, but I couldnā€™t find them in PX4 - was I not looking closely enough, or is it not possible?

Hi guys, great work on Pixracer! I am setting up a Blackout Mini H.

I happened to have an rctimer M8N so I cut the GPS/I2C cable and soldered it inline. I verified it worked and got a nice fix on the bench. But now that it is assembled on the Blackout frame, I never get a fix. The position remains about 1000mi from my location.

My guess is that this is related to interference since close proximity to various other parts is unavoidable on a small craft such as this. I have a FrSky X8R on the underside of the top plate behind the board camera and the GPS atop the top plate just above and forward of the location of the X8R. The video transmitter is far to the back along with the video antenna, so I donā€™t think that is an issue.

This is my first experience with the PX4 stack as all my other autopilots are Pixhawks running APM. So I have considered there may be some dependency Iā€™m not familiar with causing GPS issues.

I did remove the GPS from the mount and set it on the bench away from the frame (but obviously close since itā€™s connected) and it did not help.

Has anyone else experienced this? Any thoughts? When I work it out I will report back in case this is useful to others.

I would double check your wiring against this https://pixhawk.org/_detail/modules/pixracer_r09_bot_pinouts.png?id=modules%3Apixracer .

I use this NEO M8N all the time and it works great. http://www.readytoflyquads.com/mini-ublox-m8n-gps-w-35x35mm-mounting-backplane-and-compass

will do. The odd thing is that is ā€œkind ofā€ works, but lat/lng never get closer than 1000mi or so away. I was also able to go through compass calibration so I know I2C is working.

I really donā€™t think the issue is the M8N itself, they are great. So itā€™s got to be something about the wiring or the way I have things laid out.

When I have had uBlox issues and I know everything is wired correctly. I open uBlox uCenter and reset the GPS to defaults. Connect to the Flight Controller and boot. The Controller detects and configures the GPS as it requires.

I am considering using this on one of my big flying wings but I have a couple of questions:

  1. It seems that Pixracer unlike Pixhawk does not have a back up(failsafe) processor. What does it mean? Does it mean that fail rate in middle of flight is higher for Pixracer?
  2. Is there any document which says what Pixhawk can do which Pixracer can not and vice versa?
    Thank you.

Dear PKocmound,

I try to find answers in the german forum, but with no success yet. Iā€™m writing to you because of your experience with small racers.

Iā€™m flying the pixracer and have the news qgc with the master build firmware on it. The frame type is qav 250, as lorenz told me so.

The default values do not work at all! My copter start to shake as hell and this is definitely a PID issue. I now tried to set it manually but as my knowleg about PID settings is at the moment limited, I was wondering if you could give me a hand. I did the manual on the pixhawk website
https://pixhawk.org/users/multirotor_pid_tuning

The default values written in this text are not working for a racer.

Another question but not for you I think, in cleanflight/betaflight I can choose between around 5 PID controller and then set my pid values. The algorithm are translating the PID values a different way, some work better and other less. It seams to have only one controller/algorithm in px4. Will this be in the future different?

And a last question, in cleanflight you got a TPA option, this is, as far as I understand it, a "high throttle " compensator for pid. How dose px4 manage the PIDā€™s at hight throttle?