Upcoming open source package releases

[Michael Wimble]

Lots of good progress on my robot work. My robot, SIgyn, is running around the house like a bunny with a fire on its butt. I’m still fighting Wi-Fi issues, but now I’ve tracked down the root cause. More on that at the end.

---

g...@github.com:wimblerobotics/wifi_rviz.git

Not quite ready for prime time, but it’s at an alpha stage if you want to play with it.

You build it, source the install/setup.bash file before you run rviz2 in that same shell, and it adds the bar graph overlay available for anything that publishes the min/max/curr message. You can use the battery_to_minmax_publisher.py to read a BatteryState message and republish it as the min/max/curr overlay for viewing in rviz2. You can specify the min and max battery levels, and the overlay bar graph will colorize the battery voltage from red to green.

Upcoming will be the addition of the fields:

critical — a value for which the current value is considered critical. For instance, if your battery is a LiPo type, its voltage goes critical long before it nears zero.

Remember, though, that this overlay isn’t just for battery monitoring. Use it for any process parameter. For instance, I have multiple temperature sensors on my robot and current sensors.

critical_direction — lets the overlay know if the current value goes critical when it goes above or below the critical parameter value.

critical_animation — I’ll probably let you flash the overlay. Maybe I’ll allow you to do something cute like execute an arbitrary Python script, which would allow you to play a sound or send a message to your motor controller so it can turn on emergency stop. Still a thought-in-process.

title — right now, the topic name is shown below the bar graph. This would allow you to replace that with your own text.

compact — right now, the topic name is shown below the bar graph. In compact form, the topic will be shown to the left of the min value for the bar graph, reducing the height of the bar graph widget.

I may also add the ability to wrap up a bunch of bar graph widgets into a single widget that will be easily move around in the RViz2 display. I may also allow showing the widget in a side panel window, much like how a camera image is shown in RViz2, rather than just an overlay in the main RViz2 window.

—

g...@github.com:wimblerobotics/this_to_that.git

A new repository as of this afternoon. In the wifi_rviz project above, there is a custom battery_to_minmax_publisher.py node that transforms a battery reading into the message needed for the RViz2 overlay. This package is a generalization of that kind of code. It is configuration-driven. You specify an incoming topic name, message type, and outgoing topic and message type, and then a list of mappings of input fields to output fields. It also allows you to specify static fields. For instance, here is the configuration file that accomplishes what the custom code does:

config.yaml

field_mapper_node:

  ros__parameters:

    input_topic_name: /main_battery

    input_message_type: sensor_msgs/msg/BatteryState

    output_topic_name: /battery_overlay

    output_message_type: wifi_viz/msg/MinMaxCurr

    field_mappings:

      - "voltage:current"

    static_fields:

      - "min=0.0"

      - "max=45.0”

This is pre-alpha, but you’re free to clone it and play with it as it is. At the moment, it requires the input and output fields to be of the same type. It probably fails if the input is, say, an integer, and the output is, say, a float. I hope to add the ability to execute an arbitrary Python expression that takes an input message and produces the output value, allowing you to do complex conversions. To start, this will just allow me to create a lot of bar graph widgets using the wifi_rviz package (which will be renamed — I guess I forgot to say that).

—

g...@github.com:wimblerobotics/wifi_logger_visualizer.git

A heavy-lifting package. This now not only uses iwconfig to capture Wi-Fi bitrate, link quality, and signal level, but those values haven’t been particularly useful in solving my Wi-Fi issues. Now the package will also, if configured, talk to another computer (e.g., my fast desktop computer) using iperf3 to capture actual sender and receiver bit rates. The figure from iwconfig is more of a theoretical bit rate which that from iperf3 is what the actual connectivity is. The output from the package can be several things: All of the captured data is now captured as min, max, and average values as well. And you can truncate the number of digits to the right of the decimal point for the x/y location, which is helpful because the data is all captured into a SQLite3 database and chucked up by location. This especially helps in computing, say, the average sender bit rate by location which your robot roams the house, and you can chuck it by, say, location with one digit of precision to the right of the decimal place. The code now subscribes to a costmap (usually /global_costmap/costmap) so that it can mimic a costmap in size and resolution in order to be viewed as an overlay in rviz2.

• A static MatPlotLib chart showing chunky, summary results of the data captured while roaming about.
• A PNG file, captured from the MatPlotLib result.
• A costmap that can be overlayed in RViz2, mimicking the map, local costmap, and global costmap layers.
• An RViz2 overlay showing real-time data from iwconfig and iperf3.

There are lots of configuration parameters. The data logging and display get better with each release, especially the new error handling of Null values creeping into the captured data.

The current work is on the “interpolation2” branch but will be merged back into the main branch soon.  It will probably be release “1.3.x” after the merge. The README.md file is in flux. Feel free to offer comments. The topo maps have been dropped.

—

g...@github.com:wimblerobotics/ros2_roboclaw_driver.git

This is stable for the moment. I have a small list of issues to work on. This works with UART and USB communication with the RoboClaw devices. There are details on how to configure UART use using a Raspberry Pi 5 and Ubuntu 24.04. If you use it, please provide feedback and/or create new issues.

—

As always, if you like anyone’s GitHub repositories, please give a star rating on the website, pin it, watch it, and send cookie money if it’s really useful.

---

Now, about Wi-Fi

In case you didn’t know, the Nav2 stack relies on fast networking. ROS 2 solves some of the networking problems by running a lot of nodes in a single process by default, using shared memory rather than actual network calls, but that only helps when you run ROS 2 the right way and it only happens for those nodes running in the same process. Otherwise, Nav2 is very sensitive to low network bit rates. That happens in my robot when localization is attempted because my LIDAR and odom messages are send via the network to the Nav2 stack; they are not part of that same, special process.

My robot roams my house. My house has 4 Google Nest Wifi Pro repeaters which typically provide multi-hundreds of mega bits per second of connectivity. But Linux gets in the way, much to my surprise.

When I walk around my house with my iPhone, as I go from room to room, my iPhone happily reconnects to the nearest mesh repeater, and I can easily transfer gigabytes of data in short periods of time. But Linux doesn’t work that way by default. In Linux, the default setup attaches to a Wi-Fi repeater when it first brings up the networking stack, and it won’t reconnect to a faster node unless the signal gets weak. Really weak. I mean near the thermal background noise weak.

The result is that if my robot moves from one end of the house where it started, next to a mesh repeater, and moves to the other end of the house, resulting in multiple layers of aluminum blinds standing between the two locations, the Wi-Fi rate goes way down, from hundreds of mega bits per second to about 1 mega bit per second. And ROS 2 localization goes out the window. It struggles as the robot moves too far between points where it gets odom and LIDAR messages for the algorithm to work well.

I’ve done some research into the issue, and there was a suggestion of turning off the NetworkManager daemon and using wpa_supplicant to manage the Wi-Fi. Which seems to also make any simultaneous Ethernet connection not work as expected. But, I haven’t successfully even gotten the wpa_supplicant service to do the rescan correctly. It may be that I haven’t correctly configured everything, I’m not sure. But it requires a connected terminal and keyboard to fix things when they go bad in this mode, and I don’t have an ATV in my house that is small enough for me to follow along by my robot, with a long tether so I don’t pollute the local costmap, to deal with analyzing and attempting fixes to the networking stack.

I did get an AI suggestion to create a monitoring node on the actual bitrate and force a network rescan, and that’s next up to try. But, this is a Public Service Announcement of an issue you might want to be aware of.

If you think you actually understand the problem at a modest technical level, understand the network stack for Ubuntu 24.04 and the issues of the default Wi-Fi drivers, and have a tested solution, there’s a cool $20 American in it for you.

[Marco Walther]

On 4/21/25 15:25, Michael Wimble wrote:
...

> *---*
> *Now, about Wi-Fi*

First off, I don't have your Google Multi-AP setup, so I don't know,
what they actually expect. Everybody calls those things mesh networks,
but they are not really meshes at all. They are multiple APs, with some
wired or wireless back haul, and the clients roam between them. Much
like your mobile phone roams between the cell towers. Neither your cell
phone nor your laptop or robot help in providing connectivity to others
nodes in the network. But if they follow the standard 802.11r [fast]
roaming, NM should be able to do it.

One link, I found with some real details
https://lists.gnome.org/archives/networkmanager-list/2022-October/msg00024.html

My NM sets
Apr 21 18:12:39 feather7 NetworkManager[74207]: <info>
[1745284359.9844] Config: added 'ssid' value 'mw_ax11k'
Apr 21 18:12:39 feather7 NetworkManager[74207]: <info>
[1745284359.9844] Config: added 'scan_ssid' value '1'
Apr 21 18:12:39 feather7 NetworkManager[74207]: <info>
[1745284359.9845] Config: added 'bgscan' value 'simple:30:-65:300'
Apr 21 18:12:39 feather7 NetworkManager[74207]: <info>
[1745284359.9845] Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256
FT-PSK SAE FT-SAE'
Apr 21 18:12:39 feather7 NetworkManager[74207]: <info>
[1745284359.9845] Config: added 'psk' value '<hidden>'

For Ubuntu 24.04, the setup is really strange

NetPlan seems to be the 'real config'
that delegates some/all configurations to NetworkManager
that delegates WiFI handling to wpa_suplicant

Not sure, if that helps any
-- Marco

[Charles de Montaigu]

Micheal,

Have you try to switch des provider? Zenoh stack and the  rmw_zenoh ? Now replacing micro ros is more of a heavy lift and untested check out rmw_zenoh_pico could be a solution ...

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/8618C0BC-AC01-4AF1-B636-124445FA81D1%40gmail.com.

[Michael Wimble]

On Apr 22, 2025, at 8:23 AM, Charles de Montaigu <c.demo...@gmail.com> wrote:

Micheal,

Have you try to switch des provider? Zenoh stack and the  rmw_zenoh ? Now replacing micro ros is more of a heavy lift and untested check out rmw_zenoh_pico could be a solution …

I will eventually look at Zenoh. My specific problem, though, I’m pretty sure is a Linux Wifi driver issue and not related to DDS. But thanks for the suggestion. Keep ‘em coming.

[Sampsa Ranta]

My 50 cents,

As potential point of interest, it is also possible to monitor wireless traffic on lower levels with tcpdump for example. You might be able monitor the network without rescanning.

https://jasonmurray.org/posts/2021/monitorwireless/

For internet, sticky client seems to be common, not sure what is the recipe. But would be interesting to hear if you find it.

https://superuser.com/questions/1770394/how-to-get-my-linux-wi-fi-to-reliably-roam-from-ap-to-ap

And in Linux, wifi drivers vary from vendor to vendor.. Here is example from OP,

https://www.reddit.com/r/linuxquestions/comments/yw1o0e/fast_roaming_80211r_not_working_dead_on_linux/

Emphasis on this part,

"from device/client wpa_supplicant, it says:

FT: failed to set PTK to driver."

-> Running wpa_supplicant with debug might show you something.

If you feel like more networker, it is also possible to see what the client and AP(s) talk. This link is not directly solution for you but might give you hints what the traffic might look,

https://mrncciew.com/2014/09/06/cwsp-802-11r-ft-association/

- Sampsa

--

[Steven P]

I don't understand how you've got the nodes in your project split up. But with respect to optimizing Wi-Fi:

NetworkManager under the hood runs wpa_supplicant to manage WiFi connects. The default is likely something like if the signal goes below a certain threshold, it will start scanning for more access points. It may be using wpa_supplicant's "bgscan" for this. The RSSI threshold is configurable, but I don't know if NetworkManager lets you configure it.

If you take control of it manually with wpa_supplicant, or NetworkManager lets you configure the channels it scans on, you should be able to cut down the channels it scans for to just the channels that your 4 APs exist on. Each channel it scans will add ~100-150ms to the scan, and there are a ton of 5GHz channels especially. This is probably the biggest optimization you can make. Also pay attention to what channel you're connecting to, as 2.4GHz goes through walls better but there are only 3 non-overlapping channels. Everybody and their brother likes to use this band for random RF stuff because it's the ISM band. Whereas 5GHz has less penetration but it has closer to 20 channels and many of them are fairly restricted to WiFi/5G or occasionally some kind of radar (see DFS channels).

As long as your APs are configured to do fast transitions in accordance with 802.11r, it should only take a couple RTT exchanges for the device to switch. macOS was one of the pioneers of assuming the DHCP lease based on the MAC address of the AP, but I believe at least some of Linux's mainstream DHCP clients have this optimization as well. You can check this with Wireshark, or you can use tcpdump -w to capture a file on the command line you can view with wireshark.

You can selectively disable NetworkManager for a single wifi interface and let it continue to manage ethernet interfaces on the system with nmcli. Alternatively, if you can enable systemd-networkd on Ubuntu, you can let it run in place of NetworkManager to run DHCP on interfaces when they come up. This doesn't offer a pretty GUI, but systemd-networkd was originally optimized to bring up headless containers ASAP, so I have more confidence in it being aggressive about DHCP than whatever DHCP client NetworkManager is using right now.

https://wiki.archlinux.org/title/Systemd-networkd#Configuration_examples

Note that you really don't want to have it scanning all the time, or else the scans themselves will be tying up the radio and will artificially reduce the bandwidth.

You can use "iw event" to get some insight into what the wifi adapter is up to.

- Steven