PAST - Monthly Developer Q&A: October Edition [Oct 18th, Virtual]

Community Events
1

Hey there everyone. Please join us for a virtual Q&A session with the Bristlemouth core development team. We’ll be quickly covering the state of Bristlemouth, what’s coming up next, and plenty of time for questions.

Who: @zack_j @zachary @spiderkeys @evan

Where: virtual-- register below

When: Oct. 18th at 10:30am PDT

Notes:

  • A recording will be posted on the event site afterwards.
  • If you can’t make it but have a burning question, reply here and we’ll try to cover it.

See you there!
~Zack

2

Hi All, really enjoyed the first Q&A, thank you for your initiative, pity about the comms gremlins!

Following my question regarding non-ASCII payloads, do you have any examples or sample code that can shed some light on transmitting binary data over the Bristlemouth protocol?

Thanks!

3

Hi there everyone. Thanks so much for joining us for the first community update / dev. Q&A.

Sorry we all got kicked out by zoom right at 11, but we were able to record the whole session and add in a reply to the last question that we missed.

Recording:

Minutes:

** Q: I just got my Pioneer hardware. How do I get started?
** A: A good place to start is the dev kit onboarding guides.

** Q: Where can I get started if I want to start getting familiar with the programming?
** A: Start posting on Projects or Pioneer Program and let folks know what you’re working on and ask for some advice on approach.
** A: Separate the whole effort into smaller bite-size parts. E.g. getting data from a sensor, parsing data, sending data to the SD card, getting the right power set.

** Q: Any support for Windows and/or Linux [for the onboarding guides]?
** A: Windows will be a while. Linux is likely to be sooner, no concrete dates but we’re going to try to get this slotted in pronto. [Let me also add, that if you know your way around Linux really well you can likely do most of what’s there now.]

** Q: Does the Brisltemouth Standard allow non-ASCII data transmission.
** A: Yes. Check out the post here for an active area of development on this subject. Familiarity/comfort with ROS IDL and protobuf.

** Q: You mentioned an Arduino integration, what about RasPi?
** A: Yep. We want to be as universal as possible.

** Q: Where can I get started with specific water quality sensors?
** A: Multiparameter sondes are the state of the art. They are very expensive. It may be better to start with something as a proxy or proof of concept. Maybe from Atlas Scientific or Sparkfun.

Thank you very much to everyone who was able to join us on the panel or as a guest. See you at BristleCon!

~Zack

4

Hey @AndreH! Thanks for joining and for the great question! I’m sure you’re not the only one wondering about this.

As I mentioned in the session, any data may be sent over Bristlemouth. The simplest way is to call bm_pub to publish data to a topic.

bm_pub is defined here: https://github.com/bristlemouth/bm_protocol/blob/7c53bf76c685a6e7fa7841f64044eb067565f678/src/lib/middleware/bm_pubsub.cpp#L258

An example of usage is here in the bridge app: https://github.com/bristlemouth/bm_protocol/blob/7c53bf76c685a6e7fa7841f64044eb067565f678/src/apps/bridge/app_main.cpp#L191-L202

As you can see there, the 2nd and 3rd parameters are a buffer of data and the length of that data. There are no restrictions on the content of the buffer.

In order to receive the data elsewhere, you’ll have another node calling bm_sub to subscribe to a topic. You provide a callback to bm_sub that will get called by the system when any messages arrive for that topic.

Hope that helps! And of course ask if anything’s unclear.

5

Perfect, thank you @zachary.

Looks like we can have payloads of up to ~65k, looking at the bm_pub function.

bool bm_pub(const char *topic, const void *data, uint16_t len, uint8_t type, uint8_t version)

Looking forward to getting our hands on hardware to understand the data flow from sensor, via Spotter to shore and back through the API.

6

Hi @AndreH , thanks for participating in the Q&A!

The maximum message payload is currently a bit under 1500 bytes:

#define MAX_PAYLOAD_LEN (1500 - sizeof(struct ip6_hdr) - sizeof(struct udp_hdr))
See src/lib/middleware/middleware.cpp for more details on the interface between messaging middleware and network layer.

This is constrained by the MTU of the 10Base-T1L PHY. We have a roadmap item captured to implement mult-packet support in the network layer and make the message interface to middleware clients transport-agnostic. (But we can’t promise specific timing on that feature yet).

If you want to get a sense of the end-to-end data flow from sensor through web API, you can read through Getting Started Guide 5 ahead of receiving your hardware: [Bristlemouth Dev Kit Guide 5: Developing a Simple Application]

Please keep the questions and suggestions coming, thanks!

1 Like
7

Thank you @evan

I’m used to stuffing an unreasonable amount of information into a 340 byte SBD packet, so this is plenty.

I saw your awesome Dolphin detector here https://www.youtube.com/watch?v=0na4KuwRi0g

What is the state of the Python support and documentation?

Thanks!

1 Like
8

Hi @AndreH — thanks for asking :slight_smile:

The proof-of-concept MicroPython support worked as of my last testing, which was performed on version v0.3.0. We don’t have a timeline for fully supporting this yet.

It is possible to build MicroPython into a Bristlemouth app. This includes a REPL and some initial platform support. The necessary information is currently in the commit log. I will reference the specific commits below.

The three necessary steps, from my experience, are:

  1. add -DUSE_MICROPYTHON=1 to your cmake invocation
  2. depending on your build platform, you may need to follow the instructions in the ENV_SETUP.md here
  3. for effective use of the REPL via the USB serial console, decrease the frequency at which the onboard sensors are being sampled and printed to the console. Instructions here. Perhaps 10 seconds is appropriate.

Please let us know if you have any further questions!

commit fc657c6ff0de3ec3246ff5d48728102956a3906c - how to build 
Adding VERY basic micropython support! (#273)

* Adding VERY basic micropython support!

Added it to bridge app when cmake flag of `-DUSE_MICROPYTHON=1` is used.

To test, build bridge app with `-DUSE_MICROPYTHON=1`, connect to pyserial-miniterm with `--raw` argument and run the `repl` command :D

* Add micropython to ci 🤦‍♂️

* Fix ms delay

Co-authored-by: Russell DeGuzman
commit 36de147c1706705f8fd7d33bef9d969590cf2157 - adds device info 
Add our very first micropython module! aka `device` (#275)

* Use micropython heap size from CMakeLists.txt

* Make sure `make clean` removes generated micropython stuff

* Move APP_NAME define lower (so we can include in APP_DEFINES and MICROPY_DEFINES)

* Add our very first module! aka `device`

Example:

    repl
    Starting REPL
    MicroPython v1.20.0-dirty on 2023-05-24; minimal with stm32u5xx
    >>> import device
    >>> device.info()
    {'fwversion': 'ENG-v0.0.2-206-g17ca74d6-dirty+62eb26d8', 'app': 'bridge-dbg', 'GITSHA': '17CA74D6', 'BSP': 'bridge_v1_0', 'node-id': '5940ab8908303967'}
    >>>
commit 9bba99f7b96ad179fe9c4003e06c0017b2cb9556 - bristlemouth platform support details 
Micropython Improvements (#322)

* Trying to get modules working

* Many changes!

`import time`, `time.time()` now provides the correct time and date using RTC!

We can now import and pre-compile python modules from both the micropython-lib submodule as well as custom made ones!

* Start adding `machine` module

* Adding _very_ basic I2C support in micropython

Disabled -Werror for micropython 😭

Example use of i2c in micropython

    repl
    Starting REPL
    MicroPython v1.20.0 on 2023-06-12; bristlemouth with stm32u5xx
    Type "help()" for more information.
    >>> import machine
    >>> i2c = machine.I2C(1)
    TODO: Initialize with freq and timeout
    >>> i2c.scan()
    [65]
    >>> i2c.writeto(65, bytes([0x3E]))
    1
    >>> i2c.readfrom(65, 2)
    b'TI'
    >>>
3 Likes
9

Your first post is not an insignificant one! Welcome to the party @timjoh !

I think you should be on the panel for the next Community Update / Developer Q&A!

~Z

2 Likes
10

Great stuff, thank you @timjoh !

1 Like