network-config had my SSID and a hash (didn’t confirm it was correct, but I am sure the password was correct in the Rasp. Pi config tool). But the robot never showed up on my router dashboard.
I’m going to have to attach a monitor and keyboard to troubleshoot. I’ve got houseguests coming in today for the weekend, so likely next week before I can touch this again.
/K
10/22: Where I am in testing: “Seeing the bleeding edge”
My ROSbot Dave was (and is still) fully working on ROS2 Foxy/Ubuntu 20.04 Focal.
ROS2 Foxy is supported only until November of 2023, (Focal till 2025).
Thus for my “ROS2 on GoPiGo3 Image”, I chose the latest “long term support” release
Of course the continually progressing ROS2 and Ubuntu are built upon a million moving parts such as languages, compilers, and coding conventions.
So keeping a robot afloat on this fast moving deep river can be a challenge.
Status:
/home/ubuntu/ydlidar_ros2_ws/src/ydlidar_ros2_driver/src/ydlidar_ros2_driver_node.cpp:44:26: error: no matching function for call to ‘rclcpp::Node::declare_parameter(const char [5])’
44 | node->declare_parameter("port");
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
/opt/ros/humble/include/rclcpp/rclcpp/node.hpp:421:3: note: template argument deduction/substitution failed:
/home/ubuntu/ydlidar_ros2_driver/src/ydlidar_ros2_driver_node.cpp:44:26: note: candidate expects 4 arguments, 1 provided
44 | node->declare_parameter("port");
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
It appears the YDLIDAR folk have not revisited their ROS2 driver since getting it to work on Foxy.
We have to solve configuring the networking for this to be useful.
This brings ROS2HH
to the equivalent of ROSbot Dave which was
Except I have not figured out how to get my old ROS2 Foxy Desktop virtual machine to hear the ROS2HH topics so that I can run rviz2 and see what ROS2HH is seeing.
So…
Usually the slam-toolbox, mapping and localization are executed off-board, so this may be real wishful thinking on my part.
$4 Grove ultrasonic ranger for mapping, with only encoders for localization?
(Really low cost ROS2 GoPiGo3: $129 GoPiGo3, $80 RPi, $4 Grove Ultrasonic Range sensor)
I am sure the localization will be only close until the first turn, but it will be interesting to know how bad is “don’t expect much”
All runable nodes throw “rcl_shutdown already called” error when terminated with no ill effect
ros2_gopigo3_node: appears to be fully working
imu_sensor_node: appears to be fully working
ultrasonic_ranger_node: appears to be fully working
Distance_sensor_node: appears fully working
gopigo_teleop_node: appears fully working
ydlidar_ros2_driver: appears fully working
teleop_twist_joy with snes.config.yaml working
added a million example ROS2 command scripts:
Added some non-ROS GoPiGo programs to help
slam-toolbox installed and configured for ydlidar X4
ydlidar transform publishing for laser_frame to base_link
Confirmed /map publishing (at 1 map every 5 seconds) using 7% of CPU
Uses 600MB (1.2GB free of 1.8GB total)
Uses 40% of the Pi4B processor
Processor temp: 51-59degC
7.7W (0.7A at 10.9v) Total Load On Battery
Managed to resurrect my desktop ROS2 Galactic VM and get rviz2 to display the map
It’s accurate btw.
(That black square above the blue ROS2HH bot is Carl)
** THIS IS TOTALLY ON-BOARD THE GOPIGO3 PROCESSING **
(Displaying the map graphic is off-board)
I had something like that early on - was an issue with the positioning of the lidar on my URDF. So ensuring transforms are consistent sounds like the right approach.
/K
Is the right way to do that to launch a robot state and robot joint state publisher that reads the URDF?
I see in my Hands on ROS notes the robot and joint state publishers were launched in the rviz launch script on the desktop. I always thought that strange that the robot didn’t run these, but they seem to be the key to slam, and to visualization which as far as I could tell we’re only on the desktop.
I don’t think it should matter where they run, just as long as they are publishing from somewhere, and since I’m trying to put everything GoPiGo3 on the bot, I think I want/need them on the bot as well.
At the present my GoPiGo3 node publishes an odom to base_link tf, and the LiDAR is publishing an incorrect laser to base_link tf. I would like to have all the transforms coming from the URDF as a central configuration file.
I’ll have to go back and refresh my memory. If I recall not all transforms came from the URDF.
/K
Cloud-init was not running at boot, so networking could not be pre-configured.
I have a distinct memory of one of my files creating a transform outside the URDF, but right now I can’t find it looking through my GitHub repository. I’ll keep looking.
/K
Don’t worry about checking the “old”, I’ve got the mapping working with the GoPiGo3 generating the Odom to base_link and the LIDAR generating the laser to base_link and that is working well.
I’m going to investigate running the robot state and joint state publisher from URDF on the GoPiGo3. That just seems like the right place for my “everything you ever wanted to know about ROS2 (when you know nothing about ROS) on the GoPiGo3”.
If a user has ROS2 desktop (for rviz2) they can visualize everything, but I’m trying to make that completely optional to have a complete self-contained ROS2 GoPiGo3 robot with no dependancy on any “off-board processing”.
That’s great.
I re-flashed a micro SD-card. My GPG3 gets a solid green light, but still doesn’t show on the network (even when I connect an ethernet cable). I’ve dug a monitor and VGA cable out of the basement - tomorrow I should be able to trouble shoot directly. But too late for me tonight 
/K
No No, please drop testing that version. I am trying a new image of that system on which I performed
sudo cloud-init clean --logs
before shutting down.
This claims to re-enable the reading of the network-config file to establish the network.
Still researching the “headless network re-configuration” issue
I really thank you for your testing with that version 1.
I won’t spend too much time on it - I’m curious as to what’s going on.
/K
One thing to try might be to add:
ethernets:
eth0:
optional: true
dhcp4: true
to the /boot/network-config file
ethernets:
eth0:
optional: true
dhcp4: true
wifis:
wlan0:
dhcp4: true
optional: true
access-points:
"your_SSID":
password: "your_netpswd"
after flashing the image to the card (using the imager wifi/hostname/… setup), and see if it enables wired connection.
You may have to boot the system twice - I have confirmed that the network-config file gets copied to the /etc/netplan/50-cloud-init.yaml on the first boot, so perhaps on the second boot it will get used.
I just tried this with my new image that I did the sudo cloud-init clean --logs in before shrinking and confirmed that the 1st boot copied the network-config to the 50-cloud-init.yaml and the second boot used the new info.
To try a new SSID that the sys had never attached to before, I setup my iPhone hotspot and eth0 into the network-config file.
First boot:
sudo apt install -y net-tools wifi-tools
so that
ifconfig
iwconfig
were available to see info about the connections.
Second boot:
Third boot (with iPhoneX hotspot active):
Maybe three boots is the secret?
I am able to see the user file system when I mount the disk on my linux laptop, and saw that the cloud-init clean did not remove the /etc/netplan/50-cloud-init.yaml. I think that explains the need for a few boots. I’m building a new shrunk image without that file, and will post it after some more tests.
Just for future reference.
Initial boot - failed to connect to wifi. Actually got hung up on log-in. I meant to record at what stage, but then the message went off the screen before I transcribed it- had to use ctrl-c to get a prompt. Wouldn’t connect via ethernet either when I plugged in a cable after booting. There was no /boot/network-config file when I looked on the ubuntu file system. Shut down.
I rebooted - I had the screen set up this time. Noticed one of the boot messages was that eth0 and wlan0 were “false”. Didn’t hang this time when I logged in, but no network connection. Shut down.
Modified the network-config file on the SD card to include eth0. Also noticed there was a “renderer” line for wifi - I removed that since you didn’t show it.
First boot: eth0 and wlan0 “false” on boot messages; no network connection (tried ping and not showing on my wifi control panel dashboard)
Second boot: same boot messages; not online as before.
Third boot: same result
Ok - three strikes and I’m out. No more exploration of this version. I’ll test the new version as soon as I can.
/K
