I actually don't plan on using ROS. Part of this project for me is to learn more about the algorithms used in mobile robotics as well as network programming. Using ROS would mean a lot of that is already implemented and I wouldn't learn it!
Solid project, looking forward to seeing it running one question - is there a specific reason you're using 2 picos, instead of just running the motors off the same one, or the main ras-pi? Are you limited by number of pins, or is there another reason for separating them
Hey glad you like my project! There isn't any reason that both motors couldn't be run from one microcontroller or from the Raspberry Pi directly. The only difficulty would be the specific wheel encoders I am using don't have settable I2C address, so you would have to use an I2C multiplexer to communicate with multiple. The reason I went for two microcontrollers is for ease of programming and debugging. If I had one microcontroller for both motors, I would be more likely to write an error that only affected only one motor that would be hard to debug. As for why I didn't directly connect the motors to the Raspberry Pi, I like using the GPIO on the Pi as little as possible. Its more expensive to replace if any wiring is wrong and the board is shorted out. I also knew I will need a communications bus for future (secrete for now) upgrades to the vehicle, so its not like the communications bus is adding any complexity to the design.
@@kleistrobotics makes sense, agreed that messing with GPIO on the pi feels like a sketchy plan - from what I've heard there can be some weirdness with signal timing too since it has to go through an OS In my projects I guess I avoid inter board comms when I can, idk, they always feel confusing and complicated to get working. But seems like you got it figured out :)
Yeah I used to struggle with the board to board communication but I've had to deal with it at work so much its become a sink or swim situation lol. The CAN modules I mentioned make it really easy.
If I remember correctly, he was using the LIDAR as a simple "if wall to the left, then turn away from it" type control system, or maybe he had trained a neural network on lidar data to drive around a hallway. The control system for this ride will be more complicated than that, it is mapping and localization to that map. Of course there are ways around it, two or more vehicles could communicate with each other and they could update their maps to expect to see the vehicles in their reported position. The problem with that is if the reported position is wrong, then your stacking error on error on error, which will eventually result in bad localization and dangerous behavior of the vehicle (like driving into walls).
Be sure to comment if you have any questions or suggestions!
this deserves way more views, good editing, good overall video, amazing build quality
Hey thanks for the compliments! I'm glad you liked it and I hope you're excited for part two as I am!
Aaarrrrgggh you freakin’ beat me to it.
Ooohhh this is awesome!!! Are you using ROS?
I actually don't plan on using ROS. Part of this project for me is to learn more about the algorithms used in mobile robotics as well as network programming. Using ROS would mean a lot of that is already implemented and I wouldn't learn it!
Solid project, looking forward to seeing it running
one question - is there a specific reason you're using 2 picos, instead of just running the motors off the same one, or the main ras-pi? Are you limited by number of pins, or is there another reason for separating them
Hey glad you like my project! There isn't any reason that both motors couldn't be run from one microcontroller or from the Raspberry Pi directly. The only difficulty would be the specific wheel encoders I am using don't have settable I2C address, so you would have to use an I2C multiplexer to communicate with multiple.
The reason I went for two microcontrollers is for ease of programming and debugging. If I had one microcontroller for both motors, I would be more likely to write an error that only affected only one motor that would be hard to debug.
As for why I didn't directly connect the motors to the Raspberry Pi, I like using the GPIO on the Pi as little as possible. Its more expensive to replace if any wiring is wrong and the board is shorted out. I also knew I will need a communications bus for future (secrete for now) upgrades to the vehicle, so its not like the communications bus is adding any complexity to the design.
@@kleistrobotics makes sense, agreed that messing with GPIO on the pi feels like a sketchy plan - from what I've heard there can be some weirdness with signal timing too since it has to go through an OS
In my projects I guess I avoid inter board comms when I can, idk, they always feel confusing and complicated to get working. But seems like you got it figured out :)
Yeah I used to struggle with the board to board communication but I've had to deal with it at work so much its become a sink or swim situation lol. The CAN modules I mentioned make it really easy.
I've seen @nikodembartnik use more that one robot using lidar at a time.
If I remember correctly, he was using the LIDAR as a simple "if wall to the left, then turn away from it" type control system, or maybe he had trained a neural network on lidar data to drive around a hallway. The control system for this ride will be more complicated than that, it is mapping and localization to that map.
Of course there are ways around it, two or more vehicles could communicate with each other and they could update their maps to expect to see the vehicles in their reported position. The problem with that is if the reported position is wrong, then your stacking error on error on error, which will eventually result in bad localization and dangerous behavior of the vehicle (like driving into walls).