Calculate New Pitch and Roll after Z Offset - geometry

I have a subsea sensor which is pole mounted and rigidly attached to the side of a boat. The sensor reports pitch, roll and magnetic heading information with respect to an alignment mark on the front of the sensor.
Unfortunately, we are finding that the heading reading is inaccurate and often disturbed by local magnetic interference so we have decided to use a much more accurate heading source provided by the boat.
We would still like to make use of the pitch and roll values from the subsea sensor though.
The problem I foresee is that our subsea sensors "zero" alignment mark may often not align with the "zero" alignment mark of the vessel. It may be that the sensor is mounted 90 degrees offset from the front of the vessel therefore I believe that somehow, I need to use this offset to recalculate a new pitch/roll with respect to the vessels frame.
One issue I have - which could be considered quite big - is that I have absolutely no idea where to start. Whether what I think I need to do is actually correct and if so, I couldn't even think about where to begin.
Does this even make sense to anyone? If so, I'd greatly appreciate some pointers.

Related

Detecting damaged car parts

I am trying to build a system that on providing an image of a car can assess the damage percentage of it and also find out which parts are damaged in the car.
Is there any possible way to do this using Python and open-cv or tensorflow ?
The GitHub repositories I found that were relevant to my work are these
https://github.com/VakhoQ/damage-car-detector/tree/master/DamageCarDetector
https://github.com/neokt/car-damage-detective
But what they provide is a qualitative output( like they say the car damage is high or low), I wanted to print out a quantitative output( percentage of damage ) along with the individual part names which are damaged
Is this possible ?
If so please help me out.
Thank you.
To extend the good answers given by #yves-daoust: It is not a trivial task and you should not try to do it at once with one single approach.
You should question yourself how a human with a comparable task, i.e. say an expert who reviews these cars after a leasing contract, proceeds with this. Then you have to formulate requirements and also restrictions for your system.
For instance, an expert first checks for any visual occurences and rates these, then they may check technical issues which may well be hidden from optical sensors (i.e. if the car is drivable, driving a round and estimate if the engine is running smoothly, the steering geometry is aligned (i.e. if the car manages to stay in line), if there are any minor vibrations which should not be there and so on) and they may also apply force (trying to manually shake the wheels to check if the bearings are ok).
If you define your measurement system as restricted to just a normal camera sensor, you are somewhat limited within to what extend your system is able to deliver.
If you just want to spot cosmetic damages, i.e. classification of scratches in paint and rims, I'd say a state of the art machine vision application should be able to help you to some extent:
First you'd need to detect the scratches. Bear in mind that visibility of scratches, especially in the field with changing conditions (sunlight) may be a very hard to impossible task for a cheap sensor. I.e. to cope with reflections a system might need to make use of polarizing filters, special effect paints may interfere with your optical system in a way you are not able to spot anything.
Secondly, after you detect the position and dimension of these scratches in the camera coordinates, you need to transform them into real world coordinates for getting to know the real dimensions of these scratches. It would also be of great use to know the exact location of the scratch on the car (which would require a digital twin of the car - which is not to be trivially done anymore).
After determining the extent of the scratch and its position on the car, you need to apply a cost model. Because some car parts are easily fixable, say a scratch in the bumper, just respray the bumper, but scratch in the C-Pillar easily is a repaint for the whole back quarter if it should not be noticeable anymore.
Same goes with bigger scratches / cracks: The optical detection model needs to be able to distinguish between scratches and cracks (which is very hard to do, just by looking at it) and then the cost model can infer the cost i.e. if a bumper needs just respray or needs complete replacement (because it is cracked and not just scratched). This cost model may seem to be easy but bear in mind this needs to be adopted to every car you "scan". Because one cheap damage for the one car body might be a very hard to fix damage for a different car body. I'd say this might even be harder than to spot the inital scratches because you'd need to obtain the construction plans/repair part lists (the repair handbooks / repair part lists are mostly accessible if you are a registered mechanic but they might cost licensing fees) of any vehicle you want to quote.
You see, this is a very complex problem which is composed of multiple hard sub-problems. The easiest or probably the best way to do this would be to do a bottom up approach, i.e. starting with a simple "scratch detector" which just spots scratches in paint. Then go from there and you easily see what is possible and what is not

Calculate distance to RFID tag?

Is there a way to calculate/estimate the physical distance to a long-distance passive RFID tag when reading it with a tag reader? E.g. to determine the order of books in a shelf, or telling if one object is close or far away.
If the answer is 'No - not according to the standard', would it be possible to build a reader with this feature? (I guess the only way to achieve this would be to measure the time between call and response very precisely).
It is possible, but to what extent end precision depends on a lot of factors: reader and tag performance, the quality of the software and the resources you are willing to invest in such a software (both time and people in R&D).
There are mainly two ways this can be achieved: The first one relies on getting the RSSI, which is basically the signal strength. The main difficulty using this indicator is that signal strength depends on a lot of factors that can influence it like, reflections if the signal needs to pass a wood cabinet or a wall, the quality of the tag, etc.
The second one is use the time the response is received to an enquiry (Time Differece of Arrival between tags). Given that you know the speed of the beam you can estimate the distance given a very precise timer. The problem here is that this also is influenced by a lot of factors: the mean time the tag needs to complete a cycle (which you should know, and should be the same for every tag used), the timer precision which is not built precisely for these purposes.
Naturally a combination of both should be employed for maximum precission and both are actually used by companies that rely on these algorithms to provide RTLS (Real Time Location Systems) application through Triangulation and Trilateration.
For further information you can check: RTLS, RSSI, TDOA, Trilateration (and Multilateration).
It is possible. As far as I know the company below (I'm not working there, I just happen to know someone who worked there a year before):
http://www.lambda4.com/
is working on such a technology.
It may not be possible if you have a single reader; however if you have multiple receivers and reasonably clear lines of sight , "estimating" the distance becomes possible by looking at signal strengths. It's not trivial though, since the power radiated by a RFID tag is not isotropic (I.e. not uniform in all directions) due to the antenna design; if you have three receivers and a uniform source of RF, you can solve for the distance, but when you add in the antenna pattern and other factors like signal path attenuation and multiparty, it becomes really hard - especially when there are multiple devices in the vicinity.
This is at least in part because the RFID was not designed with an output pattern that helps optimize localization, such as a frequency chirp, short power bursts, or other modulation features that allow estimating the time of flight of the signal from source to receiver and back.
General equation to find distance to RFID tag is Ploss = 20⋅log[
(4 π ⋅ d)
/λ]
In case of UHF RFID, the equation to find the gap or distance to passive tag from the reader is
Pgap = 22.6(dB)+ Patt, where 22.6dB is the power for near field(λ =c/f ≈ 35cm), where f is frequency operated, Patt is the magnitude of POWER ATTENUATOR
22.6+Patt = 20⋅log[(4 π ⋅ d)/λ],
In free space, by using the above equation, the approximate distance to RFID tag may be acheived..

Do I need to worry about the overall audio gain in my program?

Is there level limiting somewhere in the digital audio chain?
I'm working on a tower defence game with OpenAL, and there will be many towers firing at the same time, all using the same sound effect (at least for now). My concern is that triggering too many sounds at the same time could lead to speakers being blown, or at the very least a headache for the user.
It seems to me that there should be a level limiter either in software, or at the sound card hardware level to prevent fools like me from doing this.
Can anyone confirm this, and if so, tell me where this limiter exists? Thanks!
as it is, you'd be lucky if the signal were simply clipped in the software before it hit the DAC. you can easily implement this yourself. when i say 'clipped', i mean that amplitudes that exceed the maximum are set to the maximum, rather than allowed to overflow, wrap, or other less unpleasant results. clipping at this stage often sounds terrible, but the alternatives i mentioned sound worse.
there's actually a big consideration to account for in this regard: are you rendering in float or int? if int, what is your headroom? with int, you could clip or overflow at practically any stage. with floating point, that will only happen as a serious design flaw. of course, you'll often eventually have to convert to int, when interfacing with the DAC/hardware. the DAC will limit the output because it handles signals within very specific limits. at worst, this will be the equivalent of (sampled) white noise at 0 dB FS (which can be an awful experience for the user). so... the DAC serves as a limiter, although this stage only makes it significantly less probable that a signal will cause hearing or equipment damage.
at any rate, you can easily avoid this, and i recommend you do it yourself, since you're directly in control of the number of sounds and their amplitude. at worst, samples with peaks of 0 dB FS will all converge at the same sample and you'll need to multiply signal (the sum of shots) by the reciprocal of the sum of shots:
output[i] = numShots > 1 ? allThoseShots[i]*(1.0/numShots) : allThoseShots[i];
that's not ideal in many cases (because there will be an exaggerated ducking sound). so you should actually introduce a limiter in addition to overall reduction for the number of simultaneous shots. then you back off the shots signal by a lower factor since their peaks will not likely converge at the same point in time. a simple limiter with ~10 ms of lookahead should prevent you from doing something awful. it would also be a good idea to detect heavy limiting in debug mode, this catches upstream design issues.
in any case, you should definitely consider appropriate gain compensation your responsibility - you never want to clip the output dac. in fact, you want to leave some headroom (ref: intersample peaks).

how to calculate geographical coordinates / which geo system is this?

I have a pair of geo coordinates I don't understand. Does anybody know this coordinate system and how to translate them to longitude and latitude in degrees?
Long. 7662.251 West, Lat. 9144.590 North
Has to be a position in Honduras (13- 16°N and 83-89° W)
You really need to investigate the source of the data, files, print outs, local gandolphs etc. Even if someone can find something with a stab in the dark it's likely to be wrong in some tiny detail. Where did the pair of coordinates come from? A text file? An email? Were there any auxiliary files? With the same file name, but different extension? In the same folder? Attached to the email? Who gave it to you? What sort of computer do they use? Are they alive? Etc.
There's simply not enough information in this question to answer it - tell us at least how you know that they are "geo coordinates" - how do you know that they must be in the Honduras?
Unfortunately this level of cultural metadata is quite often about the best we have. As a massive stab in the dark they might be projected coordinates in km, rather than metres - but they could be in feet - or anything, there's really only educated guesses that can improve on this as it stands.
If it's not one of the common ones, such as UTM, have a search on the epsg registry for coordinate systems for Honduras:
http://www.epsg-registry.org/
and see if any work out. Would be a lot easier if you have any more coordinate pairs that are also in Honduras, because then we can work out an approximate scale.
I'll have a play and see if one of the UTM zones works out...

Audio normalization/fixation?

I am using some audio fingerprinting technique to mark songs in long recordings. For example, in radio show records. Fingerprinting mechanism works fine but i have a problem with normalization (or downsampling).
Here you can see two same songs but different waveforms. I know i should make some DC Offset fixation and use some high and low gain filters. I already do them by Sox using highpass 1015 and lowpass 1015. And i use wavegain to fix the volume and DC Offset. But in this case wave forms turns to one like below:
But even in this case, i can't get the same fingerprint. (I am not expecting %100 same but at least %50 would be good)
So. What do you think? What can i do to fix records to have same fingerprints? Maybe some audio filtering would work but i don't know which one to use? Can you help me?
By the way, here is the explanation of fingerprinting technique.
http://wiki.musicbrainz.org/Future_Proof_Fingerprint
http://wiki.musicbrainz.org/Future_Proof_Fingerprint_Function
Your input waveforms appear to be clipping, so no amount of filtering is going to result in a meaningful "fingerprint". Make sure you collect valid input samples that have a reasonable dynamic range but which do not clip.

Resources