I am wondering if it makes sense to fuse multiple GPS signals to improve my estimated result. This works fine for example for accelartion sensors, but this sensors have a white gaussian noise.
GPS sensors being mounted on the same board probably suffer from the same errors like drift or multi-path effects, which cannot be corrected by only fuse the sensor readings of this sensors. I imagine that like a constant offset in the same direction, which won t be correct just stays nearly the same.
Furthermore, I have diffrent sensor which I can mount on my drone, even RKT sensor. In my opinion, it makes no sense to fuse a d-GPS with readings from an RKT GPS.
Please correct my if I am wrong.
Thank you in advance and I hope this forum is the right spot to ask that question.
yes you can. Use EKF based approach with onboard multi GPS and multi IMU
The DJi is doing it, But it is can only prevent one of sensor failure, not the systematic drift patter. To avoid that, you need some more source such as visual odometry or lidar odometry to fuse in the EKF. GPS sate count is good meaure of how bad the position is. It ranges from 0 to 15. So when every one is 15, trust GPS more less variance. When everyone is lower than 6 add very high variance to GPS source.
Yes RTK might be better when you have direct line of sight. But once out of sight, then other GPS might be better. So totaly depends on your use case
Related
I have a vehicle with a tracker installed. The device has a gps syst, 3-axis accelerometer, 3-axis magnetomet and a gyromeyet. Is it possible to determine by how much the vehicle rolled back on a slope or hill. Using gps angle wasn't an option as the angle given for short backward movement isn't always reliable. Can accelerometer be used in such a scenario??
You're right that the GPS angle (heading) will not help you in a single-antennae setup. On its own a GPS receiver needs a minimum distance of movement to determine heading.
A simple GPS receiver, when used without GPS corrections (which is the case for off-the-shelf GPS devices and mobile phones/tablets), has a minimum ~5 meter accuracy. That's why a short backward movement will not yield the desired results.
In construction/mining applications, there is often a fixed GPS base station nearby that broadcasts GPS corrections, which allows vehicle-mounted GPS receiver to apply corrections, reduce error and ultimately get centimeter-level accuracy.
So in conclusion, your 3-axis accelerometer will likely be the only sensor that you can rely on until your vehicle has rolled back at least 5 meters.
If your accelerometer is sensitive enough, you'll get measurable sensor values. However, if you rollback is very slow, where the G forces are almost imperceptible to the accelerometer, then you're out of luck.
This is assuming that you want near real-time detection of vehicle rollback.
I am doing a project on indoor localisation using fingerprinting. Is it possible to build a system in LabView which can scan the entire spectrum and provide me the RSSI measurements of different types of signals?(say FM, GSM, DVB-T and so on.) In case it has to be done separately, can someone please point me to some resources that would help me to find the RSSIs of say, FM signals? I am new to SDRs and would really appreciate some help. I have used this paper as a reference:
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7444902
There can be no general method. RSSI is inherently signal-specific, and hence, for each signal type, you will need a different estimator. An estimator that estimates the received signal strength of FM broadcasts will only see noise in a DVB-T signal at incredibly high noise power with no stable signal at all, whereas a DVB-T RSSI indicator would only see a slowly moving interfere in an FM signal.
I see you're using the indoor-positioning-system tag. That is a very bad thing: In an indoor scenario, fading is extremely important, and your received signal strength allow absolutely no conclusions on the distance to the transmitter. This is pretty much the definition of the indoor channel, where lots and lots of reflections overlap and interefere, and there's not always a direct line of sight between transmitter and receiver.
I'm afraid you still have quite some theory to read up on.
I was wondering if I could get a cheap GPS tracking device such as this one on amazon and reprogram it to send the co-ordinates to my own server? I would then like to generate reports from the DB on my server based on dates etc. I would like to build this for a very small-scale courier company I am planning on starting.
I am an amateur/hobbyist programmer and am looking for a few pointers to help me get on the right track. Pun totally intended.
This is a very broad question. But since no one answered so far, I will just throw in my two cents. First of all, you need to know what GPS signal the (cheap) receiver can track. If it can track only single frequency at L1, there's not much you can do. You have to live with large ionosphere fluctuation error signal.
http://www.navipedia.net/index.php/Ionospheric_Delay
If it can only track code signal (not carrier phase signal) you cannot do code smoothing to reduced the noise level of code signal received.
In other words, if a GPS receiver hardware is limited, there's not much room for improvement.
I am trying to access the physical un-calibrated gyroscope sensor. But I am unable to. Since I can only access the calibrated one, I want to know what method is used for drift compensation in the gyroscope sensor used in the Tango Device.
Nobody knows exactly what Tango uses for drift compensation, my own guess would be that they are heavily reliant on Structure From Motion techniques. If you're asking how to calibrate an already calibrated gyro (calibration quality is a different issue :-) ), that's a topic for an entire stack overflow site, not a single answer :-) And it would leave you battling for computation resources with Tango - if you want to experiment, any phone with 3DOF attitude sensing and a decent camera is a good starting platform for learning about this, but be warned - it's really complex - much nicer to have it packaged and take what you get.
Hi Im using the following RF module
http://www.apogeekits.com/rf_receiver_module_rx433.htm
on an embedded board with the PIC16F628A. Sadly, I realized that the signal strength was in analog form and couldn't get any ideas to get the RSSI reading off the pin because well my PIC is digital DUH!.
My basic idea was
To get the RSSI value from my Receiver
Send it to the PIC
Link the PIC to a PC via RS232
Plot a graph of time vs RSSI of the receiver (so I can make out how close my TX is to my RX)
I thought it was bloody brilliant at first but ive hit a dead end here. Any ideas on getting the RSSI data to my PC from this receiver would be nice.
Thanks in Advance
You can get a PIC that has an integrated ADC for sampling the analog signal. Or, you can use an external ADC chip to do the conversion. You would connect that to your PIC using SPI or I2C.
The simplest thing to do is obviously to use a more appropriate microcontroller - one with an ADC! There are many (most), including PICs (though that wouldn't be my first choice).
Attaching an external SPI or I2C ADC might be a bit tedious since having no SPI or I2C on your part, you'd have to bit-bash it. If you do that, use an SPI part - its simpler. Your sample rate will suffer and may end-up being a bit jittery if you are not careful.
Another solution is to use a voltage controlled PWM, then use the timer input capture to time the pulse width. That will give you good regularity and potentially good resolution. You can get a chip (example) to do that, or grow your own. That last option requires a triangle wave input as well as the measured (control) voltage, but on the same site...
In a similar vein, you could use a low frequency VCO (example) and use the output to clock one of the timers, then using a second timer periodically sampling the first and reset it. The count will relate to the voltage, though not necessarily a linear relationship, linearisation could be none on the PIC or at the receiving PC - I'd go for the latter - your micro will suck at arithmetic (performance wise) - even integer arithmetic, especially if it involves division.