bluerobotics / ping-firmware Goto Github PK
View Code? Open in Web Editor NEWRepository for binary files associated with ping devices
Repository for binary files associated with ping devices
Right now the sensor tries to fix in any possible distance/measure, this should be avoided, the sensor should only report distance when it has the confidence that there is a real tracking point.
We may want to report distance 0 if it's invalid.
For more information:
https://discuss.bluerobotics.com/t/ping-sonar-operating-out-of-range/7903
This functionality can break the functionality for users that want the sensor only to provide profiles.
Send 1000+ samples instead of a fixed 200
In manual mode, we should be able to control the transmit duration
Discussion in this forum thread
I’m unsure what the algorithm does when faced with a saturated signal (a peak with multiple full intensity values in a row, giving a flat top) - it may choose the first top value, or the middle one, or may use the derivatives to try to estimate where the actual top is most likely to be, or something else. Saturated signals are very difficult to calculate meaningful results from, because there’s a lot of missing data (it’s like looking at a photo of a mountain, but the top is cropped off - how can you tell where the peak is?).
... 100% confidence doesn’t seem very logical when a peak is effectively impossible to find in a region of saturated data ...
On 3.26, sending a request (id 6) with a requested id for profile (1300), the response is a NACK with a message: 'bad continuous request id`.
The expected result is to receive a profile message and no nack.
Here is a saelae capture demonstrating the exchange:
example.zip
When using the auto gain feature the incoming ping stream becomes quite jerky, and and the maximum data rate slows significantly. Ideally auto gain would consume negligible time, especially when the return confidence is high - if it's getting a strong response then it's unlikely it would need to change anything.
As some numbers, on my desk the received data with auto mode on is at ~2kB/s, and manual mode with exactly the same setup is at ~6kB/s. Some amount of slowdown may be reasonable, but a 3x performance hit is quite unexpected, particularly given the confidence is at 100% so the scan range is barely changing. This seems likely to be a bug.
Update to be compliant with the new revision of the common messages
The message format includes fields for receiver and sender IDs, but using them is documented as "not currently implemented", and they just get hardcoded to 0.
This is a valuable feature for people wanting to communicate with multiple devices on the same bus, as raised in this forum thread.
This seems conceptually straightforward to implement, with a msg.dst_device_id in (0, 255, self.device_id)
check in the receiving code, and including the sender ID if there is one set, although full support would require also updating Ping Viewer and the various ping libraries to make use of the feature.
It will be nice to have some way to tell the device exactly when to transmit, and to be able to operate several devices in synchronization to prevent interference.
This is not necessary and can result in problems when people use ping as a pure profile sensor.
Currently the ping_number
field is left at 0 for get_distance
, and is set to the request number for get_profile
, whereas the docs say it's the pulse/measurement count, which should continue counting even while no messages are being requested.
EDIT: re-tested with
Ping-V3.29.0_auto
and the number seems to be correct, just not currently set in thedistance
messages. Not sure whether I originally tested an earlier firmware version, or if I was just mistaken about it being set to the request number 🤷♂️
This seems like it should be quite straightforward to implement with a global count variable that's incremented whenever the device pings, and gets accessed when packing the messages that send it.
Issue raised in this forum post, and I've verified (using ping-python) both the "count profile requests instead of pings" behaviour and that the distance.ping_number
field is consistently returned as 0 values.
Things like state at boot, request logic, manual vs auto mode, continuous output etc.
It is known that the recently launched STM32 has supported the baud rate self-control capability, considering adding corresponding items in the protocol.
You can wait for a specific frame after opening.
The function is restarted after successive frame errors.
According to the requirement of the first data enabled by stm32, we can consider adding a specific character header, which will be automatically ignored in the original protocol.
The convention will be that the default device id matches the DEVICE TYPE.
Some strings are returned without a null termintator.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.