SHA3 hexadecimal paddig odd length string
The bid padding of KECCAK family
Actually, the padding is defined bit based in section 5.2 for the general case;
Algorithm 9: pad10*1(x, m)

Input:
positive integer x;
non-negative integer m.

Output:
string P such that m + len(P) is a positive multiple of x.

Steps:
    1. Let j = (– m – 2) mod x.
    2. Return P = 1 || 0^j|| 1.

and also noted as
Therefore this at least a 2-bit padding. If the message size $m \bmod r = \{0,-1\}$ then a new block will be required.
The $x$ is set as $x = r (rate)$

The suffix and padding for $\operatorname{SHA3-224}$
The Keccak uses domain separation for SHA3, rawShake, and Shake series. For SHA3-x the message is first suffixed with 01 then the padding is applied (section 6.1);
$$M||\underbrace{01}_{suffix}||\underbrace{10^*1}_{padding bits}$$
$$\operatorname{SHA3-224}(M) = \operatorname{KECCAK}[448] (M || 01, 224);$$
In this case, the minimum added bits is 4, 2 from the suffix, and at least 2 from the padding.
byte padding fix for odd hex numbered messages.

but to do a bit of padding I first need to convert the input from hex to binary. To do so I could use Algorithm 10 in section B1 but this works only with hex string of even length so it cannot be used so that's why I'm asking for detail about the hex padding

Since the encoding trans $\texttt{abc||060*80}$ to $[80\ ..\ 00\ 06\ c0\ ab]$ the obvious solutions is using $\texttt{ab6c||0*80}$ and this will be translate to $[80\ ..\ 00\ 00\ 6c\ ab]$ as required.
The confusion come from the fact that the NIST defines the message as

message A bit string of any length that is the input to a SHA-3 function.

So the bit padding is naturally applied to a bit string. For the hex valued string, it must be converted Algorithm 10: h2b(H, n) but the document implicitly defines the byte padding as before the conversion. after the conversion it is still the bit padding.

Note: the $\phantom{a}^*$ represents the Kleene star simply means zero or more.