New week, new Rust! What are you folks up to?
Last week I translated Rust 1.29 announcement to Russian and worked on Zemeroth game.
Changed the summoning algorithm to prefer imp types that are under-presented on the map, not just random ones. Seems to work fine now - even with increased summon rate imp types are balanced in count:
https://i.imgur.com/XMdbs13.png
Recorded a tiny playtest where a lot of bad decisions are demonstrated on the first three turns: Zemeroth (2018.09.11) Playtest - YouTube
Implementing basic armor atm.
Each armor point deflects one damage point. Some weapons can break armor and fire/poison/etc ignore armor.
This week Iām hoping to implement a basic campaign menu, improve on hit-chance math and replace colored dots with sticks/triangles of different forms to improve the colour accessibility.
6 Likes
Still working on Rust support for the DW1000/DWM1001 hardware. I managed to send a message between two DWM1001 modules this morning! (actually, I might have already done that last week, but wasn't able to verify until today)
Next, I need to find out why receiving data puts the hardware in a state where it can't receive again, and fix that.
I was traveling the first part of last week and never ended up posting, however I did finally release uom (type-safe zero-cost dimensional analysis) v0.20.0 which includes the long discussed thermodynamic temperature vs. temperature interval implementations as well as some feature hygiene fixes in macro generated code. This most recent weekend I release v0.20.1 in order to fix breakage introduced in #52841 that changes macro path lookup in nightly. Coming up I think my plan is to review documentation.
2 Likes
Travelling most of this week, so low-effort maintenance and writing a few blog posts.
I've released a simple crate for creating network bridges in Rust last week, and there's a lot of small improvements on my todo list that I'll add while I'm on a plane.
Hi Hannobraun,
I intend to employ two DWM1001 kev kits, each of which connecting to a raspberry pi 2, for data transmission through UWB.
I have checked all API functions, and found that there is no function allowing us to transmit data between two DWM1001 kits.
I read your comment, and wonder how you can do that.
Would you please show me the way.
I would like to thank you so much in advance.
Bests,
Ryan.
Hey Ryan,
using my driver, there are two ways to interact with the DW1000. You can use the low-level API, but that exposes the register interface directly, which is tedious and error-prone. Therefore the high-level API exists, which has relatively simple send and receive methods.
There are a number of examples in the repository of the DWM1001 board support crate. dw1000_only_rx and dw1000_only_tx are the simplest ones that are sending and receiving data, but the ranging examples might also be of interest to you.
However, it's not clear to me if that's what you actually need. Currently, all of this assumes that you're running your program on the nRF52832 microcontroller on the DWM1001. I'll soon start working on making the DW1000 driver independent of the nRF52832, so it can be used with any platform that implements the embedded-hal traits that are required. However, that still assumes you're running on something that's connected to the DW1000 directly via SPI.
You say you're using two DWM1001s each connected to a Raspberry Pi, which makes me think you want to reproduce a scenario you read about in Decawave's documentation. However, that assumes Decawave's official firmware is running on the DWM1001's nRF52832, and you're using the Raspberry Pi to communicate via UART or something (not sure, I think there are multiple ways to connect to the firmware from outside). This is a completely different use case that my crates don't cover.
It's hard to recommend something without knowing more about your situation, but in general you have the following options (as far as I can see):
- Don't use the Raspberry Pis and run your program on the DWM1001 directly, using my crates.
- Leave Decawave's official firmware on the DWM1001 and talk to it from the Raspberry Pi. You would either need to do this in C/C++, or figure out how to use Decawave's API from Rust. I know nothing about this API, so I can't help here.
- Use the Raspberry Pi to run your main program, but instead of talking to Decawave's firmware, replace it with your own firmware, using my crates. If you want to use UART for communication, you'd need to use the API from nrf52-hal.
Hope this helps,
Hanno
Hi Hanno,
Thank you so much for your response and advice. And, sorry that I am out of the work these two days so that I could not reply you sooner.
I would like to clear what I intend to do.
- I have two DWM1001-Dev kits and two raspberry pi 2 mode B. Each DWM1001-dev kit connecting to a Raspberry through the SPI interface (26 pins). One intergration (DWM1001-kev + raspberry) will perform as TRANSMITTER and the other works as RECEIVER.
- At the transmitter, I would like to run python code on Raspberry to send the data to DWM1001-kev for transmission over the UWB.
- At the receiver, a python code is also run on Raspberry to read the received data from DWM1001-kev.
I found that your driver and the examples you show me are very interested. I will follow them and learn how they can work with my project. I will let youo know the process.
Again, I appreciate your helps a lot.
Bests,
Ryan,
1 Like