[{"content":"Originally published on Project Pixel Orbital.\nRead the full post.\n","permalink":"http://ashwinnaren.com/blog/2026_07_20_pixelsat_software_part_3/","summary":"An external post on Project Pixel Orbital about the PixelSat I OBC, covering everything from chip selection to the RTIC tasks.","title":"PixelSat I Software Part 3: Comms System"},{"content":"Originally published on Project Pixel Orbital.\nRead the full post.\n","permalink":"http://ashwinnaren.com/blog/2026_07_13_pixelsat_software_part_2/","summary":"An external post on Project Pixel Orbital about the PixelSat I ADCS, covering constraints, math, and models.","title":"PixelSat I Software Part 2: Comms System"},{"content":"Originally published on Project Pixel Orbital.\nRead the full post.\n","permalink":"http://ashwinnaren.com/blog/2026_07_07_pixelsat_software_part_1/","summary":"An external post on Project Pixel Orbital about the PixelSat I communications stack, covering transceiver selection, modulation tradeoffs, message framing, and ground-network design.","title":"PixelSat I Software Part 1: Comms System"},{"content":" Originally published in the now-defunct FRC Team #4014 (Pixelators) website.\nSince that website is now down, I\u0026rsquo;ve moved the post here.\nIn retrospect, it would have made far more sense to communicate over UART or SPI if possible over UDP.\nThis season, our software team used an NVIDIA Orin Nano Developer Kit as a coprocessor with an attached Intel RealSense camera. This coprocessor allowed us to perform computationally intensive vision tasks, such as VSLAM, object detection, and April Tags, in parallel with our main robot code running on the RoboRIO.\nWhy an Orin Nano? We were looking for a coprocessor that had a good GPU, for faster vision task performance. Naturally, we looked at NVIDIA\u0026rsquo;s processors due to NVIDIA\u0026rsquo;s high-performance GPUs. We are constricted by the $600 limit on robot parts, so we couldn\u0026rsquo;t use a Jetson AGX Developer Kit ($2000-$3000). We needed a developer kit to test our code because we did not want to run the risk of deploying code on a processor that is not our testing processor due to time and budget constraints. So we did not consider non-developer kit options like the Jetson Orin NX series. The Orin Nano Developer Kit was within the $600 limit, so it was chosen. It has a 1024-core NVIDIA Ampere architecture GPU with 32 Tensor Cores, which produces up to 40 TOPS (Tera Operations Per Second) of performance. It also has a 6-core ARM Cortex-A78AE CPU, which is more than enough for our CPU work. The Orin also has a decent 7–15 W power consumption, which ensures it does not drain our battery power too quickly.\nROS 2 We used ROS 2 (Robot Operating System 2) to run the software on the Orin Nano. ROS 2 is an architecture of sorts for writing robot software. It consists of nodes, which are separate processes that communicate with each other via ROS 2\u0026rsquo;s middleware. There are three types of ways to communicate between nodes: topics, services, and actions. Topics are a publish-subscribe system, where one node publishes data to multiple receivers. Services are a request-response system, where one node requests data from another node. Actions are a more complex version of services, where the request-response system is asynchronous and there are status updates along the way. For our project, we only used topics. NVIDIA maintains a version of ROS 2 called ISSAC ROS, which has some additional support for their GPUs.\nTo set it up, NVIDIA has published a guide to setup a developer environment.\nAfter setting up the environment, we had to create a workspace and install the necessary packages (VSLAM, Object Detection, and April Tags).\nTo play around with the nodes, NVIDIA provided a shell script that would launch the nodes: scripts/run_dev.sh.\nWe run the script like this:\ncd ${ISAAC_ROS_WS}/src/isaac_ros_common \u0026amp;\u0026amp; \\ ./scripts/run_dev.sh ${ISAAC_ROS_WS} This script builds and runs the dockerfile, and then attaches to the container.\nThen we could install the required packages and run the nodes:\nsudo apt-get install -y ros-humble-isaac-ros-visual-slam ros2 launch isaac_ros_visual_slam isaac_ros_visual_slam_realsense.launch.py After running this command, we could list the nodes:\nadmin@ubuntu:/workspaces/isaac_ros-dev$ ros2 node list /rectify /resize_node /visual_slam_launch_container /visual_slam_node You can try out ros2 topic list and ros2 service list too, and view the topic output with ros2 topic echo \u0026lt;topic name\u0026gt;, or view the frequency of the topic with ros2 topic hz \u0026lt;topic name\u0026gt;.\nVision Tasks We ran three vision tasks on the Orin Nano:\nVSLAM (Visual Simultaneous Localization and Mapping) April Tags Object Detection We used the Intel RealSense camera for all three tasks.\nVSLAM VSLAM is a method used by robots and drones to navigate and map their surroundings. It uses a camera to detect features in the environment and uses those features to determine the robot\u0026rsquo;s position. This is useful in FRC because it isn\u0026rsquo;t reliant on wheel positions and slippage does not affect it. It becomes particularly useful when the robot is bumped or pushed by another robot. We used the NVIDIA ISAAC ROS VSLAM Package. This package contains a VSLAM node. When the node is run, it outputs the robot\u0026rsquo;s path to /visual_slam/tracking/slam_path. This node can be configured in many ways — for example, we enabled IMU fusion to get a more accurate position as we had a RealSense camera with an internal IMU.\nApril Tags Unfortunately, VSLAM is not perfect; at times, it can lose tracking of its surroundings. This leads to a massive drift in the robot\u0026rsquo;s position, which cannot be correct. We compensate a little with the IMU and dead-reckoning from motor encoder positions, but it is not enough.\nTo help prevent this from happening, we used the April Tags on the field to correct the VSLAM position. We used the April Tags ROS package from NVIDIA for this task. Due to performance requirements, we couldn\u0026rsquo;t run april tags at full speed because it would slow down the VSLAM. Once we received the April Tag data, we would correct the VSLAM position with the estimated robot position from the april tags via the SetOdometryPose service.\nObject Detection This didn\u0026rsquo;t make the cut due to time and performance constraints. But we did train a YOLO model to detect the notes that can be found on GitHub.\nWe were planning to use the ISAAC ROS Object Detection package to run the YOLO model.\nCustom Node Due to the high performance requirements, we used rust for the custom node on the Orin Nano via Ros2 Rust. This was surprisingly well-supported. Rust allowed us to reduce latency by allowing for easy parallelization and gave us better control over memory. The code for that node can be found on GitHub.\nCreating a node and subscribing to topics and creating clients in ROS 2 is very ergonomic.\nlet context = rclrs::Context::new(std::env::args())?; // Creates a node from the context with a name, which will appear on the ROS 2 network let node = rclrs::Node::new(context, \u0026#34;network_node\u0026#34;)?; // Creates a client to call the set_odometry_pose service, which resets the internal VSLAM position to a specified value let client = node.create_client::\u0026lt;isaac_ros_visual_slam_interfaces::srv::SetOdometryPose\u0026gt;( \u0026#34;visual_slam/set_odometry_pose\u0026#34;, )?; let path = Arc::new(RwLock::new(None)); // RwLocks allow for interior mutability (unlimited reads at once, but only one write at a time) let path_cb = Arc::clone(\u0026amp;path); let path_subscription = // Create a new shared pointer instance that will be owned by the closure node.create_subscription( \u0026#34;/visual_slam/tracking/slam_path\u0026#34;, // Slam path is the only topic that returns the robot\u0026#39;s current position rclrs::QOS_PROFILE_DEFAULT, move |msg: PathMsg| { // This subscription now owns the data_cb variable *path_cb.blocking_write() = Some(msg); // Blocking write because there isn\u0026#39;t a tokio runtime }, )?; Due to rust\u0026rsquo;s strict borrow checker, we had to use Arcs to share data across threads and RwLocks to allow for interior mutability.\nCommunication with the RoboRIO The Orin Nano was connected to the RoboRIO via Ethernet. Due to latency concerns Because network tables didn\u0026rsquo;t compile on the Orin Nano for rust, we communicated between the two via a custom UDP protocol to reduce latency. Rust is great for networking, so creating a reliable crash-proof UDP server was easy. The harder part was calling it from the RIO, which was written in C++. Our custom UDP protocol was simple and status; we just serialized the Pose into bytes (first byte was status, 1-5 was x, 5-9 was y, etc.). We also left some room for error handling in the protocol, with the first byte being the response type (0 is empty, 1 is error string, 2 is Pose etc.).\nsend_buffer[0] = std::byte{0}; socket.send(send_buffer); if (socket.bytes_available() \u0026gt;= 25) { const auto [data_size, status_code] = socket.recv(receive_buffer); float x; float y; float z; float roll; float pitch; float yaw; memcpy(\u0026amp;x, \u0026amp;receive_buffer[1], sizeof(float)); memcpy(\u0026amp;y, \u0026amp;receive_buffer[5], sizeof(float)); memcpy(\u0026amp;z, \u0026amp;receive_buffer[9], sizeof(float)); memcpy(\u0026amp;roll, \u0026amp;receive_buffer[13], sizeof(float)); memcpy(\u0026amp;pitch, \u0026amp;receive_buffer[17], sizeof(float)); memcpy(\u0026amp;yaw, \u0026amp;receive_buffer[21], sizeof(float)); pose.x = x; pose.y = y; pose.z = z; pose.roll = roll; pose.pitch = pitch; pose.yaw = yaw; frc::SmartDashboard::PutNumber(\u0026#34;x\u0026#34;, pose.x); frc::SmartDashboard::PutNumber(\u0026#34;y\u0026#34;, pose.y); frc::SmartDashboard::PutNumber(\u0026#34;z\u0026#34;, pose.z); frc::SmartDashboard::PutNumber(\u0026#34;roll\u0026#34;, pose.roll); frc::SmartDashboard::PutNumber(\u0026#34;pitch\u0026#34;, pose.pitch); frc::SmartDashboard::PutNumber(\u0026#34;yaw\u0026#34;, pose.yaw); } Logging crate While we were at it, we also used the log crate to log messages and developed a custom logger that logs in a ros2 supported manner. This was useful for debugging and logging errors.\nYou can find it as in the ros2_logger subdirectory, but we plan to move it to its own repository, so it can be used in a Cargo.toml.\nPackaging We used Docker to package our code, you can find our docker file here: https://github.com/Pixelators4014/pixelization_rs/blob/master/Dockerfile.\nTo run all the nodes simultaneously, we used a launch file, which we published here: https://github.com/Pixelators4014/pixelization_rs/blob/master/launch/run.launch.py.\nThe launch file is a python file that configures and launches all the nodes.\nIntegration with the Main Robot Code The C++ STL sucks at doing basically everything, so naturally creating an UDP socket was a pain. To fix this, we used kissnet, a header-only C++ networking library that greatly simplified socket creation.\nIntegrating the new data with odometry was rather trivial with the update method of the odometry object (https://docs.wpilib.org/en/stable/docs/software/kinematics-and-odometry/swerve-drive-odometry.html#updating-the-robot-pose).\nConclusion Further Improvements We could have fused the April Tags and VSLAM data with a Kalman Filter to get a more accurate position of the robot. We disabled this because of time constraints, but it was implemented.\nAlso, we could have moved away from ROS 2 to normal C++ packages, as ROS 2 affects performance due to its concurrency model.\nShould you use an Orin Nano? Short answer: Probably not.\nThe Orin Nano is great if you have the time and resources to set it up. \u0026hellip; but you have to learn ROS 2, which has a steep learning curve.\nIt also requires immense amounts of Linux knowledge to set up and configue—we probably spent hours configuring our Dockerfiles. The NVIDIA documentation is also not the best and is not well organized, so you have to rely on the community for help sometimes.\nWe started around Mid-February and only got it working less than a day before competition (AVR). And this was with two people working on it close to full-time who had plenty of experience doing this before. It, however, probably would be a great off-season project that could be used in the next season.\nHappy Hacking and Good Luck!\nEDIT 1 (5/28/2024): Fixed FMV limit typo\nEDIT 2 (7/18/2024): Our ros2 logger has moved to https://github.com/Pixelators4014/ros2_logger\n","permalink":"http://ashwinnaren.com/blog/2024_05_25_orin_coprocessor/","summary":"Moved from a defunct website.","title":"Adventures with an Orin Nano"},{"content":"","permalink":"http://ashwinnaren.com/music/","summary":"","title":"Music"},{"content":"Most of my projects are on my GitHub profile: https://github.com/arihant2math.\nA few other organizations have projects that I created/maintain:\nhttps://github.com/libffi-rs/ https://github.com/Pixelators4014/ https://github.com/The-Knights-of-Ni/ https://github.com/ApesofWrath Open Source libffi-rs I maintain libffi-rs: bindings for the libffi C library. The library provides a (mostly) safe interface for making dynamic user-defined ffi calls at runtime with minimal overhead. It currently is used by Miri, deno, and RustPython, among other projects.\nRepo VSLAM in FRC Integration of VSLAM on a FRC robot for enhanced localization abilities. VSLAM (Visual SLAM) is a technology that uses points of contrast in an enviorment to track the position of the camera within the enviorment. The technology for this was provided by NVIDIA and an Intel Realsense camera was used for stereo camera input. The VSLAM computations were running in conjunction with April Tag detection on an Orin Nano running ROS 2 (Robot Operating System 2).\nI developed a sub-millisecond latency communication system to fuse the April Tag and the VSLAM localization data before sending it to the main processor to be used.\nBlog Post Repo Prontus A custom frontend (desktop app) written in Rust and Tauri for https://pronto.io. It involved reverse-engineering pronto\u0026rsquo;s http and websocket API.\nRepo Finished Projects Projects that have reached an end-state. Research in pre-print or publication can be found in the publications page.\nTraffic Detection from CCTV footage Trained YOLOv8 to optimally detect cars via pre-installed CCTV on highways to calculate traffic flow in various areas.\nFinal Report Repo ","permalink":"http://ashwinnaren.com/projects/","summary":"\u003cp\u003eMost of my projects are on my GitHub profile: \u003ca href=\"https://github.com/arihant2math\"\u003ehttps://github.com/arihant2math\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eA few other organizations have projects that I created/maintain:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/libffi-rs/\"\u003ehttps://github.com/libffi-rs/\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/Pixelators4014/\"\u003ehttps://github.com/Pixelators4014/\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/The-Knights-of-Ni/\"\u003ehttps://github.com/The-Knights-of-Ni/\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/ApesofWrath\"\u003ehttps://github.com/ApesofWrath\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch1 id=\"open-source\"\u003eOpen Source\u003c/h1\u003e\n\u003ch2 id=\"libffi-rs\"\u003elibffi-rs\u003c/h2\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"https://img.shields.io/crates/d/libffi\" alt=\"Crates.io Total Downloads\"  /\u003e\n\u003c/p\u003e\n\u003cp\u003eI maintain libffi-rs: bindings for the libffi C library.\nThe library provides a (mostly) safe interface for making dynamic user-defined ffi calls at runtime with minimal overhead. It currently is used by \u003ca href=\"https://github.com/rust-lang/miri\"\u003eMiri\u003c/a\u003e, \u003ca href=\"https://deno.com/\"\u003edeno\u003c/a\u003e, and \u003ca href=\"https://rustpython.github.io/\"\u003eRustPython\u003c/a\u003e, among other projects.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/libffi-rs/libffi-rs\"\u003eRepo\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"vslam-in-frc\"\u003eVSLAM in FRC\u003c/h2\u003e\n\u003cp\u003eIntegration of VSLAM on a FRC robot for enhanced localization abilities.\nVSLAM (Visual SLAM) is a technology that uses points of contrast in an enviorment to track the position of the camera within the enviorment.\nThe technology for this was provided by NVIDIA and an Intel Realsense camera was used for stereo camera input.\nThe VSLAM computations were running in conjunction with April Tag detection on an Orin Nano running ROS 2 (Robot Operating System 2).\u003c/p\u003e","title":"Projects"},{"content":"EvoX: Meta-Evolution for Automated Discovery Shu Liu*, Shubham Agarwal*, Monishwaran Maheswaran, Mert Cemri, Zhifei Li, Qiuyang Mang, Ashwin Naren, Ethan Boneh, Audrey Cheng, Melissa Pan, Alexander Du, Kurt Keutzer, Alexandros Dimakis, Koushik Sen, Matei Zaharia, Ion Stoica\nPreprint: https://arxiv.org/abs/2602.23413\nProject Page: https://skydiscover-ai.github.io/\nRepo: https://github.com/skydiscover-ai/skydiscover\nAdaEvolve: Adaptive LLM Driven Zeroth-Order Optimization Mert Cemri*, Shubham Agrawal*, Akshat Gupta, Shu Liu, Audrey Cheng, Qiuyang Mang, Ashwin Naren, Lutfi Eren Erdogan, Koushik Sen, Matei Zaharia, Alex Dimakis, Ion Stoica\nPreprint: https://arxiv.org/abs/2602.20133\nProject Page: https://skydiscover-ai.github.io/\nRepo: https://github.com/skydiscover-ai/skydiscover\nLet the Barbarians In: How AI Can Accelerate Systems Performance Research Audrey Cheng, Shu Liu, Melissa Pan, Zhifei Li, Shubham Agarwal, Mert Cemri, Bowen Wang, Alexander Krentsel, Tian Xia, Jongseok Park, Shuo Yang, Jeff Chen, Lakshya Agrawal, Ashwin Naren, Shulu Li, Ruiying Ma, Aditya Desai, Jiarong Xing, Koushik Sen, Matei Zaharia, Ion Stoica\nExplores AI-driven optimization of problems via evolutionary learning.\nPreprint: https://arxiv.org/abs/2512.14806\nProject Page: https://sky.cs.berkeley.edu/project/adrs/\nHomomorphism Density Ashwin Naren\nAn expository paper on Homomorphism Density, a subfield of extremal graph theory concerning the density of a homomorphism in a graph. Homomorphism density provides probabilistic insights on the local structures of dense graphs.\nhttp://simonrs.com/eulercircle/irpw2024/ashwin-homdensity-paper.pdf\nIsoperimetric sets of English words Grant Blitz, Timothy Chen, Marcus Collins, Ashwin Naren, Edward Zhang, et al.\nOn Isoperimetric sets of english words, using the metric distances between them as a numerical measure of distance on the 3000 most used English words.\nhttps://www.parabola.unsw.edu.au/sites/default/files/2024-02/vol59_no2_1.pdf\n* denotes equal contribution\n","permalink":"http://ashwinnaren.com/publications/","summary":"\u003ch2 id=\"evox-meta-evolution-for-automated-discovery\"\u003eEvoX: Meta-Evolution for Automated Discovery\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eShu Liu*, Shubham Agarwal*, Monishwaran Maheswaran, Mert Cemri, Zhifei Li, Qiuyang Mang, Ashwin Naren, Ethan Boneh, Audrey Cheng, Melissa Pan, Alexander Du, Kurt Keutzer, Alexandros Dimakis, Koushik Sen, Matei Zaharia, Ion Stoica\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003ePreprint: \u003ca href=\"https://arxiv.org/abs/2602.23413\"\u003ehttps://arxiv.org/abs/2602.23413\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eProject Page: \u003ca href=\"https://skydiscover-ai.github.io/\"\u003ehttps://skydiscover-ai.github.io/\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eRepo: \u003ca href=\"https://github.com/skydiscover-ai/skydiscover\"\u003ehttps://github.com/skydiscover-ai/skydiscover\u003c/a\u003e\u003c/p\u003e\n\u003ch2 id=\"adaevolve-adaptive-llm-driven-zeroth-order-optimization\"\u003eAdaEvolve: Adaptive LLM Driven Zeroth-Order Optimization\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003eMert Cemri*, Shubham Agrawal*, Akshat Gupta, Shu Liu, Audrey Cheng, Qiuyang Mang, Ashwin Naren, Lutfi Eren Erdogan, Koushik Sen, Matei Zaharia, Alex Dimakis, Ion Stoica\u003c/em\u003e\u003c/p\u003e","title":"Publications"}]