If you want to debug an Android application that needs USB tethering – say a FPV app – then you can use the following steps.
- You need to first connect the device to the same wifi network as your PC.
- Then start the USB tethering and provide internet to whatever you need – say a Raspberry PI running wifibroadcast or my RC software.
- Run this in a terminal:
adb connect 192.168.1.33:5555
where 192.168… is the WiFi IP of your device
- That’s it. The device is now visible to Android Studio & QtCreator just like if it were connected by USB. I didn’t notice any slowdowns in deployment vs USB – but my app is rather small (a few MB)
For a multirotor to fly, the thrust of each motor has to be equal, within certain tolerances. These tolerances depend on the bandwidth of the multirotor which are usually reflected in (well tuned) rate PIDs.
Let me explain:
The rate PIDs are usually tuned to reach the best impulse response which depends on the moment of inertia (radius, mass and mass distribution) and thrust inertia (prop weight, motor power, ESC, etc etc).
Unbalanced motors result in a steady-state error for the rate PID which it has to compensate for using the P and the I terms. Going too high with either term – higher than the multirotor bandwidth can allow – will cause oscillations and instability.
It might seem obvious that unbalanced motors are bad. In the end all motors – even high end ones – tend to have slight Kv differences which results in different thrust for the same PWM input. It happened to me when I last tested my quad – it kept flipping over at launch and I didn’t understand why the PIDs cannot compensate for this. All other quads work and surely they have their own unbalanced motors.
So when I got home I measured the Kv of each motor and I found that one of them is lazier – around 90% thrust compared to the others.
So I fired up the simulator and added some randomness to each motor thrust (between 80% and 120%) and yes – the quad wouldn’t fly. The rate PID was unable to compensate for the difference in thrust. Increasing a lot the P term or a bit the I term stabilized the quad.
But what if I couldn’t increase the P or I because of oscillations? What if my PID was at its limit, stability wise? Then the quad would not be able to fly with this particular combination of motors and moment of inertia.
Seems like a silly conclusion – if the motors are bad the quad will not fly – but I felt like I had some sort of epiphany that the thing responsible to compensate for bad motors is the same thing responsible for fully using the quad bandwidth – so unbalanced motors need some bandwidth margin to allow the PID to compensate for them.
I built a custom testing rig out of some plywood sticks and these kind of elastic cords:
There is just enough clearance for 7 inch props and the quad is free to rotate around one axis (Y or roll in the video). I can easily change the free axis as the cords connect to the arms with metal hooks.
The issue I’m debugging now is related to a tendency of the motors to generate different thrust for the same throttle input. I think it’s because the ESCs have different settings on them as I couldn’t find any issue with my code so far. If I send 50% throttle to all motors the quad spins a lot.
In my last post I talked about using the si4463 chip to send video, telemetry and RC data to the quadcopter. I calculated the bandwidth and it seemed that 500kbps video with 5/7 FEC coding should be possible.
I wrote the code, linked everything together and it kind of worked. The video was stable, not many packets lost but the latency was pretty bad. It got up to ~200ms from the current 100-130ms but worse than this, the video was very choppy. I managed to narrow it down to the H264 codec in the raspberry pi: the bitrate you configure in the codec is an average bitrate, per second. Each frame can vary a lot in size as long as the average is preserved (with some allowed over and undershoot). I got I-frames of 12-16KB and P-frames of 400-500 bytes (at 30 FPS). The I-frames took way longer to send than the P-frames and this resulted in a choppy video. I tried to play around with settings – like disabling CABAC and activating CBR but nothing made the bitstream uniform enough.
The final, biggest problem was actually caused by the RF4463F30 module – and it’s the same problem I had months ago when I tried to use them: they introduce a LOT of noise in the power line, enough to cause all the I2C chips on the quad to fail.
I tried all kinds of capacitors to decouple the module and reduced the noise a lot but there seem to always be some capacitive/inductive coupled noise persisting.
In the end I just gave up and went back to the RFM22B chip which just works. For video I went back to the monitor mode/injection system but did change the modulation to CCK, 5.5Mb to hopefully reduce the possibility of interference with other 2.4Ghz RC systems. CCK is spread spectrum similar to DSSS and should be able to coexist with RC systems around.
So yeah, FPV through a very constrained channel with a temperamental H264 encoder and a very temperamental transceiver module is not fun…
It’s been a while since my last post and that’s not because I abandoned silkopter, but because I’ve been very busy working on it.
During my latest test 3 weeks ago I noticed that the video link is not as stable as I wanted. I’m using a system similar to wifibroadcast – wifi cards in monitor mode doing packet injection. They are working on 2.4Ghz and the area where I’m flying seems to have this band a bit crowded, causing the video link to be glitchy.
On the other hand my 433Mhz RC link has been pretty solid. So inspired by this I started thinking if I could do the same thing: send video through my RC link.
I already had the RF4463F30 transceivers which are using the si4463 chip and I knew them well (and hated them a lot) so I thought to give it a try.
Now – the max bandwidth the si4463 supports is limited to 1mbps which might seem like enough for 640×480 resolution but there is a lot of overhead that effectively limit this to around 755kbps. Since I want some FEC – say 5/7 coding – I end up with 500kbps target video bitrate.
I made an xls to ease the calculations. It allows me to specify the air bitrate, packet sizes, packet overhead, video bitrate, fps, preamble/sync sized, header sizes etc and calculates all kind of nice info, including if the link is viable or not.
Here is a screenshot with my current calculations:
For the video link, 500kbps seems like enough as there’s not a lot of movement in a quad, specially with a gimbal. To further improve quality and decrease latency I’m experimenting with the x264 software compressor library instead of the GPU compressor in the PI. It seems to be able to compress real-time a 640×480 video with good quality, zero latency setting and 2 cores only.
I still have to compare the quality between the 2 (GPU and x264) though.