We've successfully built the demos using the sample code available via both the Stella and Portenta shield libraries.
According to the page for the shield (Portenta UWB Shield User Manual | Arduino Documentation, we should be able to develop TDoA, AoA, as well as set a sync master for TDoA. There are no references to any of this in the TrueSense library that is provided with this board. See below:
Portenta UWB Shield Library
The PortentaUWBShield library contains an application programming interface (API) to read data from the Portenta UWB Shield and control its parameters and behavior. This library is designed to work with the DCU150 module on the shield and supports the following:
One-way ranging (Time Difference of Arrival - TDoA) and two-way ranging (TWR).
Angle of Arrival (AoA) measurement for 2D and 3D positioning.
Is this functionality on the roadmap, and if so, is there a target timeframe? If not, I'll simply return the unopened boxes as we had high hopes that this would be a straightforward implementation as with all things Arduino.
Also, for TWR, the library requires that before the anchor responds to a Stella tag, it has to have the tag's MAC address stored in the Portenta. This limits the "Pro" hardware to DIY/enthusiast level since professional commercial implementations would need to scale to hundreds of tags. We've deployed other vendors' UWB products and developed solutions using their APIs and SDKs and none of them require prior knowledge of the mobile tag's MACs in order to respond to them. Also, a scanning function would be quite helpful - it is related to the last point about not requiring the anchors to be pre-populated with tag MAC addresses.
Lasty, there are references to WGS84 and, depending on the project, we convert cartesian coordinates to WGS84 coordinates (lat/long). There's no mention of this publicly, but it is visible in the Portenta shield library. Is there a complete implementation of the use of WGS84 coordinates or conversion functions from cartesian coordinates?
Regards,
jd
hello @symtech /jd
thanks for reporting.
The TDoA demo will be ready by next week and libraries (both Tag and Shield) will be updated accordingly. It will also include a Python library that performs anchor sync and tag position triangulation.
Ref TWR and MAC addresses, I'm not sure which products you have used before but in the FiRA standard a MAC address is required. Please note how in the NearbyDemo code the MAC addresses are exchanged out of band (via BLE).
Anyway, in TDoA mode the MAC address of the tag doesn't really count much, what is really important is the fact that the tag will transmit a 64 bits unique ID (see UWBAppParamList::tdoaDeviceId) which could be derived from, for example, the boards BLE MAC address. You will see this in the updated code.
Finally, ref the usage of WGS84 coordinates, that is not intended for classic TDoA mode, that's in preparation of a further demo that implements reverse/downlink TDoA. I will come in late July.
Hope the above helps for now
Best Regards
Pier
(Author of the StellaUWB and PortentaUWBShield libraries)
@pierpaolo_lento,
Thank you for your timely response. I appreciate you addressing my questions/concerns - and I'm very pleased to know that we're going to be able to move forward with, what I consider, an excellent hardware and software stack.
You are correct about the FIRA standard - we'll be using BLE for out-of-band exchanges (such as for discovery). I also understand what you are referring to with regard to TDOA mode and the 64-bit unique ID - that makes sense.
We're looking forward to learning what the full scope of the WGS84 features will be as we are also proponents of reverse/downlink TDoA for the scalability and I believe this has the potential to add new use cases/applications to the already numerous uses of UWB.
I'm sure that I'm in good company when I say that I'm very much looking forward to the updates to the library.
Cheers,
jd
hi jd,
thanks again for your interest. I can confirm we are going ahead with TDoA examples as per the schedule.
Ref the Reverse TDOA, I agree with you about the scalability which is virtually endless but I need to point out that it also has some peculiarities:
-
the Reverse TDoA mode for now is only supported by the sr150 chips (those on the Portenta shield) but not on the SR040 (those on the Stella Tags)
-
in Reverse TDoA mode, although in listening mode only, the radio on the tag nodes is always on, which implies much higher power consumption compared to a 'traditional' TDoA tag which instead only sends blinks at regular intervals and then shuts down the radio for the rest of the time.
-
the position of the tag is calculated on the tag itself which, compared to TDoA, implies no data transfer over wifi/ethernet thus reducing latency and making it a good configuration for applications where a drone or autonomous vehicle needs to react in very short time.
-
the WGS84 metadata (or custom position metadata which is another option) is transmitted by the anchors and detected by the tag. That's how the tag can calculate its own absolute absolute position.
hope the above helps
Best Regards
Pier
Piers,
Thanks again - these points are expected (except the inability to perform reverse TDoA in the SR040 chips). This is fine, as over 50% of our use cases are for UGVs (or other self-powered vehicles) on a campus or warehouse. In those cases, we prefer to simplify the deployment and calculate the position on the rover which, as you mentioned, reduces the latency to obtain a position.
We've also used larger radios than the Portenta+shield, so the size/power are non-issues for us (in the case of UGVs). This configuration also simplifies the infrastructure configuration as we will be sending the position from the rovers to our cloud-based fleet management system where latency isn't as critical. For field-based smaller mobile deployments we typically only use TWR/AoA to for the moving vehicles to determine relative positions between themselves. This is much more accurate than performing this with GPS (and we don't want to incur the expense and overhead of RTK GPS + NTRIP). For asset management, we use TDoA as it lends itself well to this use case.
I'm truly looking forward to working with the WGS84 data. Handing lat/lon positions to customers that have existing mapping solutions helps us win those opportunities. We've had to create our own system for this for tracking trains in tunnels and areas where GPS is poor. It allowed the MTA teams a way to continue using their existing systems to track the train positions.
I'm sure you can see why the Stella/Portenta UWB products are of interest to us.
Thanks again for the timely updates,
jd
Hello,
I hope you are doing well. As per my experience i think there is support for AOA on the hardware level but the library is still not compatible with it. Could i ask when the AOA support will come to the library and if there is gonna be an code example for it. Because we are facing a similar problem and it would be really helpfully to have this feature.
Kind regards,
AT
1 Like
Hello,
Dear @pierpaolo_lento, could you please confirm that the support for AOA is coming out next week to the library plus the code example? If yes, could you please give a rough date of the new update.
Kind regards,
AT
I think you meant this to be directed to @pierpaolo_lento.
1 Like
hi,
in reality the AoA feature is already there, I didn't expose it in the demo sketches because I think it needs a bit of cosmetics.
Infact in the rangingHandler() callback you can already use something like:
twr[j].aoa_azimuth
The point is that the reported value is the raw one that needs to be translated into Q9.7 format, i.e. the integer part of the measurement is obtained by:
twr[j].aoa_azimuth >> 7
while the non integer part is obtained by:
twr[j].aoa_azimuth & 0x7F
This will give you the angle measurement.
That said, I really need to set clarify the behavior of the AoA feature:
- only azimuth angle will be measured
- angle value will be within -60.0 and +60.0 (this is the max field of view). When you exceed the field of view the value will saturate
- AoA precision depends a lot on the copolarization of the antennas on the 2 sides of the measurement. If you look closely at the sensor you will see the antennas, they look like an oval notch. The 'trick' is that the more you keep them on the same orientation, the more you get good AoA results. For example if you use the Portenta Shield in portrait orientation (which is the suggested one) to range against a Stella tag, then you better rotate the Stella around it's z-axis with the antenna pointing to the right (looking at it from the front).
Please have a try and let me know, you may also notice some offset from the real angle which is something we are optimizing.
That's all for now
Best Regards
Pier
1 Like
Hi Pier,
I've been waiting to see if there will be a demo for how to use TWR from the Stella to multiple Portenta C33 UWB modules so we can begin multilateration and TDoA. Is there an expected time frame for these APIs & demos?
Also, for our planning, will the TDoA clock master be able to also be used as an anchor in the UWB constellation?
Thanks,
jd