Saturday, July 10, 2021

There is no such thing as free beer - RC link comparison

Controlling a model in the air is not all that difficult. There are analog systems that use PWM modulation that we all know from the old ages where RC hobby was only available for the very few ones with deep pockets and then there are digital systems like DSM2/DSMX, ACCST, ACCESS, CRSF, ELRS and probably a dosen more that rely on some kind of analog signal modulation (like FLRC, LoRa or others) to send digital information.

You might have heard about the exceptional results of ExpressLRS system that Wezly got from his long range tests. I mean, going 35km out on 100mW output power is seriously a lot. Even the mighty Ghost from ImmersionRC or Tracer from Team Blacksheep struggled to get past the 30km mark in the real world tests. So what sets ExpressLRS apart? Are those OpenSource guys just better than commercial companies? Is this the end of the world as we know it?

Well, as the title of this post says, there's no such thing as free beer. Nor is there RF performance that comes for free. Here's the secret behind ExpressLRS exceptional performance.

All other links, besides ExpressLRS are called by the number of channels they support. For example Crossfire (both 900MHz and 2.4GHz) support up to 12 channels. Sure enough there is prioritization of which channels are being sent most often (that'd be the first 4 channels where control inputs are being transmitted) but all channels are being sent with full resolution. If you come to thing about it that's a huge waste of bandwidth if you only want to send binary (on/off) information. That can be encoded on just one bit instead of 10 bits which is the usual resolution of channels.

This is exactly what ExpressLRS does - it sends 4 full resolution channels at an extremely high packet rate (500Hz!) but the rest is sent as 1 byte (8 bits) and only conveys if a switch is on or off. That's the default mode for ExpressLRS and it works great with software such as Betaflight or INAV and for simple setups such as a racing quad or a small flying wing.

There is a second "mode" that you can select when building the firmware that is called "Hybrid switches" in which the 5th channel is a binary switch that is sent with every packet (and that shall be used for controlling arming the quad),then there are 6 channels that can take up to 6 positions (3 bits) and finally there's the 12th channel which has a 4 bit resolution which amounts to 16 different values being sent.

Yes, you read this right: there are only 4 full resolution, high performance channels in ExpressLRS. This is how the link can have much much much smaller packets than any other system. But that comes at a cost. If you'd like to control, let's say, a gimbal in 2 or 3 axes you're not going to be able to do that with ExpressLRS. It just doesn't have the technical capabilities at the core of the solution that would allow you to do that.

Then there is the telemetry thing...

Telemetry is data being sent from the receiver back to the radio. It can include anything from link statistics, battery voltage to GPS position, altitude, attitude of the craft and many many more. That holds true for everyone - besides ExpressLRS. Sure, the basics, such as the GPS position and link stats are being sent back but that is about it. This, however, further limits the amount of data that needs to be sent back and forth which in turn means ExpressLRS can send less data in the aloted time frame and they can do it a lot slower thus extending the range.

So we know what are the limitation. Who would then use such a crippled RC system? Is it good for anything?

Let's examine the requirements of a typical racing pilot. First, the faster the response from moving the sticks the better. There is no limit to it. Faster is better. But does a racing pilot need telemetry? No. does one need a gimbal on the quad that goes from zero to 100 in a second? Hello no! What is needed is a reliable channel for arming/disarming and 4 very fast, very accurate channels to control the vehicle. That's it.

That's 1:0 for ExpressLRS vs everyone else.

Let's see what a typical long-range pilot requires to operate a vehicle at 50km+. 4 control channels - check. A way to arm/disarm - check. A way to switch between 4 modes (launch, air, 3D cruise, RTL) - check (although it requires a bit of fiddling around to get it to work with the default setup with binary switches - in the hybrid mode it is quite simple though). And frankly speaking 500Hz update rate is just not that useful. The thing that is usually happening during the flight is that the plane flys itself and the pilot only enters minor course corrections to point the plane where it should go. So even if the packet rate is at about 5Hz it will still be way more than enough.

But if one would like to have a camera that moves around to be able to see if there is anything coming in at the aircraft from any direction, then the 16 position AUX8 is just not good enough.

That'd be 1.5:0.5 for ExpressLRS vs everyone else.

Now let's go ahead and see what the big boys need. Imagine you're flying something like a hexacopter, with a gimbal and a lot of other accessories. You're most probably going to be doing that with the help of some ground station to better see where you are. For that you need telemetry and a control link that can not only send analog stick positions but also commands to the aircraft (most probably using the two-way MAVLink protocol). ExpressLRS is just not capable of any of that.

That'd be 1.5:1.5.

So it all depends on what you need vs what you can live without. If, for example, you're flying a tiny whoop and just want to have decent range but not a lot of cables and antennas - ELRS has you covered. If you're racing or freestyling and need the fastest link possible - again ELRS is the way to go. The greay area starts with piloting anything that can be a bit more sophisticated than just doing crazy things around the tree. Planes tend to have much more functionality that sometimes needs more control. This is where ExpressLRS starts to fade and other, full-fledged control links come into play.

Tuesday, April 6, 2021

Hasura - querying fields conditionally

As it turns out GraphQL is great :) I know, I know,... it's an old story but with Hasura sitting on top of PostgreSQL it is a whole different world to explore.

For example, there might be times where you have some filter that might say Select variant: "A", "B", "C", "any". Previously it was kinda obvious, that you'd say the values were [ 'A', 'B', 'C', null ] which resulted in collapsing the expression to an empty object but with the advent of Hasura 2.0 this feature was removed. Are we left with nothing? Hell no!

Conditional expressions

So let's say you have a String field that you want to either query by a value or skip in the WHERE clausule completely. How would you do that if null is not traversed to {}?

First, let's make an example and then I'll exaplain everything in details.

query GetItems($field: String_comparison_exp!) {
  items({
    where: {
      field: $field
    }
  }) {
    id
    field
  }
}

And the accompanying variables section to go along with it:

 { field: value ? { _eq: value } : {} }

So what happened here? First, as you can see we're not passing the value of $field anymore. Instead we're passing a String_comparison_exp. This is a way of passing the actual expression in variables. Previously, in Hasura <2.0 when a value was null the actual epxpression evaluated to an empty object ({}) which in turn evaluates to TRUE in the SQL being generated. That last part still holds true, but null is no longer collapsed in Hasura 2.0. Instead you need to do that yourself. There was a ton of issues with people deleting whole content of tables and so they removed this particular functionality.

Remark: if your field is not of type String there will be an error telling you what type of expression_exp you need to use. Just read the effin error message :D.

Summary

So now you know how to manually do the collapsing and you're the boss of GraphQL again!

Happy coding!