Yes, though it will likely require some custom programming to make an effective system. Given the short range, any Decawave based module or node should work.
Your diagram implies a decentralized system where each forklift operates independently. This means there is no central coordination of transmit times.
The simplest approach is to use an ALOHA style system, which is just a fancy way of saying the nodes transmit at periodic intervals with random jitter without any coordination between them. To always measure the only distance you want, each set of nodes must be paired by address or serial number so you only get the distance results you want. For example, each fixed node addresses only the one moving node it wants. If a node is changed, the pairing must be updated.
You could design a system where the pairing is automatic by observing which nodes respond reliably to the body node query and which nodes have sane distances. This takes a statistical approach to pairing which may temporarily fail. The consequences of that failure depend on your application.
Any sort of system based on trying to control the RF signal pattern is likely to fail. RF signals are simply too hard to confine to specific areas. This is one of the reasons Bluetooth location systems are horrible.
You will want a good clear path between the body node and the fork node. Ideally, about a 30 cm diameter cylinder of clear air between them. If the nodes are tight to the metal parts, that slows down the radio signal. This can be calibrated for, and you should probably expect to do a calibration table in general for various reasons, the nearby metal being one of them.
There is one peculiar failure mode you should be aware of, and that is wrong RX_TIME values when there is a collision. Say node A and node B transmit at almost the same time. Node C receives their signals. It can be the case that node C gets a good packet from node A, but the LDE algorithm produces an RX_TIME which is actually from node B. Thus node C thinks the RX_TIME is from node A but it isn’t, and that leads to an incorrect distance computation.
There’s no absolute way to detect this has occurred. It doesn’t happen often, it takes a very narrow set of circumstances. The best treatment is to do the measurement more often than you need and filter out results which are insane or exceed dynamic expectations.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
+1 812 962 9408