ls -l /dev/ttyUSB* /dev/ttyACM* /dev/serial/by-id/ 2>/dev/null
dmesg | tail -n 80

The problem is fixed by simply disabling the USB autosuspend on Jetson, by running the following command:

sudo bash -c 'echo -1 > /sys/module/usbcore/parameters/autosuspend'

As you can see, we would need around 50Ah to run the robot for 5 hours continuously, and only 33Ah to run it for 3 hours. It is important to note that these numbers assume the robot is consuming 150W continuously which may not be the case.

Battery Constraints:

The height of the battery should be less than 5, 1/2 to be placed in the bottom compartment of the robot. If the battery is any larger, the frame design will have to be changed to accommodate the larger battery size. Width and length of the battery do not seem to matter (as far as I know!). This space constraint incentivizes us to use multiple smaller batteries and hook them up in parallel rather than using one larger battery, however, the capacity of these smaller batteries may not be enough to effectively support the projects needs. Below are some options I currently have in mind:

Option 1) Hook up Four 12V 8Ah batteries from lab (Model # SLA1079)

This would allow the batteries to fit under the frame while maintaining higher Ah capacity. This matches the project needs pretty well and uses batteries that are already owned, however, there are a few problems with it which I've listed below:

      a) With four batteries in parallel we can achieve 36Ah of capacity which can power the robot for only 3 hours continuously
          instead of 5.

      b) The current draw of the robot may be too high for the battery to supply continuously at a healthy level. The SLA1079
          datasheet provides us with a table that relates battery runtime and continuous current usage over time. It shows that
          continuous current should be lower if the battery is used for longer periods of time. This is to ensure battery health. Basically,
          if you run the battery for longer, you shouldn't draw as much current from it continuously, otherwise you hurt the battery over
          time. This table can be found in the google doc provided (I'd attach an image but I don't think the forum allows me to do that)

Option 2) Hook up Six 12V 8Ah batteries (SLA1079)

Same as option 1, but we increase capacity and current draw which solve problems a) and b). This could work, however, I'm not sure if we can safely connect 6 batteries, it may cause current draw issues. I will look into this.

Option 3) Purchase a larger battery

We could purchase a larger battery (40-60Ah battery to support 5+ hours of continuous use). This would increase the runtime of the robot as well as ensure the current draw of the robot can be easily managed. There are a few issues with this method though:

a) Increases the weight of the robot, potentially reducing mobility

b) The battery would be too large to fit inside the hull, so the hull would have to be modified to accommodate the larger battery.

Other Notes:

This is all the info I have now, but I'll keep doing research and figure out if hooking up 6 12V 8Ah batteries is safe, as well as looking into the current draw of both small and large batteries to see if they can handle the continuous current draw of our system.

Here are links to the excel spreadsheet and google doc with all my work. This information can also be found in the google drive.

Excel:
https://docs.google.com/spreadsheets/d/1c61AJ6dTo-TDHi3su-V8-ZS31RmROvyz_vDzj9C5zlU/edit?usp=sharing 

Google Doc:
https://docs.google.com/spreadsheets/d/1c61AJ6dTo-TDHi3su-V8-ZS31RmROvyz_vDzj9C5zlU/edit?usp=sharing 

• RPLIDAR publishes /scan (LaserScan)
• TF tree is complete: map --> odom -->  base_link --> laser
• SLAM toolbox publishes /map and map --> odom
• Nav2 runs without AMCL + without map_server while you are mapping
  • Nav2 expects SLAM to provide those

Bringup: 

1) Install packages (Jazzy)

sudo apt update
sudo apt install -y \
  ros-jazzy-navigation2 ros-jazzy-nav2-bringup \
  ros-jazzy-slam-toolbox \
  ros-jazzy-tf2-ros

2) Run RPLIDAR A1 driver (rplidar_ros)

ros2 launch rplidar_ros view_rplidar_a1_launch.py

Confirm the scan topic (in another terminal)

ros2 topic list | grep scan
ros2 topic echo /scan --once

header.frame_id has to be laser or laser_frame. This frame must match the TF.

3) Provide the TF from base_link --> laser

If not already published with URDF + robot_state_publisher, publish a static transform:

Ex; laser is 0.20m forward, 0.10m up from base_link , no rotation 

ros2 run tf2_ros static_transform_publisher \

  0.20 0.0 0.10 0 0 0 base_link laser

Check:

ros2 run tf2_ros tf2_echo base_link laser

4) Check odometry (odom --> base_link)

Odom comes from wheel encoders.

ros2 topic echo /odom --once

ros2 run tf2_ros tf2_echo odom base_link

5) Start SLAM toolbox (online async)

6) Start Nav2 (navigation only, no AMCL/map_server)

7) Start RViz

8) Save map

Exploration is not part of Nav2. It is a goal generator:

- subscribes to /map (OccupancyGrid)

- finds frontiers (boundary between known free space and unknown space)

- picks a frontier goal pose

- calls Nav2's NavigateToPose (or waypoint follower) action so Nav2 drives the repeats until no frontiers remain

explorer never publishes /cmd_vel. Nav2 still owns motion.

Prereqs that must already work:

Before installing exploration, make sure:

1. SLAM toolbox is publishing /map
2. TF chain exists: map --> odom --> base_link --> laser
3. Nav2 action server exists: navigate_to_pose

Check using:

• ros2 topic echo /map --once

• ros2 run tf2_ros tf2_echo map odom

• ros2 action list | grep navigate_to_pose

Install:

sudo apt update

sudo apt install -y ros-jazzy-nav2-bringup ros-jazzy-slam-toolbox

2) Clone + build in your workspace

cd ~/ws_big_robot/src   # or whatever your colcon ws is

git clone https://github.com/robo-friends/m-explore-ros2.git

cd ~/ws_big_robot

rosdep update

rosdep install -i --from-path src --rosdistro jazzy -y

colcon build --symlink-install

source install/setup.bash

3) Confirm it installed

ros2 pkg list | grep explore

ros2 run explore_lite explore --help

4) How to run it manually (first test)

ros2 run explore_lite explore --ros-args --params-file \

  ~/ws_big_robot/src/m-explore-ros2/explore/config/params.yaml

It also supports stop/resume by publishing Bool to explore/resume.

Where to embed it in your system (your bringup XML):

You embed it in the same bringup launch after you start SLAM Toolbox + Nav2.

In your current bringup file, add this node near the bottom (after navigation include is fine):

<!-- Exploration node (frontier exploration) -->

<node pkg="explore_lite"

      exec="explore"

      name="explore"

      output="screen"

      args="--ros-args --params-file $(find-pkg-share big_robot_navigation)/params/explore.yaml">

  <param name="use_sim_time" value="$(var use_sim_time)"/>

  <!-- If you use namespaces, avoid absolute topics unless you really mean global -->

  <remap from="/tf" to="tf"/>

  <remap from="/tf_static" to="tf_static"/>

</node>

Important practical note (startup ordering):

explore_lite “starts right away” by default.
If it starts before Nav2 is fully active, it may fail goals.

Easy workaround: start it embedded, but immediately “pause” exploration and unpause after Nav2 is active:

# pause

ros2 topic pub /explore/resume std_msgs/msg/Bool "{data: false}" -1

# later, resume

ros2 topic pub /explore/resume std_msgs/msg/Bool "{data: true}" -1

Create params/explore.yaml (starter template):

Start simple; don’t over-tune until it moves.

# big_robot_navigation/params/explore.yaml

explore:

  ros__parameters:

    # Common knobs you’ll tune:

    # - how close is "goal reached"

    # - how long to wait before declaring stuck

    # - frontier size thresholds

    # These names vary slightly across explore implementations, so:

    # 1) start by copying the repo's explore/config/params.yaml

    # 2) move it here and edit

Best workflow:

1. Copy the repo’s default params file into your package
2. Edit locally
3. Point the node at your copy

The repo explicitly shows where the default params live and how to run with them. 

Debugging when it “doesn’t move”

Most common causes:

1. No /map (SLAM toolbox not running / wrong scan topic)
2. TF broken (especially map→odom or odom→base_link)
3. Nav2 not actually active (bt_navigator lifecycle not “active”)
4. Topic mismatch (namespaces + you used /scan absolute in one place, relative in another)

Also: in RViz, add the frontiers marker if available:

• m-explore-ros2 mentions a frontiers marker topic explore/frontiers.

We use Université Laval’s Northern Robotics Lab (Norlab) Roboclaw ROS2 driver.
The ROS package uses the Python driver by Team Chat Robotique (tcr-roboclaw).

This guide reflects what we confirmed working today in /ws_big_robot/ws_big_robot.

1) Install Python dependency into the same Python ROS uses

ROS2 console scripts run with the Python that launches the node (often system Python in containers). Install tcr-roboclaw in that same environment.

python3 -m pip install -U tcr-roboclaw transforms3d --break-system-packages --index-url https://pypi.org/simple

Verify:

python3 -c "import tcr_roboclaw; print(tcr_roboclaw.__file__)"

2) Clone repositories into /ws_big_robot/ws_big_robot/src

cd /ws_big_robot/ws_big_robot
mkdir -p src
cd src
git clone https://github.com/norlab-ulaval/roboclaw_ros.git
git clone https://github.com/norlab-ulaval/norlab_custom_interfaces.git

3) Install required ROS system dependencies

sudo apt update
sudo apt install -y \ ros-jazzy-diagnostic-updater \ ros-jazzy-tf-transformations \ ros-jazzy-grid-map-msgs

grid_map_msgs fixes the falcon_msgs build failure.

4) Fix message definitions in Norlab Custom Interfaces

The message definitions must match what roboclaw_ros publishes.

EncoderState.msg

nano /ws_big_robot/ws_big_robot/src/norlab_custom_interfaces/roboclaw_msgs/msg/EncoderState.msg

Replace the file contents with:

std_msgs/Header header
uint32 position # ticks
float32 velocity # ticks/sec
float32 ticks_per_rotation
float32 ticks_per_meter

MotorState.msg

nano /ws_big_robot/ws_big_robot/src/norlab_custom_interfaces/roboclaw_msgs/msg/MotorState.msg

Replace the file contents with:

std_msgs/Header header
float32 current # A
float32 voltage # V
float32 duty # %
float32 temperature # C

5) Configure the Roboclaw serial port

First, find the real device name:

ls -l /dev/ttyACM* /dev/ttyUSB* 2>/dev/null

Then edit the config:

nano /ws_big_robot/ws_big_robot/src/roboclaw_ros/roboclaw_ros/config/roboclaw.yaml

Set:

⚠️ Do not use /dev/ACM* — Python won’t expand wildcards.

6) Build only what you need (Roboclaw packages)

From the workspace root (NOT inside src/):

cd /ws_big_robot/ws_big_robot
source /opt/ros/jazzy/setup.bash
rm -rf build install log
colcon build --symlink-install --packages-select roboclaw_msgs roboclaw_ros

Source the workspace:

source /ws_big_robot/ws_big_robot/install/local_setup.bash

7) Serial permissions (recommended instead of chmod 777)

sudo usermod -a -G dialout $USER

Then log out/in (or reboot).
(If you are always running as root in the container, this may not matter.)

8) Launch the node

source /opt/ros/jazzy/setup.bash
source /ws_big_robot/ws_big_robot/install/local_setup.bash
ros2 launch roboclaw_ros roboclaw_node.launch.py

9) Verify topics (optional)

In another terminal:

source /ws_big_robot/ws_big_robot/install/local_setup.bash
ros2 topic list | grep -i roboclaw

Run this on your Jetson:

df -h /

You’ll see something like:

Filesystem      Size  Used Avail Use% Mounted on

/dev/mmcblk0p1  119G   42G   77G  36% /

→ This means / (your main OS root) is the microSD card, not the NVMe.

Now check whether NVMe is visible:

lsblk

Output example:

NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS

mmcblk0      179:0    0  119G  0 disk 

└─mmcblk0p1  179:1    0  118G  0 part /

nvme0n1      259:0    0  465G  0 disk 

If nvme0n1 appears with no “MOUNTPOINT” listed, it’s just sitting idle — recognized, but not being used by the OS.

2. Check if the NVMe is mounted anywhere

Run:

df -h | grep nvme

If it returns nothing → the NVMe isn’t mounted yet.

3. Use the NVMe as extra storage (recommended, safe)

You can easily use the SSD for data, Docker, ROS workspaces, etc.
Here’s the safe and fast setup:

# Create partition + format

sudo parted /dev/nvme0n1 -- mklabel gpt

sudo parted -a opt /dev/nvme0n1 mkpart primary ext4 0% 100%

sudo mkfs.ext4 /dev/nvme0n1p1 -L jetson_ssd

# Create mount point and mount

sudo mkdir -p /mnt/ssd

sudo mount /dev/nvme0n1p1 /mnt/ssd

# Make it permanent

sudo blkid /dev/nvme0n1p1

# copy the UUID from output and edit fstab

sudo nano /etc/fstab

Add a line like:

UUID=<your-uuid> /mnt/ssd ext4 defaults 0 2

Then:

sudo mount -a

Now you can store things there:

cd /mnt/ssd

mkdir projects data

4. (Optional) Move heavy data to NVMe

You can move large folders or services onto the SSD and symlink back:

sudo systemctl stop docker

sudo mv /var/lib/docker /mnt/ssd/docker

sudo ln -s /mnt/ssd/docker /var/lib/docker

sudo systemctl start docker

Launch Gazebo (terminal 1):

ros2 launch big_robot_gazebo launch_sim.launch.xml

Run SLAM Toolbox (terminal 2):

ros2 launch big_robot_navigation map_building.launch.xml use_sim_time:=true

Run RViz (terminal 3):

ros2 launch big_robot_navigation map_view.launch.xml

Activate keyboard to move around map (terminal 4): 

ros2 run teleop_twist_keyboard teleop_twist_keyboard

Save the map (terminal 5): 

ros2 run nav2_map_server map_saver_cli -f <save name>

• Ex; ros2 run nav2_map_server map_saver_cli -f my_map2

see replies for navigation + localization steps

***IMPORTANT**

I installed JetPack 6.1 and 6.2, but neither worked. Both resulted in a black screen or booted into the shell.

Because of this, we need to install an older version, JetPack 5.1.3, first. You need to power on the Jetson and update the internal firmware using JetPack 5.1.3 so that it can properly support JetPack 6.2 later.

*****

1.  Download JetPack 5.1.3:
   https://www.jetson-ai-lab.com/initial_setup_jon.html
   (This version works, but it is outdated and needs to be updated afterward.)
   
   
2.  Download Etcher:
   https://etcher.balena.io/
   and Flashing the SD card with 5.1.3 using Etcher.
   
   
3. After flashing the SD card with Etcher, power on the Jetson and update the internal firmware.
   
   
4. Once the update is complete, shut down the Jetson. Then return to Etcher and flash the SD card again with JetPack 6.2.
   
   Once the SD card is flashed, it is no longer detected on my Mac; it is only recognized on Ubuntu.
   I also tried connecting to the Jetson via SSH, but it failed.
5. If the correct screen appears after booting, you will need to change the power mode.

https://shawnhymel.com/2255/getting-started-with-nvidia-jetson-orin-nano/#:~:text=If%20you%20try%20to%20flash,USB%20cable)%20the%20first%20time.

Firefox is not working. Watch this : 

https://www.youtube.com/watch?v=x6bccF3xtRE