As a general rule, you should not use SHA1; instead, go with one of the hash functions from the SHA-2 family.
As far as truncating a hash goes, that's fine. It's explicitly endorsed by the NIST, and there are hash functions in the SHA-2 family that are simple truncated variants of their full brethren: SHA-256/224, SHA-512/224, SHA-512/256, and SHA-512/384, where SHA-$x$/$y$ denotes a full-length SHA-$x$ truncated to $y$ bits. (Technically the starting algorithm constant is different for the truncated versions, as pointed out by Henno Brandsma, but this is somewhat orthogonal to the point I'm trying to make.)
Are there any security implications for hashing and storing sensitive data like this?
As far as determining the sensitive material from the digest itself, you're safe. All secure modern-day cryptographic hashes have what is called preimage resistance, which essentially means that it is computationally infeasible to "reverse" the hash, if you will. So, your sensitive data's confidentiality won't be compromised by storing the digest. (Note: See Gordon Davisson's comment below about this; there are possible security implications in some scenarios.)
Now, the real question is: why are you wanting to store the hash in the first place? Hopefully you are not using it to detect if the data is maliciously modified; that generally is the purview of a MAC, such as HMAC or CBC-MAC.
Is it more or less secure than using the full SHA1 hash?
Much more secure, actually, if you care about collision resistance. There is an attack on SHA1 that finds collisions in 260 time, whereas truncating SHA-512 to 160 bits requires 280 time to find collisions (see the birthday attack). So, truncating one of the SHA-2 functions to 160 bits is around 220 times stronger when it comes to collision resistance. (Plus, finding collisions is now within the realm of possibility for SHA1. So, if you are reading this, and you are building a new system, you should choose SHA-2 or SHA-3.)
Is there an increased risk of hash collision when using the truncated version?
Increased risk over SHA1? No. Increased risk over using the full SHA-512 output? Yes.
Truncating the output of a hash function always decreases its (theoretical) collision-resistance. In practice, it usually doesn't matter too much; for instance, 280 time is still pretty big. Still, if you used the full output of SHA-256, the same birthday attack would take 2128 time, which is totally out of reach.
by truncating it a potential hacker wouldn't know which algorithm was used in the first place
Always assume the attacker knows everything about your algorithm/cryptosystem except for the secret keys. This is known as Kerckhoffs's principle. Why this is important is well-covered, so you should follow it.
My understanding was that SHA1 would always produce a unique value, whereas there is a chance that the first 40 characters of a SHA512 output could appear many times.
SHA1 doesn't produce unique values. There are infinitely-many possible inputs to SHA1 (it takes a bitstring of any length), yet there are only 160 bits of output. By the pigeonhole principle, there have to be infinitely-many values that map to the same 160 bits of output. In February 2017, a SHA-1 collision was published. However, there have not been any published SHA-256 collisions to date, despite that the pigeonhole principle guarantees they exist.
I should note, if you are going to use the full output of SHA1, SHA-256, or SHA-512, you should be aware of length extension attacks.
b2a, which stands for "binary to ASCII" which converts byte arrays to a hexadecimal representation. Naming things correctly is pretty important. $\endgroup$