The two key message parameters are RADIO.rssi and RADIO.remrssi.The first is the RSSI (signal strength) level that the local radio isreceiving at. The remrssi parameter is the RSSI that the remote radio isreceiving at.
The reason the RSSI varies so much during this flight is that thesignal is attenuated when the plane is rolled over in a turn as I wasusing a simple wire antenna in the plane. The RSSI values for thisflight were plenty high enough for the link quality to be excellentthroughout the flight using the default radio parameters.
The most common source of range problems is noise. Noise is unwantedradio emissions in the same frequency range that your radio is usingthat interferes with the operation of your radio. The radios havetelemetry logging built in to help you diagnose the source of the noise.
Perhaps the most common source of noise with the 3DR-433 is noise fromthe USB bus on your ground station. That shows up as high values for theRADIO.noise value. If you get this, then you could try using a differentUSB cable, or a different laptop. You can also try using a USB hubbetween your laptop and your radio.
The key parameter that controls the range of your radios is theAIR_SPEED. The default is 64 (which is 64kbps) will give you a rangeof over a kilometre with small omni antennas. The lower you set theAIR_SPEED the longer your range, although lowering the AIR_SPEEDalso lowers how much data you can send over the link.
The radio firmware can only support 13 possible air data rates, whichare 2, 4, 8, 16, 19, 24, 32, 48, 64, 96, 128, 192 and 250. If yourapplication needs a different air rate for some reason then we canpotentially add it to the register tables. If you choose an unsupportedair rate then the next highest rate from the supported list will bechosen.
The ECC parameter makes a big difference to the data rate you cansupport at a given AIR_SPEED. If you have ECC set to zero, then noerror correcting information is sent, and the radio uses a simple 16 bitCRC to detect transmission errors. In that case your radio will be ableto support data transfers in one direction of around 90% of theAIR_SPEED.
If you enable ECC, then the data rate youcan support is halved. The ECC system doubles the size of the data sentby the radios. It is worth it however, as the bit error rate will dropdramatically, and you are likely to get a much more reliable link atlonger ranges.
As mentioned above, the radios support a 12/24 Golay error correctingcode if you set the ECC parameter to 1. This means that for every 12bits of data the radio will send 24 bits, calculating the bits usingGolay code lookup tables. The process is reversed on the receiving end,and allows the radio to correct bit errors of up to 3 bits in every 12bits send (i.e. 25% bit error rate).
If you set MAVLINK to 2, then in addition to doing MAVLink framing theradio will look for RC_OVERRIDE packets (used for joysticks) andensure that those packets get sent as quickly as possible. This optionis useful if you are using a tablet based joystick for control.
The RADIO packets also contain information about error rates, and howfull the serial transmit buffer is (as a percentage). ArduPilot canuse this information to automatically adapt the telemetry stream ratesto the data rate that the radios can sustain.
You need to be very careful to configure your radios to stay within thelegal power limits of the country you are operating in. The defaultpower level of 20dBm is fine for the US and Australia, as up to 30dBm isallowed by the LIPD class licenses there in the 915-928MHz frequencyband for a frequency hopping radio. So as long as your antennas have again of less than 10dBi you should be within the ISM rules.
Change MAX_WINDOW from the default of 131 to 33. This will ensurethat the GCS can send a packet to the vehicle at least once every 33msecs. It is worth noting that this will lower the availablebandwidth, so if you need absolute maximum bandwidth you are best offwith the default of 131. Both radios on a channel must have thesame value for this parameter, or they will not be able to talk toeach other.
To enable LBT in your radio you need to set the LBT_RSSI threshold.This is the signal strength that the radio considers to be an indicationthat the channel is busy. If you set LBT_RSSI to zero then LBT isdisabled.
The minimum non-zero setting is 25 which is a few dB above the receivesensitivity of the radio (-121 dBm). To setup LBT_RSSI you need toknow what signal level your local radio regulations require for LBTfunctionality. Each increment in LBT_RSSI above 25 is roughly equal to0.5dB above the radios receive sensitivity. So if you set LBT_RSSI to40 then the radio will consider the channel to be free if the signalstrength is less than 7.5dB above the receiver sensitivity.
The way firmware upload normally works is the planner connects to theradio and sends a AT&UPDATE command to put the radio into bootloadermode ready to receive a new firmware. That only works if the planner cansend AT commands to the radio.
to prevent the buffer from getting too much data (which increaseslatency and risks overflow) the radios send information on how fullthe buffer is to the connected device. ArduPilot adapts itstelemetry rates by small amounts to keep the amount of buffered datareasonable.
during the initial search for another radio, and any time the link islost, the radios go into a mode where they move the receivingfrequency very slowly but move the transmit frequency at the normalrate. This allows the two radios to find each other for initial clocksync. How long this takes depends on the number of channels, the airdata rate and the packet loss rate.
If the controller cannot be mounted in the recommended/default orientation (e.g. due to space constraints) you will need to configure the autopilot software with the orientation that you actually used: Flight Controller Orientation.
PX4 is protocol-compatible with radios that use SiK.SiK Radios often come with appropriate connectors/cables allowing them to be directly connected to Pixhawk Series controllers(in some cases you may need to obtain an appropriate cable/connector).Typically you will need a pair of devices - one for the vehicle and one for the ground station.
ROS is a framework for incorporating various modules of robotics by configuring modules as a TCP network. The ROS community is currently growing in a very fast pace both in the community and industry. The ROS wiki has great tutorials in understanding the framework. Please get used to using ROS following tutorials 1.~9. in the tutorials page.
MAVROS is a ROS package which enables ROS to interact with autopilot software using the MAVLink protocol. MAVlink consists of 17 bytes and includes the message ID, target ID and data. The message ID shows what the data is. Message IDs can be seen in the messageID command set.
MAVROS can be installed using the source in the mavros repository. The default dialect of MAVROS is apm. As we are installing px4 on the pixhawk flight controller, MAVROS should be built from source, by configuring mavros by the command below.
For the companion computer to communicate with the flight controller, a USB2TTL converter is needed to convert the voltage of the communication levels. A brief overview of configuring the companion computer with the pixhawk is shown in this link.
1.Recently, I am finding the transfer function of drone. Its input is roll pitch and yaw rate from topic mavros/imu_raw_data of mavros and its output is PWM signals of roll pitch yaw and throttle from mavros/actuator control that are coded on ROS, mavros, Odroid xu4 and px4 native stack firmware. The control signal of drone is from radio controller and sometimes this signal will be combined with chirping signals on roll pitch and yaw so that it will make my drone move around x y z axis and collect the necessary input and output data.2.To achieve this, I used topic mavros/rc/in which reads the roll pitch yaw and throttle signal from radio controller and scaled them to the range of -1 to 1. After that, I produce directly to the output of actuator using topic mavros/ actuator control (roll pitch yaw throttle channel of group 0). This code is fine! I can change my Pixhawk into Offboard Mode, then arm motor and control drone through radio signal, add chirping noise using switch on radio controller ( topic mavros/rc/in) as well as save the input and output data in text file.3.However, when running this code in my experiment, my drone oscillates a lot in take-off process and flip itself occasionally. I guess that the major reason is that the control signal from radio alone to control drone directly is not good.4.After that, I tried to turn it into Manual mode and used QRoundControl software to adjust PID parameters for roll pitch and yaw rate. Fortunately, my drone operates well with less fluctuation. However, with this flight mode, I cannot run my code as in section1 and 2 proposed because it is clear that my code only runs with Offboard Mode.Therefore, can anybody here that have experience with controlling drone with mavros and px4 native stack give me some ideas to solve my problem. I will run manual mode first and then switch it to offboard mode when my drone is stable? but to do that, what i have to add in my code or a process? or should I convert my code to program PX4 native stack firmware?Thank you too much for any help and discussion.