Example: Simple Tank-Drive Robot: Difference between revisions
(Starts nodegraph bit) |
No edit summary |
||
Line 16: | Line 16: | ||
By adding the H-Bridge Motor IO Units, the [[Chip Node]] in the [[Nodegraph Editor]] gains 2 new inputs and 2 new outputs: | By adding the H-Bridge Motor IO Units, the [[Chip Node]] in the [[Nodegraph Editor]] gains 2 new inputs and 2 new outputs: | ||
[[File:Chip Node with Default IO.png|center|thumb|437x437px|The Chip Node gets a pair of "<motor name> armed" output and "<motor name>" inputs, allowing you to drive the motors and get their status.]] | [[File:Chip Node with Default IO.png|center|thumb|437x437px|The Chip Node gets a pair of "<motor name> armed" output and "<motor name>" inputs, allowing you to drive the motors and get their status.]] | ||
The two input ports - here named "M1" and "M2" (because that's the name of each motor in the IO Configuration) - drive each motor. They expect values between 0 and 1, with 0 being "full reverse" and 1 being "full forward". The two outputs - here named "M1 armed" and "M2 armed" - indicate whether the motors are [[IO Config Editor#Actuators|armed]]. The concept of actuator arming can feel a little complex, but it is important because without it the chance of accidentally driving a motor is much higher: any actuator is considered "armed" once the actuator has recieved a drive signal corresponding to it's "safe state". In the case of H-Bridge IO Units, the "safe state" is not moving, meaning that the RoboPad ''must'' recieve a value of 0.5 on each of the M1 and M2 input ports before each motor will move in any other way. Without this, it would be possible to (for example) add a signal to the M1 port that constantly fed the port with a value of "1", which would cause the robot to start driving it's M1 wheel immediately as soon as the [[The Controller|controller]] was accessed, which wouldn't be safe. | The two input ports - here named "M1" and "M2" (because that's the name of each motor in the IO Configuration) - drive each motor. They expect values between 0 and 1, with 0 being "full reverse" and 1 being "full forward". The two outputs - here named "M1 armed" and "M2 armed" - indicate whether the motors are [[IO Config Editor#Actuators|armed]]. The concept of actuator arming can feel a little complex, but it is important because without it the chance of accidentally driving a motor is much higher: any actuator is considered "armed" once the actuator has recieved a drive signal corresponding to it's "safe state". In the case of H-Bridge IO Units, the "safe state" is not moving, meaning that the RoboPad ''must'' recieve a value of 0.5 on each of the M1 and M2 input ports before each motor will move in any other way. Without this, it would be possible to (for example) add a signal to the M1 port that constantly fed the port with a value of "1", which would cause the robot to start driving it's M1 wheel immediately as soon as the [[The Controller|controller]] was accessed, which wouldn't be safe: | ||
[[File:Non-Armable Configuration.png|center|thumb|A potentially unsafe RoboPad configuration that is intended to cause the M1 motor to continually drive forward on launch. However, as M1 is a H-Bridge motor, it will never be armed as it requires the value "0.5" (no motion) to be passed to it first, so the unsafe situation is avoided.]] | |||
Fortunately for us, the [[Slider Node]] defaults to emitting the value 0.5, so we can simply connect two Sliders to the M1 and M2 inputs. In the images below, we've hooked them up and positioned them on the [[The Controller|Controller Stage]] so that one is on the left and one on the right: |
Revision as of 01:35, 21 August 2024
A tank-drive robot is the most simple type of robot that you can make with a RoboPad. It is the default configuration that the roboPad is set up for and allows for driving two motors using two sliding sticks (Sliders) - one to control power to the left motor and one to control power to the right motor. This page aims to give you a walk-through of building a robot like.
Hardware
Tank drive robots have only two actuators: A left drive motor and a right drive motor, both attached to a wheel. After attaching your power supply to the "+" and "-" pins, it simply requires that two motors be soldered - one each to the M1 and M2 pin pairs on the RoboPad.
IO Configuration
In order to tell the RoboPad that there are two motors attached, you will need to configure the IO Units on the device. The RoboPad has special IO Units available for drive motors called "Built-in H-Bridge Motor" units. These use the internal H-bridges to drive the motors forwards and backwards:
They allow you tot set a "Forward Scale" and a "Reverse Scale" for each, which lets you change how fast the attached motors spin when told to go all the way forward or backward, which is useful for tuning a robot if it's not driving straight when you tell it to go forward or backward, or just to slow it down if forward or backwards is too fast. They should be there by default, and if not you can add them with the "Add" menu at the top of the IO Configuration page.
Nodegraph Configuration
By adding the H-Bridge Motor IO Units, the Chip Node in the Nodegraph Editor gains 2 new inputs and 2 new outputs:
The two input ports - here named "M1" and "M2" (because that's the name of each motor in the IO Configuration) - drive each motor. They expect values between 0 and 1, with 0 being "full reverse" and 1 being "full forward". The two outputs - here named "M1 armed" and "M2 armed" - indicate whether the motors are armed. The concept of actuator arming can feel a little complex, but it is important because without it the chance of accidentally driving a motor is much higher: any actuator is considered "armed" once the actuator has recieved a drive signal corresponding to it's "safe state". In the case of H-Bridge IO Units, the "safe state" is not moving, meaning that the RoboPad must recieve a value of 0.5 on each of the M1 and M2 input ports before each motor will move in any other way. Without this, it would be possible to (for example) add a signal to the M1 port that constantly fed the port with a value of "1", which would cause the robot to start driving it's M1 wheel immediately as soon as the controller was accessed, which wouldn't be safe:
Fortunately for us, the Slider Node defaults to emitting the value 0.5, so we can simply connect two Sliders to the M1 and M2 inputs. In the images below, we've hooked them up and positioned them on the Controller Stage so that one is on the left and one on the right: