This project can be interfaced with 1 or 2 ELRS, FRSKY , HOTT , MPX, FLYSKY , Futaba, Spektrum or Jeti receiver(s) (protocol has to be selected accordingly).
When connected to 2 receivers, the output signals (e.g. PWM or Sbus) will be issued from the last received Rc channels. So this provides a kind of redundancy/diversity.
- to use a mp6050 device
- to configure oXs in order to get Rc channels and to generate PWM signals for the servos controling the camera
- to get from the handset the "original" (not mixed) sticks positions in 3 additional RC channels
- to get from the handset the gyro mode and general gain in 1 additional RC channels
- to use a mp6050 device
- to configure oXs in order to get Rc channels and to generate PWM signals for the servos controling the camera
- to edit the camera parameters in the config.h file and to compile the edited project.
Each function (telemetry/PWM/SBUS/gyro/logger/sequencer/localisation) can be used alone or combined with the others.
Note: when a mpu6050 is used (to improve vario reactivity, stabilize the plane and/or a camera), it is important to calibrate the mp6050 horizontally and vertically (see section below)
This project requires a board with a RP2040 processor (like the rapsberry pi pico).
A better alternative is the RP2040-Zero or the RP2040-TINY (both have the same processor but smaller board)
This board can be connected to:
a GPS from UBlox (like the beitian bn220) or one that support CASIC messages
note : a Ublox GPS can be re-configured automatically by oXs ( with own oXs param). It has then to use the default standard ublox config.
It can also be configured manually (with U-center firmware) externally prior to be connected to oXs. Set up must then be:
About the SDP31, SDP32, SDP33 , SDP810: Those sensors are probably better than MS4525. They do not requires calibration (and reset) and are more accurate at low speed. Those sensors exists in 3 versions which differs by the maximum differential pressure (and so the max speed) they can measure SDP31 (or SDP810-500) can measure up to 500 Pa = 105 km/h SDP32 (or SDP810-125) can measure up to 125 Pa = 52 km/h SDP33 can measure up to 1500 Pa = 189 km/h The difference between SDP3x and SDP800 series is mainly the size of the sensor. SDP3x are very small (5mm) and require soldering on small pin SDP810 are bigger (25 mm) and have a 4 pin connector Currently oXs code is written for SDP3x serie but using a SDP810 requires only to change the I2C address in the config.h file.
FRSKY/ELRS/JETI/... receiver, MS5611, GPS and other sensors must share the same Gnd
Connect a 5V source to the Vcc pin of RP2040 board ( RP2040-zero or RP2040-TINY boards do not accept more than 5.5V on Vcc pin !! )
There is no default affectation of the RP2040 pins so user has to specify it with some parameters after flashing the firmware (see below)
Depending on the protocol, the pins used for PRIMARY/SECONDARY RC Channels and for Telemetry (TLM) varies | protocol | PRI pin is connectected to | SEC pin is connected to | TLM pin is connected to | Comment |
---|---|---|---|---|---|
C(ELRS) | (TX from Rx1) | (TX from Rx2) | (RX from RX1) | ||
S(Frsky sport) | (Sbus from Rx1) | (Sbus from Rx2) | (Sport from RX1 or Rx2) | (1) | |
F(Frsky Fbus) | Fbus from Rx1 | (Sbus from Rx2) | Not used | (2) | |
J(Jeti ex) | (Sbus from Rx1) | (Sbus from Rx2) | (Ex from Rx1 or Rx2) | ||
E(Jeti Exbus) | Exbus from Rx1 | (Sbus from Rx2) | Not used | (2) | |
H(Hott) | (Sbus from Rx1) | (Sbus from Rx2) | ???(tlm from RX1 or Rx2) | (1) | |
M(Multiplex) | (Sbus from Rx1) | (Sbus from Rx2) | ???(tlm from RX1 or Rx2) | (1) | |
I(Flysky Ibus) | (Sbus from Rx1) | (Sbus from Rx2) | ( Ibus from RX1 or Rx2) | (1) | |
L(Spektrum Srxl2) | Srxl from Rx1 | Not used | Not used | (2) | |
2(Futaba Sbus2) | Sbus2 from Rx1 | (Sbus2 from Rx2) | Sbus2 from Rx1 via 1Kohm | (3) |
Note: pins between () means that they are optional.
(1) for safety, insert a 1 kOhm resistor between TLM pin and Rx
(2) for safety, insert a 1 kOhm resistor between PRI pin and Rx
(3) For Futaba, TLM pin must be equal to PRI pin - 1 and insert 1 kOhm resistor between PRI and TLM
Up to 16 PWM signals can be generated on pin gpio 0...15 (to select in setup parameters).
Voltages 1, 2, 3, 4 can be measured on gpio 26...29. Take care to use a voltage divider (2 resistances) in order to limit the voltage on those pins to 3V max. V2 is normally used to measure a current (based on the analog voltage). V3 and V4 can be used to measure or a voltage or a temperature (based on a voltage). For each voltage being measured, you probably have to specify the offset and scale to be applied.
One RPM (Hz) can be measured
When a MS5611/SPL06/BMP280 (baro sensor) and/or MP6050 is used:
When a differential pressure sensor is used, you should connect SCL/SDA like for a baro sensor.
When a GPS is used:
When a Hobbywing, ZWT, Kontronik or BlHeli ESC is used:
About sequencers and locator, see below.
The affectation of the pins has to be defined by the user. Here are the command codes and the pins that can be used are: Note: pin 16 is reserved for an internal LED on RP2040-zero or RP2040-TINY and so should not be used with this board. |
Command | used for: |
---|---|---|
C1 = 0/15 ... C16 = 0/15 | PWM output | |
GPS_TX = 0/29 | getting GPS data | |
GPS_RX = 0/29 | sending configuration to GPS | |
PRI = 5 ,9, 21 ,25 | primary RC channel input | |
SEC = 1, 13 , 17 ,29 | secondary RC channel input | |
SBUS_OUT = 0/29 | Sbus output | |
TLM = 0/29 | telemetry data (! for futaba Sbus2, this pin must be equal to PRI pin - 1) | |
V1= 26/29 ... V4= 26/29 | voltage (or current/temperatue) measurements | |
SDA = 2, 6, 10, 14, 18, 22, 26 | I2C devices (baro, airspeed, MP6050, ADS115, ...) | |
SCL = 3, 7, 11, 15, 19, 23, 27 | I2C devices (baro, airspeed, MP6050, ADS115, ...) | |
RPM = 0/29 | RPM | |
LED = 16 | internal led of RP2040-zero or RP2040-TINY | |
LOG = 0/29 | data to be logged | |
ESC_PIN = 0/29 | data provided by ESC (rpm, volt, current, temp) | |
SPI_CS = 0/29 | Chip Select pin from RMF95 (locator) | |
SPI_SCK = 10, 14, 26 | SCK pin from RFM95 (locator) | |
SPI_MOSI = 11, 15, 27 | MOSI pin from RFM95 (locator) | |
SPI_MISO = 8, 12, 24, 28 | MISO pin from RFM95 (locator) |
This software has been developped using the RP2040 SDK provided by Rapsberry.
If you just want to use it, there is (in most cases) no need to install/use any tool.
Developers can change the firmware, compile and flash it with VScode and Rapsberry SDK tools.
An easy way to install those tools is to follow the tutorials provided by Rapsberry.
In particular for Windows there is currently an installer. See : https://github.com/raspberrypi/pico-setup-windows/blob/master/docs/tutorial.md
Once the tools are installed, copy all files provided on github on you PC (keeping the same structure).
Open VScode and then select menu "File" + item "Open Folder". Select the folder where you copied the files.
In VScode, press CTRL+SHIFT+P and in the input line that appears, enter (select) CMake: Configure + ENTER
This will create some files needed for the compilation.
To compile, select the "CMake" icon on the left vertical pannel (rectangle with a triangle inside).
Move the cursor on the line oXs [oXs.elf]; an icon that look like an open box with some dots apears; click on it.
Compilation should start. When done a new file oXs.uf2 should be created.
For more info on VScode and SDK look at tutorials on internet.
Note : the file config.h contains some #define that can easily be changed to change some advanced parameters.
Note for ELRS:
The RP2040 send the telemetry data to the ELRS receiver at some speed.
This speed (=baud rate) must be the same as the baudrate defined on the receiver.
Usually ELRS receiver uses a baudrate of 420000 to transmit the CRSF channels signal to the flight controller and to get the telemetry data.
Still, ELRS receivers can be configured to use another baud rate. In this case, change the baudrate in parameters accordingly.
You have to compile your self the firmware if you want to change some values in the config.h file in order e.g. to:
For ELRS protocol, oXs does not received any RC channels data from the receiver(s) when RF connection is lost. If oXs is connected to 2 receivers (via PRI and SEC), oXs will generate PWM and Sbus signals on the last received data. If oXs does not get any data anymore from receiver(s), it will still continue to generate PWM and/or SBUS signals based on the failsafe setup stored inside oXs.
For Frsky/Jeti... protocols where Sbus is used, the failsafe values are normally defined inside the receiver and the receiver continue to generate a Sbus signal even if the RF connection is lost. Still, when connection is lost Sbus signal contains some flags that say that some data are missing or that failsafe has been applied. When oXs is connected to 2 different receivers, it gives priority to PRI sbus signal except when SEC signal is OK and PRI is not OK (no signal, missing frame, failsafe). So for Frsky/Jeti, oXs does not have to take care of his own failsafe setup (except if oXs would not get any Sbus signal anymore - e.g due a wiring issue).
For failsafe oXs has 3 options:
For the 2 last options, the handset must be on and generating the channels values that you want to save in oXs.
oXs tries to detect automatically which sensors are connected (based on the parameters being fill in the setup). It can display on the PC (on a serial terminal getting the messages via usb ) the current setup and the sensors that have been discovered.
oXs measures different fields depending on the sensors being detected.
Please note that the data being transmitted depends also on the protocol being used (Sport, ELRS, ...).
For more information, please look at document "fields per protocol.txt" in folder "doc"
When a baro sensor and an airspeed sensor are both used, oXs calculates 2 vertical speeds:
You can use a channel to control the way airspeed compensated Vspeed is calculated and/or transmitted.
First you have to send a command ACC (via the PC) to specify the channel being used (1...16).
You must use a protocol/wiring (like Sbus, Fbus, Exbus, ...) that allows the Rx to communicate the RC channel values to oXs.
Then, depending on the value sent by the Tx on the selected channel, oXs manages the airspeed compensated Vspeed in different ways:
Note: you can use the FV command to know the current coefficient. This allow you to check that your Tx sent a Rc channel value that match the expected goal and indeed required, adjust your Tx settings.
When an MP6050 is used, it is important to calibrate it and to let oXs knows his orientation in the plane. The mpu must be installed in the model in such a way that one axis of MPU6050 is vertical and that another one is aligned with main axis of the model (nose-queue). There are 24 possible orientations to match this. Most commercial gyro's require that the user declare the orientation of the MP6050 in the model. oXs does it automatically with a 2 steps calibration process (named here Horizontal and Vertical).
Horizontal calibration calculates the acceleration and gyro offsets in the 3 directions. It identifies also partly the orientation of the MP6050. It requires that the plane is set horizontally (like when it flies and roll/pitch are both 0) and do NOT move at all. Then a usb command MPUCAL=H is sent. The horizontal calibration takes a few seconds (less than 5). The result is displayed.
Vertical calibration completes the determination of MPU6050 orientation. It requires that the plane is set vertically with the nose up. It is not required to keep it totally still in this position. Then a command MPUCAL=V is sent. The horizontal calibration is done in less than 1 second.
Please note that, like other usb commands that change the configuration, you have to send afterwards a SAVE command to store the results in memory and so keep them after a power off or a reset.
The current configuration is displayed (like other parameters) with the ENTER command.
Once the MP6050 calibration process has been done and saved, it is normally not required to do it again. Still if you change the orientation of oXs in a model, you have or to perform the 2 steps calibration again or you can just change the orientation using 2 usb commands GOV (horizontal orientation) and GOV (vertical orientation). Those 2 commands can change the orientation but not the offset.
Note: at each power on, oXs performs automatically a new calibration of the gyro offsets (so nor acceleration offsets nor orientation). To get correct offset parameters, the model must stay still during the first 2 seconds. His attitude does not matter. It is possible to disable this automatic calibration with a parameter in file config.h.
Please note that when the MP6050 is used to stabilize the plane, you have also to perform a gyro mixer calibration. See gyro section.
With oXs, one single channel on the handset can control one or several SERVOS in sequences defined by the user (e.g. for landing gears with doors and wheels).
It can also generate one or several ANALOG signals in sequences (e.g. to blink leds or to start/stop motors).
One output is controlled by only one Rc channel.
You can use several Rc channels; each channel controls one or serveral outputs (SERVO and/or ANALOG).
oXs uses 3 concepts : sequencer, sequence and step.
oXs uses ONE "sequencer" per GPIO to be controlled. There can be up to 16 sequencers (one per gpio 0...15).
Each "sequencer" has several (min 2, max 21) "sequences". Each sequence is activated by a specific RC channel value (-100%,- 90%, ... 90%,100%)
Each "sequence" has one or several steps. Each step correspond to one action (move servo to position X, set led on power Y)
oXs can repeat continously one sequence or just stay on the last step waiting for a new Rc channel value to start a new sequence.
Each "sequencer" is defined by 7 parameters:
Each "sequence" is defined by 5 parameters
Each "step" is defined by 3 parameters
For each sequencer, when the handset sent a different Rc value that matches the value of a sequence, oXs starts "playing" all steps of the related sequence. If this happens while oXs is already playing a sequence, oXs will continue or stop playing the current sequence depending on the flags U, O and P (see above). If the current step may not be interrupted, oXs, will delay the new requested sequence up to the end of the current sequence. When the current sequence reaches his end, oXs will or play the delayed sequence (if any), or repeat the current sequence (if flag = "R") or keep the last PWM output.
For each sequencer, if the handset sent a Rc value that does not match a defined value (taking care of tolerance), the change of Rc value has no effect; oXs continues to "play" the current sequence.
Sequencers, sequence and steps are defined sending a command via the USB port using a serial terminal. So there is no need to compile/flash to change some parameters.
All sequencers are defined by only one command: SEQ=[...] (...) {...} {...} (...) {...} etc...
To delete all sequencers, enter SEQ=DEL
Processing of SEQ commands
Sequencers parameters are displayed as all other parameters when you press only ENTER. It is possible to make a complete copy/paste of the displayed SEQ to the input aera of the serial terminal in order to easily edit some parameters.
If the LOG Gpio is defined, all telemetry data and all PWM Rc channel values (usec) captured by oXs are transmitted on the LOG pin in a compressed format.
Each time a set of data is ready, oXs generates a packet (with only the newly generated data).
The packet is generated with an UART 8N1 (8 bits, no parity, 1 stop bit) at the defined logger baudrate.
Each packet starts with 0X7E (= synchro byte) followed by 4 bytes (number of milli sec since RP2040 start up) and by
There is some stuffing mecanism (like in Frsky Sport protocol) in order to ensure that the value 0X7E can only be present at the begining of a packet. \ \ This format allows to compress the data transmitted via the (quite slow) UART to the logger. \ \ The logger will remove the stuff bytes, uncompress the data, combine the new data with previous one to create an "actual" set of data's, convert it in CSV format and finally store it on a SD card.
When oXs get the Rc channels from a receiver (via Sbus, Ibus, ...) and when a MPU6050 is installed, oXs can apply gyro corrections on several servos. For more details, please read carrefully the file "gyro concepts.md" in the folder "doc".
Important note: at this stage, this is still experimental. It has not been intensively tested. So used it at you own risk.
oXs can be used to locate a lost model (if you add a LORA module).
The model is normally connected to the handset but when the model is on the ground, the range is quite limitted. So if a model is lost at more than a few hundreed meters, the handset will not get any telemetry data anymore. oXs allows to use a separate connection (with LORA modules) in order to have an extended range and have a chance to find back a lost model. This is possible because those modules use a lower frequency, a lower transmitting speed and a special protocol for long range. The LORA modules are SX1276/RFM95 that are sall and easily available (e.g. Aliexpress, ebay, amazon) \ \ The principle is the following:
You have to build 2 devices:
Normally:
When a model is lost:
Note: the range of communication between two SX1276 modules is normally several time bigger then the common RC 2.4G link.
If oXs and locator receiver are both on the ground, it can be that there are to far away to communicate with each other.
But there are 2 ways to extend the range:
An oXs device with a SX1276/RFM95 does not perturb the 2.4G link and consumes only a few milliAmp because it remains normally in listening mode and when sending it is just a few % of the time. So, in order to increase the reliability of the system, it is possible to power oXs with a separate 1S lipo battery of e.g. 200/500 mAh. This should allow the system to work for several hours.
Cabling : The SX1276/RFM95 module must be connected to the Rp2040 in the following way
To be checked : perhaps you have to use an additional voltage regulator (cost less than 1€) to get the 3.3 V, because it is not sure that the rp2040 voltage regulator can provide enough current when module is transmitting (for just a small time)
To build the locator receiver, please check and use the project openXsensor for Arduino (on github)
When a RP2040-Zero or RP2040-TINY is used, the firmware will handle a RGB led (internally connected to gpio16).
Note: some users got a RP2040-zero or RP2040-TINY where red and green colors are inverted. If you got such a device and want to get the "normal" colors, you can enter a command LED=I to invert the 2 colors.
Please note that other boards do not have a RGB led on gpio16 and so this does not applies.