RoboPad Wiki - User contributions [en]

SMRRF 2026 Kit

2026-03-25T09:51:06Z

Blayze: /* Battery Selection */ Adds warning about li-ion batteries' limited power output.

Thank you for picking up a RoboPad kit at SMRRF 2026! On this page you'll find all the information you'll need to get setup like we were at the event.

The kit itself is build around the ''RoboPad'', assembled onto a breakout board that we call the ''EduBoard''. In order to find out more about the RoboPad, checkout the [https://robopad.co.uk/firmware.html user guide] and the rest of [[Main Page|this wiki]]. The RoboPad can be configured to do quite a few things, but by default it is configured to just drive two brushed motors using a simple tank-drive control scheme - this should be enough to get you started, before you begin taking steps to make more complex bots!

Before you start, we recommend that you [https://robopad.co.uk/register register] your product; in doing so, you'll be able to choose to sign up for firmware updates and general product updates, should you want to. These are the best ways of keeping up to date with information on the latest RoboPad [[Firmware Releases|firmware releases]] and feature updates.

== Kit Contents and Quickstart ==
[[File:SMRRF 2026 Kit Components.png|thumb|439x439px|The components in the kit]]
The kit itself only accounts for the electronic components - everything you need to build a simple 2-wheel robot. However, if you took home parts on the day, you may have additional 3D printed parts.

The kit is designed to make it easy to use a 9v battery and a RoboPad to drive two motors. The power switch (3) is separated from the power distribution wire (5) so that you can easily mount the power switch into any 3D printed enclosure (such as the 3D printed print-a-blok switch holder that was used at SMRRF) without having to resolder its connecting wires.

The RoboPad+EduBoard combo allows for easy connection of servo motors and additional outputs should you want to add more later down the line.

To get going with your RoboPad, simply connect the two motors to the "M1" and "M2" headers on the EduBoard breakout (optionally via the extension leads for extra reach), connect a 9v battery to the connector, the switch to the battery connector, and then the battery connector into the JST-XH connector on the EduBoard, and then flick the switch to turn it on. You should see a network with the same name as the one listed on the RoboPad. Connect to it, and navigate to "start.robopad.co.uk" (or "192.168.4.1" if your phone raises an SSL warning) in your phone's browser and start driving.

== Printable Parts ==
The SMRRF 2026 workshop was run in collaboration with [https://www.3dpprofessor.com/ The 3D Printing Professor], facilitated by [https://dreamsvoid.com/ DreamsVoid]. Through this collaboration, we were able to leverage the creativity of the 3D-printable building block system, [https://www.youtube.com/playlist?list=PLVybj_7VBHRJ2tu4gwskeY5XX914GSU9T PrintABlok], as a base for the robots you built! We designed a number of our own PrintABlok parts to support the electrical components available, and DreamsVoid provided kilograms of base parts. If you'd like to 3D print these parts yourself, you can find them below:

* The Blayze Tech [https://www.printables.com/model/1647213-robopad-printablok-parts RoboPad PrintABlok support parts] on Printables
* The Blayze Tech N20 motor/o-ring wheels on Printables
* The 3D Printing Professor's [https://www.3dpprofessor.com/shop/ online store], where you can get the [https://www.3dpprofessor.com/product/printablok-base-set-free/ base PrintABlok parts] and the [https://www.3dpprofessor.com/product/electrobloks-free/ electroBlok parts] for free, as well as many other themed PrintABlok sets at a reasonable price point (we personally are quite excited about his recently released PrintAQuest line)
*DreamsVoid's [https://www.printables.com/model/1304091-printablok-connector-remover connector removal tool] - an incredibly useful tool for when you want to remove PrintABlok connectors

== The RoboPad & EduBoard ==
[[File:RoboPad + EduBoard pinout.png|left|thumb|The pin mappings of a RoboPad mounted onto an EduBoard.]]
The EduBoard is a carrier board for a RoboPad. It provides a secure battery attachment interface via a JST-XH connector and easily accessible headers to attach motors and additional actuators to.

Just like the RoboPad, the board accepts an input power of between 4 and 10v. The polarity of this input power source matches that indicated on the attached RoboPad - that is, positive on the left, with negative (ground) on the right. If you bought your kit on the day, you may notice that the leads on the supplied JST-XH connection cable do not match this colourscheme; however if you received your kit in the post, you will find that they do. In both cases, the correct way to place the JST-XH cable into the power socket is to align it correctly with the socket itself, rather than considering the wiring colours.

On the base RoboPad, additional actuators [[IO Config Editor|can be attached to a number of the exposed pins]]. However, pins E1 and E2 are considered the "default" external pins, as the other pins can exhibit undefined behaviour briefly on device power-up (these pins are defined as "advanced" or "extra" pins). The EduBoard breaks out these two pins, as well as the most stable of extra pins in a format that makes them easily usable alongside typical hobby-grade servos via the 3-pin connectors on the left of the board. As indicated on the board, the left-most pin is a ground pin, the middle is the power input to the servo, and the right is the signal.

Functionally, the signal pin is directly connected to it's respective pin on the base RoboPad board, and provides a 3.3v signal to the connected device. The power pin, however, is selectable via two solderable joints on the rear of the EduBoard. Using one or more of these joints, it is possible to select the maximum voltage that will be provided to the given servos. This can be particularly useful when you are trying to drive a servo that operates at a lower voltage than the input voltage provided to the board itself. For example, when powering a hobby 9v servo that operates at 6v, but with a 9v battery connected, you will want to solder the "5.8v" selector - this will step down the battery's voltage to around 6v, allowing it to safely drive the servo without risk of overvolting it. The combined current draw of these pins is limited to 2.1 amps, so please check the maximum current draw of the actuators you intend to connect before attempting to drive them.

Additionally, servos need not be the only things driven. By ignoring the central "PWR" connector, the Externals headers become generic output pins - you could, for example, connect an LED via from a "SIG" pin to it's respective "GND" pin via a current limiting resistor - then, by configuring the output as a digital or PWM output in the [[IO Config Editor]], you can dynamically control that LED from the UI.

== Tips ==
=== Prints ===
Unlike the base PrintABlok parts which use zip-ties, the bloks that we designed for the SMRRF workshop use compliant clips to hold the components in. These can result in it being a little different to get components in and out:
* Motors should be firmly pushed in with a little more pressure on the rear of the motor first, to ensure proper alignment of the solder joints within the block, followed by force on the front - they will reach a "halfway point" where you will then be able to apply equal pressure to the whole motor.
* Motors can be removed by hand, but this can hurt. Instead, consider printing the Motor remover part from the Printables object, which requires 4 M2 nuts and 2 M2 cylindrical head bolts - the bolts are placed in such a way that they extend into the cavity in the print, and then motor blocks can be slid onto the bolts, with the bolts sliding through the connector holes and pushing the motors out of the blok.
* A flathead screwdriver is useful to remove the EduBoard form it's blok.
* In order to remove 9v batteries from our holder, grip it by the base and top of the battery+connector combo.
If you are struggling to remove wheels from the motor shaft, consider using needle-nose grippers as a lever between the wheel and the motor.

The 3D Printing Professor has a number of electrical-oriented bloks that you may find useful in his ElectroBloks kit - in particular, we found that the humble "wire tidy" block was incredibly useful for cable management on our test robots. He's also got some motor mounts for bigger so-called "yellow" motors, and LEDs.

=== Robot Control and Handling ===
Before changing the nodegraph editor, it can be easier to fix drive control and orientation issues by simply moving or flipping the connectors connected to M1 and M2. In the default configuration, swap the two connectors to swap which slider controls which wheel, and simply unplug, rotate by 180 degrees, and re-plug a connector in to invert the direction the motor drives. Before learning to race around a home-built course, take some time to configure these things first.

If you are finding your robot to be difficult to control due to its speed, before editing the nodegraph, consider going to the [[IO Config Editor|IO Configuration Editor]] and turning down the forward and reverse scales on the two default built-in H-bridge motor IO Units that are linked to the M1 and M2 ports on the EduBoard first.

By default, RoboPads are configured with tank-drive (two sliders, with each controlling a single motor). While this gives a very intuitive understanding of how the robot works, and makes for easy debugging, it is ''not'' a very intuitive control scheme. Consider opening the nodegraph editor and trying to configure a [[Example: Simple Joystick-Drive Robot|joystick control]], or for more fine-grained control, plug in a USB controller and configure a [[Gamepad Node]] to work with it.

=== Battery Selection ===
The kits that we sold on the day only provided 9v battery connectors, as unfortunately selling and posting batteries is not something that we can currently offer. However, should you wish to source and upgrade your battery yourself, here are some tips.

The RoboPad accepts anywhere from 4v to 10v as input, meaning that 9v, 4/6x AAs, 2S lithium polymer or 2S lithium ion batteries can be used. During the event, we used 2S lithium ion batteries, as they lasted long and posed a lower puncture risk than lithium polymer batteries. Specifically, we used [https://www.amazon.co.uk/Pinsinholy-2000mAh-Rechargeable-Capacity-Batteries/dp/B0CZL6VMSM toy RC car batteries] that allowed us to swap out the batteries for replacement - these were good, however in our post-event testing we did notice that they lack the required power output to reliably support rapid movements from standing to full-speed. However, if driving the bot under normal circumstances, this kind of movement rarely occurs (we were only able to replicate it with our automated QA system).

In combat robotics, as the RoboPad is built for, we typically use 2s lithium polymer batteries for their smaller sizes. However, they can quickly run too low to be succesfully recharged, so are better suited to short stints of usage. They also pose a fairly significant puncture/fire risk. '''Please use care when using or handling any battery and if in doubt, seek experienced help.'''

The RoboPad does not currently implement a battery protection low-voltage cut-off, however in the near future we aim to implement a battery level sensor as part of the available IO units (this will be released as a firmware update).

SMRRF 2026 Kit

2026-03-24T02:26:35Z

Blayze: /* Tips */ Adds battery info.

Thank you for picking up a RoboPad kit at SMRRF 2026! On this page you'll find all the information you'll need to get setup like we were at the event.

The kit itself is build around the ''RoboPad'', assembled onto a breakout board that we call the ''EduBoard''. In order to find out more about the RoboPad, checkout the [https://robopad.co.uk/firmware.html user guide] and the rest of [[Main Page|this wiki]]. The RoboPad can be configured to do quite a few things, but by default it is configured to just drive two brushed motors using a simple tank-drive control scheme - this should be enough to get you started, before you begin taking steps to make more complex bots!

Before you start, we recommend that you [https://robopad.co.uk/register register] your product; in doing so, you'll be able to choose to sign up for firmware updates and general product updates, should you want to. These are the best ways of keeping up to date with information on the latest RoboPad [[Firmware Releases|firmware releases]] and feature updates.

== Kit Contents and Quickstart ==
[[File:SMRRF 2026 Kit Components.png|thumb|439x439px|The components in the kit]]
The kit itself only accounts for the electronic components - everything you need to build a simple 2-wheel robot. However, if you took home parts on the day, you may have additional 3D printed parts.

The kit is designed to make it easy to use a 9v battery and a RoboPad to drive two motors. The power switch (3) is separated from the power distribution wire (5) so that you can easily mount the power switch into any 3D printed enclosure (such as the 3D printed print-a-blok switch holder that was used at SMRRF) without having to resolder its connecting wires.

The RoboPad+EduBoard combo allows for easy connection of servo motors and additional outputs should you want to add more later down the line.

To get going with your RoboPad, simply connect the two motors to the "M1" and "M2" headers on the EduBoard breakout (optionally via the extension leads for extra reach), connect a 9v battery to the connector, the switch to the battery connector, and then the battery connector into the JST-XH connector on the EduBoard, and then flick the switch to turn it on. You should see a network with the same name as the one listed on the RoboPad. Connect to it, and navigate to "start.robopad.co.uk" (or "192.168.4.1" if your phone raises an SSL warning) in your phone's browser and start driving.

== Printable Parts ==
The SMRRF 2026 workshop was run in collaboration with [https://www.3dpprofessor.com/ The 3D Printing Professor], facilitated by [https://dreamsvoid.com/ DreamsVoid]. Through this collaboration, we were able to leverage the creativity of the 3D-printable building block system, [https://www.youtube.com/playlist?list=PLVybj_7VBHRJ2tu4gwskeY5XX914GSU9T PrintABlok], as a base for the robots you built! We designed a number of our own PrintABlok parts to support the electrical components available, and DreamsVoid provided kilograms of base parts. If you'd like to 3D print these parts yourself, you can find them below:

* The Blayze Tech [https://www.printables.com/model/1647213-robopad-printablok-parts RoboPad PrintABlok support parts] on Printables
* The Blayze Tech N20 motor/o-ring wheels on Printables
* The 3D Printing Professor's [https://www.3dpprofessor.com/shop/ online store], where you can get the [https://www.3dpprofessor.com/product/printablok-base-set-free/ base PrintABlok parts] and the [https://www.3dpprofessor.com/product/electrobloks-free/ electroBlok parts] for free, as well as many other themed PrintABlok sets at a reasonable price point (we personally are quite excited about his recently released PrintAQuest line)
*DreamsVoid's [https://www.printables.com/model/1304091-printablok-connector-remover connector removal tool] - an incredibly useful tool for when you want to remove PrintABlok connectors

== The RoboPad & EduBoard ==
[[File:RoboPad + EduBoard pinout.png|left|thumb|The pin mappings of a RoboPad mounted onto an EduBoard.]]
The EduBoard is a carrier board for a RoboPad. It provides a secure battery attachment interface via a JST-XH connector and easily accessible headers to attach motors and additional actuators to.

Just like the RoboPad, the board accepts an input power of between 4 and 10v. The polarity of this input power source matches that indicated on the attached RoboPad - that is, positive on the left, with negative (ground) on the right. If you bought your kit on the day, you may notice that the leads on the supplied JST-XH connection cable do not match this colourscheme; however if you received your kit in the post, you will find that they do. In both cases, the correct way to place the JST-XH cable into the power socket is to align it correctly with the socket itself, rather than considering the wiring colours.

On the base RoboPad, additional actuators [[IO Config Editor|can be attached to a number of the exposed pins]]. However, pins E1 and E2 are considered the "default" external pins, as the other pins can exhibit undefined behaviour briefly on device power-up (these pins are defined as "advanced" or "extra" pins). The EduBoard breaks out these two pins, as well as the most stable of extra pins in a format that makes them easily usable alongside typical hobby-grade servos via the 3-pin connectors on the left of the board. As indicated on the board, the left-most pin is a ground pin, the middle is the power input to the servo, and the right is the signal.

Functionally, the signal pin is directly connected to it's respective pin on the base RoboPad board, and provides a 3.3v signal to the connected device. The power pin, however, is selectable via two solderable joints on the rear of the EduBoard. Using one or more of these joints, it is possible to select the maximum voltage that will be provided to the given servos. This can be particularly useful when you are trying to drive a servo that operates at a lower voltage than the input voltage provided to the board itself. For example, when powering a hobby 9v servo that operates at 6v, but with a 9v battery connected, you will want to solder the "5.8v" selector - this will step down the battery's voltage to around 6v, allowing it to safely drive the servo without risk of overvolting it. The combined current draw of these pins is limited to 2.1 amps, so please check the maximum current draw of the actuators you intend to connect before attempting to drive them.

Additionally, servos need not be the only things driven. By ignoring the central "PWR" connector, the Externals headers become generic output pins - you could, for example, connect an LED via from a "SIG" pin to it's respective "GND" pin via a current limiting resistor - then, by configuring the output as a digital or PWM output in the [[IO Config Editor]], you can dynamically control that LED from the UI.

== Tips ==
=== Prints ===
Unlike the base PrintABlok parts which use zip-ties, the bloks that we designed for the SMRRF workshop use compliant clips to hold the components in. These can result in it being a little different to get components in and out:
* Motors should be firmly pushed in with a little more pressure on the rear of the motor first, to ensure proper alignment of the solder joints within the block, followed by force on the front - they will reach a "halfway point" where you will then be able to apply equal pressure to the whole motor.
* Motors can be removed by hand, but this can hurt. Instead, consider printing the Motor remover part from the Printables object, which requires 4 M2 nuts and 2 M2 cylindrical head bolts - the bolts are placed in such a way that they extend into the cavity in the print, and then motor blocks can be slid onto the bolts, with the bolts sliding through the connector holes and pushing the motors out of the blok.
* A flathead screwdriver is useful to remove the EduBoard form it's blok.
* In order to remove 9v batteries from our holder, grip it by the base and top of the battery+connector combo.
If you are struggling to remove wheels from the motor shaft, consider using needle-nose grippers as a lever between the wheel and the motor.

The 3D Printing Professor has a number of electrical-oriented bloks that you may find useful in his ElectroBloks kit - in particular, we found that the humble "wire tidy" block was incredibly useful for cable management on our test robots. He's also got some motor mounts for bigger so-called "yellow" motors, and LEDs.

=== Robot Control and Handling ===
Before changing the nodegraph editor, it can be easier to fix drive control and orientation issues by simply moving or flipping the connectors connected to M1 and M2. In the default configuration, swap the two connectors to swap which slider controls which wheel, and simply unplug, rotate by 180 degrees, and re-plug a connector in to invert the direction the motor drives. Before learning to race around a home-built course, take some time to configure these things first.

If you are finding your robot to be difficult to control due to its speed, before editing the nodegraph, consider going to the [[IO Config Editor|IO Configuration Editor]] and turning down the forward and reverse scales on the two default built-in H-bridge motor IO Units that are linked to the M1 and M2 ports on the EduBoard first.

By default, RoboPads are configured with tank-drive (two sliders, with each controlling a single motor). While this gives a very intuitive understanding of how the robot works, and makes for easy debugging, it is ''not'' a very intuitive control scheme. Consider opening the nodegraph editor and trying to configure a [[Example: Simple Joystick-Drive Robot|joystick control]], or for more fine-grained control, plug in a USB controller and configure a [[Gamepad Node]] to work with it.

=== Battery Selection ===
The kits that we sold on the day only provided 9v battery connectors, as unfortunately selling and posting batteries is not something that we can currently offer. However, should you wish to source and upgrade your battery yourself, here are some tips.

The RoboPad accepts anywhere from 4v to 10v as input, meaning that 9v, 4/6x AAs, 2S lithium polymer or 2S lithium ion batteries can be used. During the event, we used 2S lithium ion batteries, as they lasted long and posed a lower puncture risk than lithium polymer batteries. Specifically, we used [https://www.amazon.co.uk/Pinsinholy-2000mAh-Rechargeable-Capacity-Batteries/dp/B0CZL6VMSM toy RC car batteries]. that allowed us to swap out the batteries for replacement.

In combat robotics, as the RoboPad is built for, we typically use 2s lithium polymer batteries for their smaller sizes. However, they can quickly run too low to be succesfully recharged, so are better suited to short stints of usage. They also pose a fairly significant puncture/fire risk. '''Please use care when using or handling any battery and if in doubt, seek experienced help.'''

The RoboPad does not currently implement a battery protection low-voltage cut-off, however in the near future we aim to implement a battery level sensor as part of the available IO units (this will be released as a firmware update).

SMRRF 2026 Kit

2026-03-24T02:15:40Z

Blayze: /* Tips */ Adds Robot control and handling subsection to Tips

Thank you for picking up a RoboPad kit at SMRRF 2026! On this page you'll find all the information you'll need to get setup like we were at the event.

The kit itself is build around the ''RoboPad'', assembled onto a breakout board that we call the ''EduBoard''. In order to find out more about the RoboPad, checkout the [https://robopad.co.uk/firmware.html user guide] and the rest of [[Main Page|this wiki]]. The RoboPad can be configured to do quite a few things, but by default it is configured to just drive two brushed motors using a simple tank-drive control scheme - this should be enough to get you started, before you begin taking steps to make more complex bots!

Before you start, we recommend that you [https://robopad.co.uk/register register] your product; in doing so, you'll be able to choose to sign up for firmware updates and general product updates, should you want to. These are the best ways of keeping up to date with information on the latest RoboPad [[Firmware Releases|firmware releases]] and feature updates.

== Kit Contents and Quickstart ==
[[File:SMRRF 2026 Kit Components.png|thumb|439x439px|The components in the kit]]
The kit itself only accounts for the electronic components - everything you need to build a simple 2-wheel robot. However, if you took home parts on the day, you may have additional 3D printed parts.

The kit is designed to make it easy to use a 9v battery and a RoboPad to drive two motors. The power switch (3) is separated from the power distribution wire (5) so that you can easily mount the power switch into any 3D printed enclosure (such as the 3D printed print-a-blok switch holder that was used at SMRRF) without having to resolder its connecting wires.

The RoboPad+EduBoard combo allows for easy connection of servo motors and additional outputs should you want to add more later down the line.

To get going with your RoboPad, simply connect the two motors to the "M1" and "M2" headers on the EduBoard breakout (optionally via the extension leads for extra reach), connect a 9v battery to the connector, the switch to the battery connector, and then the battery connector into the JST-XH connector on the EduBoard, and then flick the switch to turn it on. You should see a network with the same name as the one listed on the RoboPad. Connect to it, and navigate to "start.robopad.co.uk" (or "192.168.4.1" if your phone raises an SSL warning) in your phone's browser and start driving.

== Printable Parts ==
The SMRRF 2026 workshop was run in collaboration with [https://www.3dpprofessor.com/ The 3D Printing Professor], facilitated by [https://dreamsvoid.com/ DreamsVoid]. Through this collaboration, we were able to leverage the creativity of the 3D-printable building block system, [https://www.youtube.com/playlist?list=PLVybj_7VBHRJ2tu4gwskeY5XX914GSU9T PrintABlok], as a base for the robots you built! We designed a number of our own PrintABlok parts to support the electrical components available, and DreamsVoid provided kilograms of base parts. If you'd like to 3D print these parts yourself, you can find them below:

* The Blayze Tech [https://www.printables.com/model/1647213-robopad-printablok-parts RoboPad PrintABlok support parts] on Printables
* The Blayze Tech N20 motor/o-ring wheels on Printables
* The 3D Printing Professor's [https://www.3dpprofessor.com/shop/ online store], where you can get the [https://www.3dpprofessor.com/product/printablok-base-set-free/ base PrintABlok parts] and the [https://www.3dpprofessor.com/product/electrobloks-free/ electroBlok parts] for free, as well as many other themed PrintABlok sets at a reasonable price point (we personally are quite excited about his recently released PrintAQuest line)
*DreamsVoid's [https://www.printables.com/model/1304091-printablok-connector-remover connector removal tool] - an incredibly useful tool for when you want to remove PrintABlok connectors

== The RoboPad & EduBoard ==
[[File:RoboPad + EduBoard pinout.png|left|thumb|The pin mappings of a RoboPad mounted onto an EduBoard.]]
The EduBoard is a carrier board for a RoboPad. It provides a secure battery attachment interface via a JST-XH connector and easily accessible headers to attach motors and additional actuators to.

Just like the RoboPad, the board accepts an input power of between 4 and 10v. The polarity of this input power source matches that indicated on the attached RoboPad - that is, positive on the left, with negative (ground) on the right. If you bought your kit on the day, you may notice that the leads on the supplied JST-XH connection cable do not match this colourscheme; however if you received your kit in the post, you will find that they do. In both cases, the correct way to place the JST-XH cable into the power socket is to align it correctly with the socket itself, rather than considering the wiring colours.

On the base RoboPad, additional actuators [[IO Config Editor|can be attached to a number of the exposed pins]]. However, pins E1 and E2 are considered the "default" external pins, as the other pins can exhibit undefined behaviour briefly on device power-up (these pins are defined as "advanced" or "extra" pins). The EduBoard breaks out these two pins, as well as the most stable of extra pins in a format that makes them easily usable alongside typical hobby-grade servos via the 3-pin connectors on the left of the board. As indicated on the board, the left-most pin is a ground pin, the middle is the power input to the servo, and the right is the signal.

Functionally, the signal pin is directly connected to it's respective pin on the base RoboPad board, and provides a 3.3v signal to the connected device. The power pin, however, is selectable via two solderable joints on the rear of the EduBoard. Using one or more of these joints, it is possible to select the maximum voltage that will be provided to the given servos. This can be particularly useful when you are trying to drive a servo that operates at a lower voltage than the input voltage provided to the board itself. For example, when powering a hobby 9v servo that operates at 6v, but with a 9v battery connected, you will want to solder the "5.8v" selector - this will step down the battery's voltage to around 6v, allowing it to safely drive the servo without risk of overvolting it. The combined current draw of these pins is limited to 2.1 amps, so please check the maximum current draw of the actuators you intend to connect before attempting to drive them.

Additionally, servos need not be the only things driven. By ignoring the central "PWR" connector, the Externals headers become generic output pins - you could, for example, connect an LED via from a "SIG" pin to it's respective "GND" pin via a current limiting resistor - then, by configuring the output as a digital or PWM output in the [[IO Config Editor]], you can dynamically control that LED from the UI.

== Tips ==
Tips on motor removal, wheel generation + printing, course building and battery selection/upgrading to come here.

=== Prints ===
Unlike the base PrintABlok parts which use zip-ties, the bloks that we designed for the SMRRF workshop use compliant clips to hold the components in. These can result in it being a little different to get components in and out:
* Motors should be firmly pushed in with a little more pressure on the rear of the motor first, to ensure proper alignment of the solder joints within the block, followed by force on the front - they will reach a "halfway point" where you will then be able to apply equal pressure to the whole motor.
* Motors can be removed by hand, but this can hurt. Instead, consider printing the Motor remover part from the Printables object, which requires 4 M2 nuts and 2 M2 cylindrical head bolts - the bolts are placed in such a way that they extend into the cavity in the print, and then motor blocks can be slid onto the bolts, with the bolts sliding through the connector holes and pushing the motors out of the blok.
* A flathead screwdriver is useful to remove the EduBoard form it's blok.
* In order to remove 9v batteries from our holder, grip it by the base and top of the battery+connector combo.
If you are struggling to remove wheels from the motor shaft, consider using needle-nose grippers as a lever between the wheel and the motor.

The 3D Printing Professor has a number of electrical-oriented bloks that you may find useful in his ElectroBloks kit - in particular, we found that the humble "wire tidy" block was incredibly useful for cable management on our test robots. He's also got some motor mounts for bigger so-called "yellow" motors, and LEDs.

=== Robot Control and Handling ===
Before changing the nodegraph editor, it can be easier to fix drive control and orientation issues by simply moving or flipping the connectors connected to M1 and M2. In the default configuration, swap the two connectors to swap which slider controls which wheel, and simply unplug, rotate by 180 degrees, and re-plug a connector in to invert the direction the motor drives. Before learning to race around a home-built course, take some time to configure these things first.

If you are finding your robot to be difficult to control due to its speed, before editing the nodegraph, consider going to the [[IO Config Editor|IO Configuration Editor]] and turning down the forward and reverse scales on the two default built-in H-bridge motor IO Units that are linked to the M1 and M2 ports on the EduBoard first.

By default, RoboPads are configured with tank-drive (two sliders, with each controlling a single motor). While this gives a very intuitive understanding of how the robot works, and makes for easy debugging, it is ''not'' a very intuitive control scheme. Consider opening the nodegraph editor and trying to configure a [[Example: Simple Joystick-Drive Robot|joystick control]], or for more fine-grained control, plug in a USB controller and configure a [[Gamepad Node]] to work with it.

=== Battery Selection ===

SMRRF 2026 Kit

2026-03-24T02:04:08Z

Blayze: /* Tips */ Adds first set of tips

Thank you for picking up a RoboPad kit at SMRRF 2026! On this page you'll find all the information you'll need to get setup like we were at the event.

The kit itself is build around the ''RoboPad'', assembled onto a breakout board that we call the ''EduBoard''. In order to find out more about the RoboPad, checkout the [https://robopad.co.uk/firmware.html user guide] and the rest of [[Main Page|this wiki]]. The RoboPad can be configured to do quite a few things, but by default it is configured to just drive two brushed motors using a simple tank-drive control scheme - this should be enough to get you started, before you begin taking steps to make more complex bots!

Before you start, we recommend that you [https://robopad.co.uk/register register] your product; in doing so, you'll be able to choose to sign up for firmware updates and general product updates, should you want to. These are the best ways of keeping up to date with information on the latest RoboPad [[Firmware Releases|firmware releases]] and feature updates.

== Kit Contents and Quickstart ==
[[File:SMRRF 2026 Kit Components.png|thumb|439x439px|The components in the kit]]
The kit itself only accounts for the electronic components - everything you need to build a simple 2-wheel robot. However, if you took home parts on the day, you may have additional 3D printed parts.

The kit is designed to make it easy to use a 9v battery and a RoboPad to drive two motors. The power switch (3) is separated from the power distribution wire (5) so that you can easily mount the power switch into any 3D printed enclosure (such as the 3D printed print-a-blok switch holder that was used at SMRRF) without having to resolder its connecting wires.

The RoboPad+EduBoard combo allows for easy connection of servo motors and additional outputs should you want to add more later down the line.

To get going with your RoboPad, simply connect the two motors to the "M1" and "M2" headers on the EduBoard breakout (optionally via the extension leads for extra reach), connect a 9v battery to the connector, the switch to the battery connector, and then the battery connector into the JST-XH connector on the EduBoard, and then flick the switch to turn it on. You should see a network with the same name as the one listed on the RoboPad. Connect to it, and navigate to "start.robopad.co.uk" (or "192.168.4.1" if your phone raises an SSL warning) in your phone's browser and start driving.

== Printable Parts ==
The SMRRF 2026 workshop was run in collaboration with [https://www.3dpprofessor.com/ The 3D Printing Professor], facilitated by [https://dreamsvoid.com/ DreamsVoid]. Through this collaboration, we were able to leverage the creativity of the 3D-printable building block system, [https://www.youtube.com/playlist?list=PLVybj_7VBHRJ2tu4gwskeY5XX914GSU9T PrintABlok], as a base for the robots you built! We designed a number of our own PrintABlok parts to support the electrical components available, and DreamsVoid provided kilograms of base parts. If you'd like to 3D print these parts yourself, you can find them below:

* The Blayze Tech [https://www.printables.com/model/1647213-robopad-printablok-parts RoboPad PrintABlok support parts] on Printables
* The Blayze Tech N20 motor/o-ring wheels on Printables
* The 3D Printing Professor's [https://www.3dpprofessor.com/shop/ online store], where you can get the [https://www.3dpprofessor.com/product/printablok-base-set-free/ base PrintABlok parts] and the [https://www.3dpprofessor.com/product/electrobloks-free/ electroBlok parts] for free, as well as many other themed PrintABlok sets at a reasonable price point (we personally are quite excited about his recently released PrintAQuest line)
*DreamsVoid's [https://www.printables.com/model/1304091-printablok-connector-remover connector removal tool] - an incredibly useful tool for when you want to remove PrintABlok connectors

== The RoboPad & EduBoard ==
[[File:RoboPad + EduBoard pinout.png|left|thumb|The pin mappings of a RoboPad mounted onto an EduBoard.]]
The EduBoard is a carrier board for a RoboPad. It provides a secure battery attachment interface via a JST-XH connector and easily accessible headers to attach motors and additional actuators to.

Just like the RoboPad, the board accepts an input power of between 4 and 10v. The polarity of this input power source matches that indicated on the attached RoboPad - that is, positive on the left, with negative (ground) on the right. If you bought your kit on the day, you may notice that the leads on the supplied JST-XH connection cable do not match this colourscheme; however if you received your kit in the post, you will find that they do. In both cases, the correct way to place the JST-XH cable into the power socket is to align it correctly with the socket itself, rather than considering the wiring colours.

On the base RoboPad, additional actuators [[IO Config Editor|can be attached to a number of the exposed pins]]. However, pins E1 and E2 are considered the "default" external pins, as the other pins can exhibit undefined behaviour briefly on device power-up (these pins are defined as "advanced" or "extra" pins). The EduBoard breaks out these two pins, as well as the most stable of extra pins in a format that makes them easily usable alongside typical hobby-grade servos via the 3-pin connectors on the left of the board. As indicated on the board, the left-most pin is a ground pin, the middle is the power input to the servo, and the right is the signal.

Functionally, the signal pin is directly connected to it's respective pin on the base RoboPad board, and provides a 3.3v signal to the connected device. The power pin, however, is selectable via two solderable joints on the rear of the EduBoard. Using one or more of these joints, it is possible to select the maximum voltage that will be provided to the given servos. This can be particularly useful when you are trying to drive a servo that operates at a lower voltage than the input voltage provided to the board itself. For example, when powering a hobby 9v servo that operates at 6v, but with a 9v battery connected, you will want to solder the "5.8v" selector - this will step down the battery's voltage to around 6v, allowing it to safely drive the servo without risk of overvolting it. The combined current draw of these pins is limited to 2.1 amps, so please check the maximum current draw of the actuators you intend to connect before attempting to drive them.

Additionally, servos need not be the only things driven. By ignoring the central "PWR" connector, the Externals headers become generic output pins - you could, for example, connect an LED via from a "SIG" pin to it's respective "GND" pin via a current limiting resistor - then, by configuring the output as a digital or PWM output in the [[IO Config Editor]], you can dynamically control that LED from the UI.

== Tips ==
Tips on motor removal, wheel generation + printing, course building and battery selection/upgrading to come here.

=== Prints ===

* Unlike the base PrintABlok parts which use zip-ties, the bloks that we designed for the SMRRF workshop use compliant clips to hold the components in. These can result in it being a little different to get components in and out.
** Motors should be firmly pushed in with a little more pressure on the rear of the motor first, to ensure proper alignment of the solder joints within the block, followed by force on the front - they will reach a "halfway point" where you will then be able to apply equal pressure to the whole motor.
** Motors can be removed by hand, but this can hurt. Instead, consider printing the Motor remover part from the Printables object, which requires 4 M2 nuts and 2 M2 cylindrical head bolts - the bolts are placed in such a way that they extend into the cavity in the print, and then motor blocks can be slid onto the bolts, with the bolts sliding through the connector holes and pushing the motors out of the blok.
** A flathead screwdriver is useful to remove the EduBoard form it's blok.
** In order to remove 9v batteries from our holder, grip it by the base and top of the battery+connector combo.
* If you are struggling to remove wheels from the motor shaft, consider using needle-nose grippers as a lever between the wheel and the motor.
* The 3D Printing Professor has a number of electrical-oriented bloks that you may find useful in his ElectroBloks kit - in particular, we found that the humble "wire tidy" block was incredibly useful for cable management on our test robots. He's also got some motor mounts for bigger so-called "yellow" motors, and LEDs.

SMRRF 2026 Kit

2026-03-24T01:54:39Z

Blayze: /* The RoboPad & EduBoard */

File:RoboPad + EduBoard pinout.png

2026-03-24T01:36:54Z

2026-03-23T01:28:37Z

Blayze:

A labelled diagram of components in the SMRRF 2026 kit.

SMRRF 2026 Kit

2026-03-23T00:07:08Z

Blayze:

2024-09-26T12:26:07Z

Blayze: Creates the TinyBEC page.

IO Config Editor

2024-09-20T12:25:05Z

Blayze: /* Unidirectional Brushless Motor */ Adds notice about ESCs "beeping" non-used motors.

'''''NOTICE: This page consists of information on a feature currently in [[Beta]]. Information is liable to change or be incomplete.'''''

The Input/Output (IO) Configuration Editor page is the page where you can edit the physical IO configuration of the RoboPad board by configuring '''IO Units'''. You can, for instance, set one of the [[:File:Screenshot from 2022-11-06 23-38-46.png|external pins]] to output a digital electronic signal, which can be controlled via the [[Nodegraph Editor|nodegraph]]. It is accessible via the [[The Management Page|Management Page.]]
[[File:The default IO Configuration Editor page 2023-02-19.png|thumb|The default IO Configuration Editor page as of 2023-02-19]]
Each '''IO Unit''' has a number of settings and will add it's own input and output ports to the [[Chip Node]] in the [[Nodegraph Editor|nodegraph]]. Importantly, for actuators, you are able to specify '''safe values''' - these are the values that the IO Unit will default to when the RoboPad looses connection to your phone or you are on any screen other than the controller screen (it's [[emergency stop state]]). It is very important that you understand how your safe values and IO Units in general interact with the physical circuitry you have added to your RoboPad - for instance, if you are adding an additional motor to your robot using a Generic PWM IO Unit, you will most likely want to ensure that it's safe value is set to 0 so that it will turn off in an emergency situation. Some IO Units do not have safe value settings (such as HBridge motors and unidirectional brushless motors) as all of these configurations are configured to turn off by default.

'''Changing the physical configuration of the RoboPad and the behaviour of it's pins using the IO Configuration Editor should be considered an advanced topic - ensure that you have read and fully understand everything on this wiki page and everything you are doing before attempting to change these settings.'''

=== Emergency Stop Behaviour When Changing IO Unit Configuration ===
It is also important to understand that IO Unit safe values '''remain configured''' on the pins they are set to, '''even when removed''' (using the red "x") until either '''another IO Unit is configured to use that pin''' or the '''device is reset'''. This has been done because it is '''not recommended, expected or suggested''' that a user would change the physical configuration of their RoboPad circuit without first powering it down. Therefore, the firmware assumes that the safest thing to do is retain the last set safe value for any given pin until it is told otherwise (or the device is power cycled, at which point unconfigured pins remain at a high-impedance state).

=== "Advanced Pins" ===
Some Pins - namely all pins that are not External 1 and External 2 (marked E1 and E2 respectively on the board) are considered ''Advanced Pins''. This is because they may behave in a way outside of expected behaviour. For instance, many of these pins will output arbitrary signals within the first 500 milliseconds of RoboPad boot and as such should not be used for actuators that may cause harm if they were to unexpectedly move. Others (particularly the "Internal" pins) are already connected to some internal electronics on the RoboPad, such as the built-in HBridge that drives the default M1 and M2 outputs. In order to use these pins, you would have to remove the HBridge from the device (which is not advised and will void the product's guarantee).

== Pins ==
[[File:Screenshot from 2022-11-06 23-38-46.png|thumb|Accessible pins, as they are seen on the RoboPad version 1.1 board.]]
Much like an Arduino, pins are capable of driving a small current (~12mA per pin) at 3.3v to external circuitry, or can sink a small current (~20mA). Below is a list of the different pin names and how they might be used.
[[File:RoboPad 1.3 Pinout.png|thumb|Accessible pins, as they are seen on the RoboPad version 1.2 and 1.3 boards.]]
{| class="wikitable"
|+Pin names, IDs and additional information
!Pin Name
!ID on Board
!Information
|-
|External 1
|E1
|Non-advanced pin.
|-
|External 2
|E2
|Non-advanced pin.
|-
|TX
|T
|The "Transmit" pin when manually reprogramming the RoboPad.
Subject to pseudo-random signal state for the first 500ms after RoboPad boot.
|-
|RX
|R
|The "Recieve" pin when manually reprogramming the RoboPad.
Subject to pseudo-random signal state for the first 500ms after RoboPad boot.
|-
|Safeboot
|SB
|Pulled '''low''' through an on-board 10kΩ resistor, and meant to be connected to the 3.3v pin (pulling it '''high''') at the 4 seconds after boot point to enable [[Safeboot|safeboot.]]
Subject to pseudo-random signal state for the first 500ms after RoboPad boot.
|-
|Program Enable
|PE
|Used along with the TX and RX pins to manually reprogram the RoboPad.
Subject to pseudo-random signal state for the first 500ms after RoboPad boot.
|-
|Unset
|
|When "Unset" is available, the pin may optionally be non-configured. Choosing this option means no pin is used for the particular option.
|-
|Drive Enable
|Internal
|An internal pin used to enable or disable the built-in HBridge chip.
Subject to pseudo-random signal state for the first 500ms after RoboPad boot.
|-
|Drive Pin 1
Forward
|Internal
|An internal pin attached to the built-in HBridge chip.
Subject to pseudo-random signal state for the first 500ms after RoboPad boot.
|-
|Drive Pin 1
Backward
|Internal
|An internal pin attached to the built-in HBridge chip.
Subject to pseudo-random signal state for the first 500ms after RoboPad boot.
|-
|Drive Pin 2
Forward
|Internal
|An internal pin attached to the built-in HBridge chip.
Subject to pseudo-random signal state for the first 500ms after RoboPad boot.
|-
|Drive Pin 2
Backward
|Internal
|An internal pin attached to the built-in HBridge chip.
Subject to pseudo-random signal state for the first 500ms after RoboPad boot.
|}

== IO Units ==
A variety of IO Units can be added that are suitable for a number of uses, all are listed here.
=== Actuators ===
All actuators add input ports to the [[Chip Node]], allowing signals to be passed from the [[Nodegraph Editor|Node Graph]] to each actuator. On top of this, each actuator will create an output port on the Chip Node, usually labelled ending with ''"Armed"'' - this is an indicator of whether or not the actuator is '''armed'''. The signal to any specific actuator ''must'' pass through that actuator's configured '''safe value''' for it to be considered to be '''armed''' - then and only then will the actuator start to process new control signals. As an example, an servo attached using the "PWM Output" with a safety value set to 50% would require a near-50% signal to be sent to it's input before you will be able to see any change in the pin's output.

All actuators output '''3.3 volts''' along their output pins. Make sure that any connected peripherals such as ESCs or H-Bridges operate with 3.3 volt logic.
==== H-Bridge Motor ====
[[File:H-Bridge Motor IO Unit Screenshot 2023-2-20.png|right|frameless|410x410px]]A [[wikipedia:H-bridge|H-Bridge]] is a simple, common circuit that can control the polarity of electricity to an attached electrical component - commonly a motor. In practice this means that a typical brushed DC motor's direction and speed can be controlled from one using two control signals. While you can make one yourself [https://www.robotroom.com/BipolarHBridge.html using transistors] (that site also has a [https://www.robotroom.com/DPDT-Bidirectional-Motor-Switch.html useful example] using switches which might make the concept easier to understand too), they often come in integrated circuit (IC) form factors, such as the Texas Instruments ''L293D'', which packs two H-bridges and comes bundled with some additional features.

Using this IO Unit, the RoboPad will send drive signals suitable for use with a H-bridge through the specified pins (''PinA'' and ''PinB''). It's emergency stop state is to stop all signals and power down associated pins. The nodegraph is expected to supply a value between 0 and 1 to this IO Unit's input port, where 0 is maximum reverse rotation, 0.5 is stationary and 1 is maximum forward rotation. This IO Unit creates an output port (labeled "<name> armed") on the Chip Node that signals high (1) when a control signal has been passed to it that would place it into it's safe state.
* '''Name''': The name of this HBridge motor, basically only changes the name of the motor input port on the Chip Node.
* '''Pin A''': One of the two directional signals needed by H-Bridge chips.
* '''Pin B''': One of the two directional signals needed by H-Bridge chips, signalling the opposite direction from that signalled in ''Pin A.''
* '''Enable Pin''': If set to a value other than "Unset", a high signal will be transmitted whenever the H-Bridge is in use; to be connected to a H-Bridge chip's "enable" pin(s).
* '''Forward Scale''': Scales the forward signal (over 50%) before it is transmitted to the motor signal pins - if your motor drives forward faster than backwards, then you can lower this value.
* '''Reverse Scale''': Scales the backward signal (below 50%) before it is transmitted to the motor signal pins - if your motor drives backwards faster than forwards, then you can lower this value.

==== Built-in H-Bridge Motor ====
[[File:Built-in H-Bridge Motor 2023-02-20-b.png|right|frameless|410x410px|The Built-In H-Bridge Motor IO Unit UI]]The "Built-in H-Bridge Motor" IO unit is a specialised version of the "H-Bridge Motor" above, specifically designed to work only with the two built-in H-Bridges on the RoboPad, allowing you to select motors to be attached to the ''M1'' and ''M2'' pin pairs on the board. By default, two of these are configured, one for M1 and one for M2. When in the [[emergency stop state]], these IO Units attempt to send a stop signal to any attached motors, not powering any associated pins. Just as in the "H-Bridge Motor" IO Unit, the nodegraph is expected to supply a value between 0 and 1 to this IO Unit's input port, where 0 is maximum reverse rotation, 0.5 is stationary and 1 is maximum forward rotation. This IO Unit creates an output port (labeled "<name> armed") on the Chip Node that signals high (1) when a control signal has been passed to it that would place it into it's safe state.
* '''Name''': The name of this HBridge motor, basically only changes the name of the motor input port on the Chip Node.
* '''Built-in Motor''': Which of the two built-in motor pins this H-Bridge Motor IO Unit references - M1 connects to the M1 pins, M2 to the M2 pins.
* '''Forward Scale''': Scales the forward signal (over 50%) before it is transmitted to the motor signal pins - if your motor drives forward faster than backwards, then you can lower this value.
* '''Backward Scale''': Scales the backward signal (below 50%) before it is transmitted to the motor signal pins - if your motor drives backwards faster than forwards, then you can lower this value.
==== Unidirectional Brushless Motor ====
[[File:UniBrushless 2023-02-21.png|right|frameless|410x410px]]
A [[wikipedia:Brushless_DC_electric_motor|brushless motor]] is a type of motor that uses many (usually three) electromagnetic circuits, pulsed in a specific sequence to generate a moving magnetic field - this field then "pulls" the motor's magnetised rotor with it, allowing for rotation without direct electrical contact (as is found in brushed motors, where metal brushes must transfer power directly to the rotor), resulting in motors that are less prone to wear and generally operate more smoothly and efficiently. The downside of this is that they require [[wikipedia:Electronic_speed_control|electronic speed controllers (ESCs)]] to be driven, which are circuits containing microprocessors that power the motor's coils in the correct sequential pattern. These ESCs take in a control signal, and will often require an arming sequence before they start to energise the motor's coils.

The "Unidirectional Brushless Motor" IO Unit allows the RoboPad to send drive signals (much as a traditional RC radio receiver would) suitable for reception by an ESC that can accept a PWM control signal, and will automatically send thvcbe configured arming sequence beforehand in order to initialise the ESC ready for motor control. Note that this only configures one pin as a control signal pin, and as such is designed to work with ''unidirectional'' brushless motor ESCs, i.e. ESCs that allow a single motor to be driven in a single direction at varying speeds. An incoming nodegraph signal of 0 results in the minimum microseconds signal being sent to the ESC, while an incoming nodegraph signal of 1 results in the maximum microseconds signal being sent to the ESC. This IO Unit creates an output port (labeled "<name> armed") on the Chip Node that signals high (1) when a control signal has been passed to it that would place it into it's safe state.

* '''Name''': The name of this brushless motor, basically only changes the name of the motor input port on the Chip Node.
* '''Pin''': Which pin will generate the ESC control signal.
* '''Minimum Microseconds [''Advanced'']''': The minimum value the PWM control signal generated has (i.e. what it has when a 0/low signal is sent to the IO Unit via the nodegraph). '''Only change this if you know what you are doing!'''
* '''Maximum Microseconds [''Advanced'']''': The maximum value the PWM control signal generated has (i.e. what it has when a 1/high signal is sent to the IO Unit via the nodegraph). '''Only change this if you know what you are doing!'''
* '''Arm Sequence''': The sequence of signals that must be sent to the ESC to arm it. Refer to your ESC's manual to understand it's arming sequence and select the appropriate option here. If none match, [https://robopad.co.uk/contact.html drop us a line and tell us].
''Note:'' Many ESCs will emit a "standby" noise if you have them armed but not in use for a prolonged time. This is usually expressed as the motor spinning small amounts to beep every few seconds.

==== Servo Motor ====
[[File:Servo 2023-02-22.png|right|frameless|410x410px]]
A [[wikipedia:Servomotor|servo motor]] is a motor/control board combination integrated circuit that takes a control signal and actuates to a position within its range of movement that aligns with the received signal.

The "Servo Motor" IO Unit allows the RoboPad to send PWM drive signals that a servo motor can interpret. While the control signal provided by the RoboPad is at 3.3v and as such should work fine under most common servos, they will require their own power supply - some servos accept a range of input voltages and will be suitable to power directly from your robot's power source (such as a battery), but others will require power circuitry to ensure that you are providing them a safe and expected voltage. In a similar vein, make sure that you can provide the appropriate voltage and currant to your servo motor. The ''5v'' output pin of the RoboPad is only rated up to 500mA (and it already powers the built-in Dual H-Bridge), and many servos will require either a higher voltage or draw a higher current, which could damage the board. '''Always refer to your motor's manual and/or technical information and verify that it will work with the rest of your electrical circuit.''' This IO Unit creates an output port (labeled "<name> armed") on the Chip Node that signals high (1) when a control signal has been passed to it that would place it into it's safe state.

* '''Name''': The name of this servo motor, basically only changes the name of the motor input port on the Chip Node.
* '''Pin''': Which pin will generate the PWM control signal.
* '''Minimum Microseconds''': The minimum value the PWM control signal generated has (i.e. what it has when a 0/low signal is sent to the IO Unit via the nodegraph). '''Only change this if you know what you are doing!'''
* '''Maximum Microseconds''': The maximum value the PWM control signal generated has (i.e. what it has when a 1/high signal is sent to the IO Unit via the nodegraph). '''Only change this if you know what you are doing!'''
* '''Disconnect Behaviour''': What this IO Unit should do in the [[emergency stop state]]. By default this is "Stay in place" meaning that the control signal will remain at what it last sent - this makes sense for most servo-based actuators as in an emergency stop state, you would not want the servo moving. However, in some cases you may want the servo to move to a pre-defined position. In that case this can be set to "Return to disconnect %" which will set the servo control signal to ''Disconnect Percent'' (defined below) in the emergency stop state.
* '''Disconnect Percent''': The percent, relative from the ''minimum microseconds'' value (0%) to the ''maximum microseconds'' value (100%) to return to when entering the [[emergency stop state]] if ''Disconnect Behaviour'' is set to "Return to disconnect %".

==== Digital Output ====
[[File:Digital Output 2023-02-22.png|right|frameless|410x410px]]
The simplest IO Unit actuator, the "Digital Out" IO Unit sets a physical pin as a binary digital output, similar to those you might find on an [https://reference.arduino.cc/reference/en/language/functions/digital-io/digitalwrite/ arduino]. As a control signal comes into the IO Unit via the nodegraph, if the value is over 0.5 then a logical high (at 3.3 volts) is sent out of the selected pin, if the value is below 0.5 then a logical low (at 0 volts) is sent out of the selected pin. When you are driving external devices (such as LEDs, motors, etc), remember that the pins can only drive a small current (chip specifications recommend ~12mA source, ~20mA sink) so you may want to use a [[wikipedia:Transistor|transistor]] to drive heavier loads. This IO Unit creates an output port (labeled "<name> armed") on the Chip Node that signals high (1) when a control signal has been passed to it that would place it into it's safe state.

* '''Name''': The name of this digital output, basically only changes the name of the input port on the Chip Node.
* '''Pin''': Which pin will generate the digital signal.
* '''Safety Value''': What value to output when in the [[emergency stop state]] if the ''Stop Behaviour'' is configured as "Return to safe".
* '''Stop Behaviour''': What this IO Unit should do when the RoboPad goes into the [[emergency stop state]]. By default "Return to safe", meaning that it will transmit the value set in ''Safety Value''.

==== PWM Output ====
[[File:PWM Output IO Unit.png|right|frameless|410x410px]]
The "PWM Output" IO Unit sets a physical pin as a PWM pseudo-analog output, similar to those you can configure on an [https://docs.arduino.cc/learn/microcontrollers/analog-output arduino]. As the signal (between 0 and 1) comes into the IO Unit via the nodegraph, the value is then ouput as a PWM signal from the RoboPad "between" 0 and 3.3 volts. When you are driving external devices (such as LEDs, motors, etc), remember that the pins can only drive a small current (chip specifications recommend ~12mA source, ~20mA sink) so you may want to use a [[wikipedia:Transistor|transistor]] to drive heavier loads. This IO Unit creates an output port (labeled "<name> armed") on the Chip Node that signals high (1) when a control signal has been passed to it that would place it into it's safe state.

* '''Name''': The name of this PWM output, basically only changes the name of the input port on the Chip Node.
* '''Pin''': Which pin will generate the PWM control signal.
* '''Safety Value''': The percent, relative from the ''minimum microseconds'' value (0%) to the ''maximum microseconds'' value (100%) to return to when entering the [[emergency stop state]] if ''Stop Behaviour'' is set to "Return to safe".
* '''Stop Behaviour''': What value to output when in the [[emergency stop state]] if the ''Stop Behaviour'' is configured as "Return to safe".

== Physically Attaching Hardware ==
Hardware such as motors typically connects to one of the M1 or M2 output pairs or the E1 and E2 output pins (or others if in advanced mode, as laid out in the "Pins" section [[IO Config Editor#Pins|above]]). While M1 and M2 can drive motors directly via a passthrough to the RoboPad's supply voltage, motors that require their own voltage supply such as servos or brushless motors will require a connection directly to their own power supply. Typically this is the same power source as that used to power the RoboPad, however it could also be a battery elimination circuit (BEC) or any other voltage-appropriate power source. The images below show some example wiring diagrams (use the left and right buttons to change between images):<gallery mode="slideshow">
File:Basic 2-Motor wiring diagram.png|The most basic RoboPad circuit configuration, consisting of two drive motors connected to the M1 and M2 pin pairs.
File:Servo Wiring Diagram.png|A servo motor with it's control signal connected to the E1 pin, while it's power supply is connected to the same battery power supply powering the RoboPad.
</gallery>

Slider Node

2024-09-14T15:02:00Z

Blayze: /* Settings */ Adds upper and lower value settings.

{{Return to nodes}}{{Node Data
|title=Slider Node
|gallery=<gallery mode="slideshow">
File:Slider-node.png
File:Slider-settings.png
</gallery>
|output-list=<li>signal</li>
}}
The Slider Node is a UI Node that places a slider on the [[The Controller|controller]]. A slider is a simple element that can can be dragged in one direction - either up and down or left and right.

Slider Nodes were introduced in [[Firmware Releases|firmware version]] 2.1 along with all basic nodes.

The [[Example: Simple Tank-Drive Robot|Example Tank-Drive Robot]] uses a pair of sliders as it's central input method - check that out for an example nodegraph!

== Outputs ==
A Slider Node has a single output port - ''signal''. This output port will emit the position of the slider, from 0 to 1 (clipped), every time the slider is moved when in the [[The Controller|controller]].

== Settings ==
The Slider Node's settings can be configured to alter its visual presentation, mode of operation and output value mapping.

{{UI_Node_Settings|node=Slider}}

* '''Stick Colour''': Configures the colour of the stick of this slider as it's seen in the [[The Controller|controller]].
* '''Render Orientation''': Configures the direction the slider will render - ''vertical'' will result in a stick that can move up and down within its region, while ''horizontal'' will draw a stick that can move left and right.
* '''Release Behaviour''': Configures what should happen to the slider when a held click or touch is released - ''reset'' will result in the slider returning to its ''Start Position'' when released - much like a spring-loaded self-centering joystick on a traditional physical controller, while ''hold'' will leave the Slider in its current position, similar to non-self-centering joysticks. Sliders set to ''hold'' will render with three little bars in the center of the slider perpendicular to the direction of movement allowed (you can think of them as gear teeth, meshing into some unseen rack to stop the slider from moving back on its own).
* '''Start Position''': This configures both the position the slider starts in and the position that it returns to if its ''Release Behaviour'' is set to ''reset''.
* '''Invert Output''': This option inverts the output. By default a fully downward position makes the output ''Signal'' port emit '''0''', and a fully upwards emits '''1''', however enabling this inverts that, with a fully downward slider position emitting '''1''' and a fully upward position emitting '''0'''. Note that similar achievement could be achieved by using an [[Inverter Node]] on the ''signal'' output port.
* '''Upper Value''': ''[Added in version 2.4-b5]'' The value this slider will output at it's maximum position, defaults to '''1'''.
* '''Lower Value''': ''[Added in version 2.4-b5]'' The value this slider will output at it's minimum position, defaults to '''0'''.

== Gallery ==
<gallery mode="slideshow">
File:Default Controller 2023-02-25.png|Two sliders are present in the default nodegraph configuration. Both of these sliders are in ''reset'' mode and their sticks will ping back to the center once released.
File:Slider-vertical-reset-and-hold-UI.png|Two sliders in the ''vertical'' orientation, the left set to ''reset'' mode and the right set to ''hold'' mode.
File:Slider-horizontal-reset-and-hold-UI.png|Two sliders in the ''horizontal'' orientation. The upper is set to ''reset'' mode, with the lower set to ''hold''.
</gallery>

The Management Page

2024-09-12T01:06:56Z

Blayze: Updates to robopad.local

[[File:Management-page-2023-02-26.png|thumb|A screenshot of the management page displaying near-default firmware configuration as of 2023-02-26 ([[beta]] version 2.4-b2).]]
The management page is the page where you can configure almost all aspects of the RoboPad that aren't editable in the [[Nodegraph Editor]] and [[IO Config Editor|IO Configuration Editor]].

The page is split into 4 areas that handle storage information, general configuration, nodegraph management and input/output management.

=== Storage Information ===
At the very top of the page information and options for the entire system are displayed. Here you can see a visual indicator of the amount of storage used, as a red bar that fills a light-coloured region. In the screenshot shown to the right, 50% of the storage is used.

Below this are two buttons used to control the firmware and storage stored on the device. The [[Firmware Releases|Firmware Updater]] can be accessed by clicking on it's button, allowing you to update the firmware to the [[Firmware Releases|latest version]] (or a [[Beta|beta version]]), and all user-configured data on the device can be removed (and automatically reset to it's default values) via the '''Format Device''' button.

=== General Configuration ===
The settings under the ''general configuration'' heading reflect things that can change about the RoboPad in general - these things tend to skew towards wifi configuration settings. Since these settings are core to the RoboPad, when they are changed a reboot is required. Hence, to save any of these settings you must click the "Save and Reboot" button, which will update the settings and reboot the device. Leaving this page without clicking this button will '''not''' save the settings.

* '''Robot Name''': The name of the RoboPad, also used as the RoboPad's local wifi network [[wikipedia:Service_set_(802.11_network)#SSID|SSID]]. Has a maximum length of 32 characters.
* '''Robot Password''': The password used when accessing the RoboPad's local wifi network. Has a maximum length of 32 characters.
* '''Network Channel''': Allows you to select [[wikipedia:List_of_WLAN_channels#2.4_GHz_(802.11b/g/n/ax)|which of the 14 designated 2.4GHz range channels]] to run the RoboPad's wifi network on. In practice, performing a scan of channels in use by surrounding wifi networks and changing this to a less-populated channel might improve signal performance.
* '''Enable DNS''': In order to let the address "robopad.local" ("start.robopad.co.uk" in versions up to 2.3) direct to "192.168.4.1" (the [[wikipedia:IP_address|IP address]] of the RoboPad) when you are connected to the RoboPad's wifi network, a [[wikipedia:Domain_Name_System|domain name server (DNS)]] must run on the device. While this is a relatively small service, it still takes up processing power and computation time to run. If you are comfortable with or prefer navigating to "192.168.4.1" over "robopad.local", you may disable this feature for a minor performance boost.
* '''Heartbeat Timeout''': This is a critical safety feature of the RoboPad. In normal operation, the [[The Controller|controller]] sends "heartbeat" signals to the RoboPad, letting it know that it's still connected. If these signals are not detected by the RoboPad for a certain time period, then it will assume that it has lost connection to the controller or phone and transition to the [[emergency stop state]]. This setting controls how long it takes, in seconds, before the RoboPad considers the controller disconnected. To ensure safe operation, '''you should set this value to as low as it can go'''.
* '''Transmission Interval''': This indicates, in milliseconds, how often the controller transmits data back to the RoboPad. In practice, the controller samples things like [[Slider Node|Sliders]] or other [[Nodegraph Editor#UI Element Nodes|UI Elements]] at an incredibly high sampling rate - much higher than it makes sense to transmit to the RoboPad (higher transmission rates can clog the network, particularly if there are lots of RoboPads operating in one place), so we artificially limit transmissions to only occur in batches, the time between which is controlled by this setting. This value increments in steps of 16ms, and goes from 0 (instantaneous transmission) to 496ms (batching changes from the last half-second). Note that if an incoming signal over-writes a previous one in the same batch, the latest value is transmitted, not each value in turn - i.e. it is lossy.
* '''Reset General Config''': The ''Reset General Data'' button allows you to reset the general configuration options to their default values.

=== Node Graph Management ===
These settings give direct control over the [[Nodegraph Editor|nodegraph]] settings file.

* '''View Nodegraph''': The ''Download Nodegraph'' button takes you to a page showing the direct [[wikipedia:JSON|.json]] file representing the nodegraph. Some browsers will show this as an explorable object, some will simply display it as text. By saving the page you are able to download a copy of the nodegraph itself. Note that like all setting configuration downloads, it will download named "info" under most web browsers - make sure you re-name the downloaded file to something memorable.
* '''Upload Nodegraph''': This lets you upload a nodegraph file downloaded previously using the button under ''View Nodegraph''.
* '''Reset Nodegraph''': This resets the nodegraph to it's default configuration.

=== IO Management ''[beta version 2.4 and newer]'' ===
These settings give direct control over the [[IO Config Editor|input/output configuration]] file, and provide a link to the [[IO Config Editor|IO Configuration Editor]].

* '''Edit IO Config''': The ''Open IO Config Editor'' button allows you to access the [[IO Config Editor|input/output (IO) Configuration Editor]].
* '''View IO Config''': Similar to the ''View Nodegraph'' section, this will take you to a page that contains the raw IO configuration file. Most web browsers will immediately start downloading this file, usually titled as "info.bin". Make sure that you rename the downloaded file to something memorable.
* '''Upload IO Config''': Similar to the ''Upload Nodegraph'' section, this lets you upload an IO configuration previously downloaded using the button under ''View IO Config''.
* '''Reset IO Config''': This resets the IO configuration file to it's default configuration.

Nodegraph Editor

2024-08-24T22:14:44Z

Blayze: /* Example Nodegraphs */ Links to examples.

[[File:Node Editor Screenshot.png|thumb|675x675px|The Nodegraph Editor page, displaying the default nodegraph (as of 2023-02-25, [[beta]] build).]]
At the core of the configurability of RoboPad is the Nodegraph Editor. It allows you to specify a control flow from the UI elements that make up your on-screen controller when in [[The Controller|controller mode]] all the way to the RoboPad itself. While the nodegraph itself is stored on the RoboPad, every bit of processing that is performed on the node graph is performed on the device you are using to control the robot (usually a mobile phone), meaning that it has minimal impact on the robot's performance. Every time a node is updated - either by it's UI element moving (such as a joystick being moved or a button being pressed), it transmits that change out of it's output ports (golden rounded-squares on the left side of the node), and into the input ports (blue circles on the right side of the node) of any connected nodes. In this way, data can be transformed using different nodes before transmission to the robot itself. This lets you do things like configure different controllers on the screen, adding buttons to perform additional functions or process control signals in different ways.

If you are looking to start exploring the nodegraph editor, you may want to start with the list of '''Node Catalogue''' or list of '''Example Nodegraphs''' below, once you have familiarised yourself with general usage of the nodegraph editor and the concepts of inter-node communication.

== General Usage ==
The Nodegraph Editor stage is fairly simple - the top-bar is where you'll find every button to handle things that effect the whole nodegraph. Here you can:

* '''Save the Nodegraph''', which will save the current nodegraph to the RoboPad, allowing it to be loaded when you [[The Controller|open the controller]].
* '''Add a Node''', which will spawn a new node of the type specified by the dropdown on the left to the top-left of the nodegraph editor stage.
* '''Automatically adjust the UI''', the "Auto UI" button will automatically arrange the UI elements on the controller following a simple pattern. This is useful if you wan to quickly iterate on controller UI designs. The new UI transform settings will be visible in each UI node's settings menu, meaning you can change them (or the nodegraph) to fine-tune the UI placement.

In order to change settings about individual nodes on the stage, you can use the three buttons at the bottom of each node. The '''clone''' and '''delete''' buttons allow you to copy (along with all configured settings) and delete the node, while the '''edit''' button opens each node's specific settings menu that allows you to configure that node's behaviour. On UI nodes, this will generally involve things like placement and physical behaviour of the UI element that the node describes, while on non-UI nodes these settings will control node behaviour. The only non-removable node is the [[Chip Node]], which is a special node that represents the RoboPad itself. The input and output ports on the Chip Node are defined by the physical configuration of the RoboPad in the [[IO Config Editor]].

Nodes can communicate with each other via '''signals''' over '''connections''', which can be made by first clicking/tapping on either a '''port''' (the blue or gold shapes extending out of the side of each node) and then tapping on a port of the other colour on another node, linking them and allowing data to flow from one to the other.

== Inter-Node Communication ==
Individual nodes can control a variety of processes and communicate with each other via the gold and blue '''ports''' on either side of them - '''rounded-square edges gold''' '''ports on the left''' of the node always '''output''' signals, ''emitting'' data away from the node, while '''circular light-blue ports on the right''' of the node ''consume'' signals. In the example below, signals flow from the right-hand side into the Chip Node, which then actuators the robot's ''M1'' output. Every time the ''Slider'' is moved on the controller, it's signal is sent into the ''divide'' Math node (which has also previously been sent the signal "3" from the Number node), which computes the new value of ''a/b'' and the ''emits'' that value into ''M1'' on the Chip Node. In this case, that has the effect of decreasing the sensitivity and maximum value of the slider by three.

Similarly, the Chip Node will ''emit'' a signal of "1" on the ''M1 armed'' output port whenever M1 becomes armed. In the example, we connect this signal to an ''Indicator'', a UI element that will allow us to see that the motor is armed.
[[File:Control flow example.png|center|frameless|710x710px]]
You'll notice that signals can be '''any numeric value''' - while most built-in UI elements and [[IO Config Editor|IO Units]] work within the range of '''zero to one''', any value can be passed between the nodes. This can be very useful when you are trying to perform more complex behaviours within a nodegraph, however you should always know what values the input ports on the Chip Node (as defined by the [[IO Config Editor|IO Units currently configured]]) accept. Strange and difficult to debug behaviour may be the result of sending values to the Chip Node that it's not expecting. If in doubt, try adding an Indicator Node to the stage first before hooking anything up to the Chip Node and check that the values it's displaying are as expected as you use the UI elements on the screen. Once you've verified that, then you can start hooking up nodes to the Chip Node itself.

== Node Catalogue ==
Here is a list of all nodes available to you while in the nodegraph editor, clicking on each will bring you to a page outlining it's function, behaviour and available settings. The list has been split into the groups found on the "Add Node" UI selector in the editor, with the addition of a link to the Chip Node.

=== Special Nodes ===
The chip node is in it's own category as it is solely configured through the [[IO Config Editor|IO Configuration Editor]]. It has a golden title region.
* [[Chip Node]]

=== UI Element Nodes ===
The User Interface (UI) nodes almost all draw things to the [[The Controller|controller]], allowing you to actually interactively change values within the nodegraph. All UI nodes have a dark blue title region to separate them from other nodes.

* [[Slider Node]] - Places a slider element (acting like a single-direction joystick on a traditional hand-held controller) on the controller either horizontally or vertically, allowing you to input a linear signal between 0 and 1.
* [[Joystick Node]] - Places what is essentially a two-dimensional slider (acting like a bidirectional joystick on a traditional hand-held controller) on the controller that allows you to input a linear XY signal between 0 and 1 indicating the position of the stick within it's zone on the controller.
* [[Button Node]] - Places a button on the controller, allowing you to send a signal into the nodegraph when it is pressed.
* [[Indicator Node]] - Places a region on the controller that changes as a signal is sent to it; this is like an LED or indicator light on a traditional hand-held controller. You can also label and configure these indicators to show the value passed to them - very useful for debugging!
* [[Gamepad Node]] - Does not place a UI element on the controller, but instead when the controller is running, searches the device for a connected [[wikipedia:Gamepad|gamepad]], allowing you to use a physical input device to send signals to the nodegraph.

=== Signal Processing ===
Most nodes within the nodegraph deal with signals between 0 and 1, and signal processing nodes are designed to work with this in mind, providing basic manipulation steps that you might want to perform on nodegraph signals. Also found in this group are nodes that control signal flow through the nodegraph, allowing for things like signal delay or signal switching.

* [[Joystick Mixer Node]] - Specifically designed to transform a signal pair (between 0 and 1) that encodes a joystick position (as is generated by the ''[[Joystick Node]]'') into a dual-wheel drive signal, suitable for passing to [[IO Config Editor#H-Bridge Motor|Hbridge Motor]] IO Units.
* [[Inverter Node]] - Inverts a signal about 0.5; 0 becomes 1, 0.2 becomes 0.8 ect.
* [[Scaler Node]] - Scales a signal around 0.5 (by default).
* [[Switch Node]] - Switches which input it uses as an output dependant on another value, think of it like a [[wikipedia:Railroad_switch|train track switch]], allowing a node to selectively listen to signals emitted by one or another node.
* [[Delay Node]] - Delays a signal by a set number of milliseconds. Useful for timed behaviour.

=== Computation ===
The nodes found here perform generic computational operations - anything that allows you to perform mathematical manipulations of signal data

* [[Math Node]] - Performs basic mathematical operations on incoming signals.
* [[Number Node]] - Used to generate a static numeric signal.

=== Custom Nodes ===
Two nodes are configured to allow for custom JavaScript, so that you can write fully customised nodes. Be aware, however, that the JavaScript you write for these is currently stored '''uncompressed''' on the RoboPad's internal memory store, which is quite limited. You can see how much of the internal memory is currently in use by checking in the [[The Management Page|Management Page]]. Note that [[Updating Firmware|updating the firmware]] can require a large chunk of internal memory to cache the update.

* [[Custom Node]] - A general node that can be programmed to act on incoming signals, without drawing to the [[The Controller|controller]].
* [[Custom UI Node]] - The same as the ''Custom Node'', but functions specified to draw to the [[The Controller|controller]].

== Example Nodegraphs ==
The [[Example Robot Configurations|Example Robots page]] has some more in-depth worked examples of nodegraph usage.

Example: Simple Joystick-Drive Robot

2024-08-21T16:27:49Z

Blayze: /* Troubleshooting */ Adds troubleshooting guidelines

'''''NOTICE: This page consists of information (the IO Config editor) on a feature currently in [[Beta]]. Information is liable to change or be incomplete. However, a similar nodegraph is constructable for version 2.3 or lower builds of RoboPad.'''''

While a [[Example: Simple Tank-Drive Robot|tank-drive robot]] is the most simple type of robot that you can make with a RoboPad, many people want to control both drive motors of a simple two-motor robot with a single [[Joystick Node|Joystick]]. This page aims to give you a walk-through of building a robot that can be driven in this manner.

The nodegraph from this example can be found [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EctL76vbaS5HupqStJggtA8BuB2ThmnzbZDuQlYE2ZUg0g?e=57FshM here] (click the download button in the top left of the viewer to get a local copy that can be uploaded via the [[The Management Page#Node Graph Management|Nodegraph Management Page]]).

The IO Configuration can be found [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EdDMS4fiFFNBk0XiUJGwuLEB8vUZF1rG9RE07kyvFVDZIw?e=3PVTYd here].

== 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.<gallery mode="slideshow">
File:Basic 2-Motor wiring diagram.png|Motors are attached to M1 and M2 of the RoboPad in a simple 2-wheel Tank-Drive Robot.
</gallery>

== IO Configuration ==
In order to tell the RoboPad that there are two motors attached, you will need to configure the [[IO Config Editor|IO Units]] on the device. The RoboPad has special IO Units available for drive motors called "[[IO Config Editor#Built-in H-Bridge Motor|Built-in H-Bridge Motor]]" units. These use the internal [[wikipedia:H-bridge|H-bridges]] to drive the motors forwards and backwards:
[[File:Default IO Units.png|center|thumb|494x494px|With two "Built-in H-Bridge Motor" IO Units added, you can control up to two motors attached to the RoboPad on the "M1" and "M2" pins.]]

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:
[[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" (see the [[Example: Simple Tank-Drive Robot|Tank Drive example]] for more information on this - in this example, we assume knowledge of arming mechanics, and include armed status indicators).

In order to drive the motors M1 and M2, we will employ the use of a [[Joystick Node]] and a [[Joystick Mixer Node]]. By default the Joystick Node outputs two values: The position of the "stick" within the joystick in terms of it's X and Y position, between 0 and 1. We could hook this directly up to the M1 and M2 inputs if we wanted to:
[[File:Bad-joystick-config.PNG|center|thumb|A badly-connected joystick nodegraph that will cause incorrect motor drive.]]
However, this would result in moving the joystick left and right driving one wheel (if M1 is connected to it as in this example, the left wheel) only of the robot, and moving it vertically drives the other (here, the right):
[[File:Bad-joystick-config-diagram.PNG|center|thumb|A very difficult to drive robot.]]
In this case, driving the robot is very difficult. In the example above, moving the stick to the top right results in the robot moving forward, and the top left has it just spinning counter-clockwise in-place. We need some kind of mixing so that moving the stick up makes the robot move forwards, down backwards and left and right makes it turn left and right variably. Fortunately, that's what the [[Joystick Mixer Node]] is for:
[[File:Basic-joystick-drive-nodegraph.png|center|thumb|A properly mixed joystick node.]]
Now the robot should drive something more like this:
[[File:Good-joystick-diagram.png|center|thumb|When a joystick mixer node is used, the robot will drive forward when the joystick is moved upwards, and turn left and right as the joystick is moved left and right.]]
While this is still a relatively simple control scheme, it can still be a little confusing, especially if you decide to make any changes to the output of the Joystick Node before they go into the mixer node. In this case [[Indicator Node|Indicator Nodes]] can be very useful as they can be configured to display a value directly which can help you debug your nodegraph. In the final version of this example configuration, we use two to indicate whether the motors have been armed:
[[File:Joystick-drive-with-indicators.PNG|center|thumb|Here we have connected two indicators to tell us if and when the drive motors are armed.]]

The nodegraph for this example can be downloaded [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EctL76vbaS5HupqStJggtA8BuB2ThmnzbZDuQlYE2ZUg0g?e=57FshM here]. The IO Configuration can be found [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EdDMS4fiFFNBk0XiUJGwuLEB8vUZF1rG9RE07kyvFVDZIw?e=jLDhIO here].

Using a joystick node opens up a lot of real estate on your screen and (since it's a single-finger input), gives you the chance to add additional controlls on the screen. It's the perfect input mode to use alongside a [[Slider Node]] to drive a [[IO Config Editor#Servo Motor|Servo]] as a lifter for your robot.

== Troubleshooting ==
Even though you've configured your nodegraph following this page, you might still have some issues with driving your robot - these can arise when the physical configuration of the robot doesn't match up with the software settings you've configured - usually this can be that your left and right motors are flipped, or the power to one of the motors is inverted. You can of course fix these by re-soldering, but you can also usually just change the nodegraph as appropriate. Below are some common situations and their solutions.

=== The Robot Drives Backwards When the Stick is Pushed Forwards ===
In this case, it's likely that the drive motors have been soldered in the opposite polarity to the nodegraph configuration - you could reverse the polarity of the motors, or you can invert the output of the [[Joystick Node|joystick UI node]]. In the node's settings, there is an option for '''invert Y axis''' which will mean that instead of the y-axis output port emitting 0 when the joystick is at the bottom and 1 when it is at the top, it will emit 1 when at the bottom and 0 when at the top, flipping the forward/backward behaviour.

Note that you could also achieve this behaviour by putting an [[Inverter Node]] between the ''y'' output port of the Joystick and the ''yaxis'' input of the [[Joystick Mixer Node]].

=== The Robot Turns The Wrong Way ===
If the robot is turning right when you want to turn left (and vice-versa), this is similar to the previous issue, and can be solved in a similar way - you must '''invert the X axis''' before the signal gets to the [[Joystick Mixer Node]]. You can also achieve this same result by disconnecting the Joystick Mixer's ''left/right drive'' output ports and the [[Chip Node]]'s ''M1'' and ''M2'' ports and then connecting them in the other order, so that the drive signals cross and each of the Joystick Mixer Node's ''drive'' outputs is driving the opposite side it was before. The physical solution to this issue is usually switching which motor is connected to which "M" port - i.e. if M1 was left and M2 right, switch M2 to left and M1 to right.

=== Instead of Driving Forward, the Robot Turns ===
Lift the robot up off of its wheels - when you push the stick up to drive forward, do the wheels turn in opposite directions? When you pull the stick back to attempt to drive backwards, do they spin again in opposite directions but the other way? In this situation only '''one''' motor is connected in it's inverted polarisation. You could fix this by flipping the polarisation of the motor that is moving in the way you don't want it to, or you could connect an [[Inverter Node]] between the [[Joystick Mixer Node]]'s output ''left/right drive'' port and the Chip's ''M1'' or ''M2'' port (depending on which motor you want to invert).

=== The Robot Turns or Moves Too Fast ===
Controlling a robot from a phone can be finickety at times, and if your robot's got fast motors, you can loose control when turning. A simple way of reducing turning speed is to add a [[Scaler Node]] between the ''x'' output of the [[Joystick Node|Joystick]] and the ''xaxis'' input of the [[Joystick Mixer Node|Joystick Mixer]]. At this point the '''scale size''' can be set to some value lower than 1 to ''scale'' down the input signal so instead of emitting between 0 and 1, it might emit between, say, 0.3 and 0.8.

Scaler nodes can also be added to the Joystick's ''y'' output port to scale down speed. Or, if you prefer to keep the nodegraph simple, you can manually set the forward and backward scales in the [[IO Config Editor#Built-in H-Bridge Motor|H-Bridge IO Config settings]].

Example: Simple Joystick-Drive Robot

2024-08-21T16:12:24Z

Blayze: /* Troubleshooting */

Joystick Node

2024-08-21T16:08:30Z

Blayze:

{{Return to nodes}}{{Node Data
|title=Joystick Node
|gallery=<gallery mode="slideshow">
File:Joystick-node.png
File:Joystick-settings.png
</gallery>
|output-list=<li>x</li><li>y</li>
}}
The Joystick Node is a UI Node that places a simulated dual-axis joystick on the [[The Controller|controller]]. A joystick is a simple element that can can be dragged in two directions - up and down (the ''x axis'') and left and right (the ''y axis''). These values are reported out of Joystick node's ''x'' and ''y'' output ports as an ''x'' value, the position of the joystick from the left to the right, expressed as a number between 0 and 1, and the ''y'' value, the position of the joystick from the bottom to the top, again expressed as a number between 0 and 1.

Joystick Nodes were introduced in [[Firmware Releases|firmware version]] 2.1 along with all basic nodes.

The [[Example: Simple Joystick-Drive Robot|Joystick drive example robot]] uses a joystick as it's central input method - check that out for an example nodegraph!

== Outputs ==
Joystick Nodes are very similar to [[Slider Node|Slider Nodes]], but have an additional degree of freedom, meaning they can move in 2 axes. They are designed to mimic traditional dual-axis joystick found on a physical controller. Joystick Nodes have two output ports - ''x'' and ''y'', reflective of the stick's position in the x axis and y axis of it's region of movement. Both outputs are emitted from 0 to 1 (clipped), every time the slider is moved when in the [[The Controller|controller]].

== Settings ==
The Joystick Node's settings can be configured to alter it's visual presentation, mode of operation and output value mapping.

{{UI_Node_Settings|node=Joystick}}

* '''Stick Colour''': Configures the colour of the stick of this joystick as it's seen in the [[The Controller|controller]].
* '''X-Axis Release Behaviour''': Configures what should happen to the stick when a held click or touch is released, but only along the ''x-axis'' - ''reset'' will result in the stick returning to it's x-axis (horizontal) ''Start Position'' when released - much like a spring-loaded self-centering joystick on a traditional physical controller, while ''hold'' will leave the stick in it's current position along the x-axis, similar to non-self-centering joysticks. Joysticks set to ''hold'' in the x-axis will render with three little vertical bars in the center of the stick.
* '''Y-Axis Release Behaviour''': This behaves identically to the ''X-Axis Release Behaviour'', but along the y-axis (vertically).
* '''X-Axis Start Position''': This configures both the position the slider starts in along the x-axis (horizontally) and the position that it returns to if it's ''X-Axis Release Behaviour'' is set to ''reset''.
* '''Y-Axis Start Position''': This behaves identically to the ''X-Axis Start Position'', but along the y-axis (vertically).
* '''Invert X Axis''': This option inverts the output along the x-axis (horizontally). By default a fully leftwards stick position makes the output ''x'' port emit '''0''', and a fully right stick emits '''1''', however enabling this inverts that, with a stick position fully to the left emitting '''1''' and a fully right position emitting '''0'''. Note that similar achievement could be achieved by using an [[Inverter Node]] on the ''x'' output port.
* '''Invert Y Axis''': This behaves identically to the ''Invert X Axis'' option, but inverts along the y-axis (vertically).

== Gallery ==
<gallery mode="slideshow">
File:Joystick-return-behaviour-examples.png|Three joystick node elements drawn to the controller, one with both x and y behaviours set to reset (bottom left), one with both set to hold (middle) and one with only x-axis set to hold (right), all in their starting position.
File:Joystick-return-behaviour-examples-2.png|Three joystick node elements drawn to the controller, one with both x and y behaviours set to reset (bottom left), one with both set to hold (middle) and one with only x-axis set to hold (right). After movement, only the top can be completely off-center in both axes.
</gallery>

Example: Simple Joystick-Drive Robot

2024-08-21T15:05:55Z

Blayze:

Example: Simple Tank-Drive Robot

2024-08-21T14:36:44Z

Blayze: Adds instructions on how to download the nodegraph.

'''''NOTICE: This page consists of information (the IO Config editor) on a feature currently in [[Beta]]. Information is liable to change or be incomplete. However, a similar nodegraph is constructable for version 2.3 or lower builds of RoboPad.'''''

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 ([[Slider Node|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.

The nodegraph from this example can be found [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EZw9oIJKxlpOpjSIfN2ZZmgBktOBPOnqY55PVyKPJLDxrQ?e=gjRYLT here] (click the download button in the top left of the viewer to get a local copy that can be uploaded via the [[The Management Page#Node%20Graph%20Management|Nodegraph Management Page]]).

The IO Configuration can be found [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EdDMS4fiFFNBk0XiUJGwuLEB8vUZF1rG9RE07kyvFVDZIw?e=3PVTYd here].

== 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.<gallery mode="slideshow">
File:Basic 2-Motor wiring diagram.png|Motors are attached to M1 and M2 of the RoboPad in a simple 2-wheel Tank-Drive Robot.
</gallery>

== IO Configuration ==
In order to tell the RoboPad that there are two motors attached, you will need to configure the [[IO Config Editor|IO Units]] on the device. The RoboPad has special IO Units available for drive motors called "[[IO Config Editor#Built-in H-Bridge Motor|Built-in H-Bridge Motor]]" units. These use the internal [[wikipedia:H-bridge|H-bridges]] to drive the motors forwards and backwards:
[[File:Default IO Units.png|center|thumb|494x494px|With two "Built-in H-Bridge Motor" IO Units added, you can control up to two motors attached to the RoboPad on the "M1" and "M2" pins.]]

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:
[[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:
[[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 (use the left and right buttons to see additional images):<gallery mode="slideshow">
File:Basic Tankdrive.png|Two Sliders attached to the RoboPad chip node.
File:Basic Tankdrive Left Slider.png|The left slider configuration - it's positioned on the left of the screen, with a default value of 0.5 and "reset" behaviour. This means that as the stick is dragged up and down it will emit values between 0 and 1, driving M1 backwards and forwards, and when released it will output 0.5, stopping the motor.
File:Basic Tankdrive Right Slider.png|The right slider configuration - it's positioned on the right of the screen, with a default value of 0.5 and "reset" behaviour. This means that as the stick is dragged up and down it will emit values between 0 and 1, driving M2 backwards and forwards, and when released it will output 0.5, stopping the motor.
</gallery>However, while this is the minimum requirements to drive a robot using two sliders, it is often helpful to keep track whether your actuators are armed, which is why by default the RoboPad is bundled with a more advanced nodegraph that includes two [[Indicator Node|Indicator Nodes]] that change from dark to light green when each actuator is activated (again, use the arrows to see additional images):<gallery mode="slideshow">
File:Indicator Tankdrive Nodegraph.png|In this nodegraph, two Indicators have been added to indicate the armed status of the two drive motors.
File:Indicator-tankdrive-left-indicator.PNG|The left (M1) indicator has been placed above the left slider. The label visibility has been turned off and it set to "binary" mode so that it only turns a lighter shade of green to indicate the motor is armed.
File:Indicator-tankdrive-right-indicator.PNG|The right (M2) indicator has been placed above the right slider. The label visibility has been turned off and it set to "binary" mode so that it only turns a lighter shade of green to indicate the motor is armed.
</gallery>The nodegraph for this example is actually the default configuration of the RoboPad, so resetting the nodegraph and IO Configs via the [[The Management Page|Management Page]] should set it to this. However, you can download the nodegraph for yourself [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EZw9oIJKxlpOpjSIfN2ZZmgBktOBPOnqY55PVyKPJLDxrQ?e=gjRYLT here]. The IO Configuration can be found [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EdDMS4fiFFNBk0XiUJGwuLEB8vUZF1rG9RE07kyvFVDZIw?e=jLDhIO here].

Example: Simple Joystick-Drive Robot

2024-08-21T14:35:13Z

Blayze: Adds download instructions for the nodegraph.

Example Robot Configurations

2024-08-21T11:50:32Z

Blayze: Added links

Here you can find some examples of robot electrical topologies you might want to utilise when building your own robot, and the nodegraphs that best suit them.

* [[Example: Simple Tank-Drive Robot|Tank-Drive Controlled Robot]]
* [[Example: Simple Joystick-Drive Robot|Joystick Controlled Robot]]

Example: Simple Joystick-Drive Robot

2024-08-21T02:48:33Z

Blayze:

Example: Simple Tank-Drive Robot

2024-08-21T02:48:27Z

Blayze:

Slider Node

2024-08-21T02:47:24Z

Blayze: links to example

{{Return to nodes}}{{Node Data
|title=Slider Node
|gallery=<gallery mode="slideshow">
File:Slider-node.png
File:Slider-settings.png
</gallery>
|output-list=<li>signal</li>
}}
The Slider Node is a UI Node that places a slider on the [[The Controller|controller]]. A slider is a simple element that can can be dragged in one direction - either up and down or left and right.

Slider Nodes were introduced in [[Firmware Releases|firmware version]] 2.1 along with all basic nodes.

The [[Example: Simple Tank-Drive Robot|Example Tank-Drive Robot]] uses a pair of sliders as it's central input method - check that out for an example nodegraph!

== Outputs ==
A Slider Node has a single output port - ''signal''. This output port will emit the position of the slider, from 0 to 1 (clipped), every time the slider is moved when in the [[The Controller|controller]].

== Settings ==
The Slider Node's settings can be configured to alter its visual presentation, mode of operation and output value mapping.

{{UI_Node_Settings|node=Slider}}

* '''Stick Colour''': Configures the colour of the stick of this slider as it's seen in the [[The Controller|controller]].
* '''Render Orientation''': Configures the direction the slider will render - ''vertical'' will result in a stick that can move up and down within its region, while ''horizontal'' will draw a stick that can move left and right.
* '''Release Behaviour''': Configures what should happen to the slider when a held click or touch is released - ''reset'' will result in the slider returning to its ''Start Position'' when released - much like a spring-loaded self-centering joystick on a traditional physical controller, while ''hold'' will leave the Slider in its current position, similar to non-self-centering joysticks. Sliders set to ''hold'' will render with three little bars in the center of the slider perpendicular to the direction of movement allowed (you can think of them as gear teeth, meshing into some unseen rack to stop the slider from moving back on its own).
* '''Start Position''': This configures both the position the slider starts in and the position that it returns to if its ''Release Behaviour'' is set to ''reset''.
* '''Invert Output''': This option inverts the output. By default a fully downward position makes the output ''Signal'' port emit '''0''', and a fully upwards emits '''1''', however enabling this inverts that, with a fully downward slider position emitting '''1''' and a fully upward position emitting '''0'''. Note that similar achievement could be achieved by using an [[Inverter Node]] on the ''signal'' output port.

== Gallery ==
<gallery mode="slideshow">
File:Default Controller 2023-02-25.png|Two sliders are present in the default nodegraph configuration. Both of these sliders are in ''reset'' mode and their sticks will ping back to the center once released.
File:Slider-vertical-reset-and-hold-UI.png|Two sliders in the ''vertical'' orientation, the left set to ''reset'' mode and the right set to ''hold'' mode.
File:Slider-horizontal-reset-and-hold-UI.png|Two sliders in the ''horizontal'' orientation. The upper is set to ''reset'' mode, with the lower set to ''hold''.
</gallery>

Joystick Node

2024-08-21T02:46:11Z

Blayze:

{{Return to nodes}}{{Node Data
|title=Joystick Node
|gallery=<gallery mode="slideshow">
File:Joystick-node.png
File:Joystick-settings.png
</gallery>
|output-list=<li>x</li><li>y</li>
}}
The Joystick Node is a UI Node that places a simulated dual-axis joystick on the [[The Controller|controller]]. A joystick is a simple element that can can be dragged in two directions - up and down (the ''x axis'') and left and right (the ''y axis''). These values are reported out of Joystick node's ''x'' and ''y'' output ports.

Joystick Nodes were introduced in [[Firmware Releases|firmware version]] 2.1 along with all basic nodes.

The [[Example: Simple Joystick-Drive Robot|Joystick drive example robot]] uses a joystick as it's central input method - check that out for an example nodegraph!

== Outputs ==
Joystick Nodes are very similar to [[Slider Node|Slider Nodes]], but have an additional degree of freedom, meaning they can move in 2 axes. They are designed to mimic traditional dual-axis joystick found on a physical controller. Joystick Nodes have two output ports - ''x'' and ''y'', reflective of the stick's position in the x axis and y axis of it's region of movement. Both outputs are emitted from 0 to 1 (clipped), every time the slider is moved when in the [[The Controller|controller]].

== Settings ==
The Joystick Node's settings can be configured to alter it's visual presentation, mode of operation and output value mapping.

{{UI_Node_Settings|node=Joystick}}

* '''Stick Colour''': Configures the colour of the stick of this joystick as it's seen in the [[The Controller|controller]].
* '''X-Axis Release Behaviour''': Configures what should happen to the stick when a held click or touch is released, but only along the ''x-axis'' - ''reset'' will result in the stick returning to it's x-axis (horizontal) ''Start Position'' when released - much like a spring-loaded self-centering joystick on a traditional physical controller, while ''hold'' will leave the stick in it's current position along the x-axis, similar to non-self-centering joysticks. Joysticks set to ''hold'' in the x-axis will render with three little vertical bars in the center of the stick.
* '''Y-Axis Release Behaviour''': This behaves identically to the ''X-Axis Release Behaviour'', but along the y-axis (vertically).
* '''X-Axis Start Position''': This configures both the position the slider starts in along the x-axis (horizontally) and the position that it returns to if it's ''X-Axis Release Behaviour'' is set to ''reset''.
* '''Y-Axis Start Position''': This behaves identically to the ''X-Axis Start Position'', but along the y-axis (vertically).
* '''Invert X Axis''': This option inverts the output along the x-axis (horizontally). By default a fully leftwards stick position makes the output ''x'' port emit '''0''', and a fully right stick emits '''1''', however enabling this inverts that, with a stick position fully to the left emitting '''1''' and a fully right position emitting '''0'''. Note that similar achievement could be achieved by using an [[Inverter Node]] on the ''x'' output port.
* '''Invert Y Axis''': This behaves identically to the ''Invert X Axis'' option, but inverts along the y-axis (vertically).

== Gallery ==
<gallery mode="slideshow">
File:Joystick-return-behaviour-examples.png|Three joystick node elements drawn to the controller, one with both x and y behaviours set to reset (bottom left), one with both set to hold (middle) and one with only x-axis set to hold (right), all in their starting position.
File:Joystick-return-behaviour-examples-2.png|Three joystick node elements drawn to the controller, one with both x and y behaviours set to reset (bottom left), one with both set to hold (middle) and one with only x-axis set to hold (right). After movement, only the top can be completely off-center in both axes.
</gallery>

Example: Simple Joystick-Drive Robot

2024-08-21T02:44:55Z

Blayze:

'''''NOTICE: This page consists of information on a feature currently in [[Beta]]. Information is liable to change or be incomplete.'''''

While a [[Example: Simple Tank-Drive Robot|tank-drive robot]] is the most simple type of robot that you can make with a RoboPad, many people want to control both drive motors of a simple two-motor robot with a single [[Joystick Node|Joystick]]. This page aims to give you a walk-through of building a robot that can be driven in this manner.

The nodegraph from this example can be found [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EctL76vbaS5HupqStJggtA8BuB2ThmnzbZDuQlYE2ZUg0g?e=57FshM here].

The IO Configuration can be found [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EdDMS4fiFFNBk0XiUJGwuLEB8vUZF1rG9RE07kyvFVDZIw?e=3PVTYd here].

== 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.<gallery mode="slideshow">
File:Basic 2-Motor wiring diagram.png|Motors are attached to M1 and M2 of the RoboPad in a simple 2-wheel Tank-Drive Robot.
</gallery>

== IO Configuration ==
In order to tell the RoboPad that there are two motors attached, you will need to configure the [[IO Config Editor|IO Units]] on the device. The RoboPad has special IO Units available for drive motors called "[[IO Config Editor#Built-in H-Bridge Motor|Built-in H-Bridge Motor]]" units. These use the internal [[wikipedia:H-bridge|H-bridges]] to drive the motors forwards and backwards:
[[File:Default IO Units.png|center|thumb|494x494px|With two "Built-in H-Bridge Motor" IO Units added, you can control up to two motors attached to the RoboPad on the "M1" and "M2" pins.]]

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:
[[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" (see the [[Example: Simple Tank-Drive Robot|Tank Drive example]] for more information on this - in this example, we assume knowledge of arming mechanics, and include armed status indicators).

In order to drive the motors M1 and M2, we will employ the use of a [[Joystick Node]] and a [[Joystick Mixer Node]]. By default the Joystick Node outputs two values: The position of the "stick" within the joystick in terms of it's X and Y position, between 0 and 1. We could hook this directly up to the M1 and M2 inputs if we wanted to:
[[File:Bad-joystick-config.PNG|center|thumb|A badly-connected joystick nodegraph that will cause incorrect motor drive.]]
However, this would result in moving the joystick left and right driving one wheel (if M1 is connected to it as in this example, the left wheel) only of the robot, and moving it vertically drives the other (here, the right):
[[File:Bad-joystick-config-diagram.PNG|center|thumb|A very difficult to drive robot.]]
In this case, driving the robot is very difficult. In the example above, moving the stick to the top right results in the robot moving forward, and the top left has it just spinning counter-clockwise in-place. We need some kind of mixing so that moving the stick up makes the robot move forwards, down backwards and left and right makes it turn left and right variably. Fortunately, that's what the [[Joystick Mixer Node]] is for:
[[File:Basic-joystick-drive-nodegraph.png|center|thumb|A properly mixed joystick node.]]
Now the robot should drive something more like this:
[[File:Good-joystick-diagram.png|center|thumb|When a joystick mixer node is used, the robot will drive forward when the joystick is moved upwards, and turn left and right as the joystick is moved left and right.]]
While this is still a relatively simple control scheme, it can still be a little confusing, especially if you decide to make any changes to the output of the Joystick Node before they go into the mixer node. In this case [[Indicator Node|Indicator Nodes]] can be very useful as they can be configured to display a value directly which can help you debug your nodegraph. In the final version of this example configuration, we use two to indicate whether the motors have been armed:
[[File:Joystick-drive-with-indicators.PNG|center|thumb|Here we have connected two indicators to tell us if and when the drive motors are armed.]]

The nodegraph for this example can be downloaded [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EctL76vbaS5HupqStJggtA8BuB2ThmnzbZDuQlYE2ZUg0g?e=57FshM here]. The IO Configuration can be found [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EdDMS4fiFFNBk0XiUJGwuLEB8vUZF1rG9RE07kyvFVDZIw?e=jLDhIO here].

Using a joystick node opens up a lot of real estate on your screen and (since it's a single-finger input), gives you the chance to add additional controlls on the screen. It's the perfect input mode to use alongside a [[Slider Node]] to drive a [[IO Config Editor#Servo Motor|Servo]] as a lifter for your robot.

Example: Simple Joystick-Drive Robot

2024-08-21T02:42:22Z

Blayze:

Example: Simple Joystick-Drive Robot

2024-08-21T02:40:50Z

Blayze:

'''''NOTICE: This page consists of information on a feature currently in [[Beta]]. Information is liable to change or be incomplete.'''''

While a [[Example: Simple Tank-Drive Robot|tank-drive robot]] is the most simple type of robot that you can make with a RoboPad, many people want to control both drive motors of a simple two-motor robot with a single [[Joystick Node|Joystick]]. This page aims to give you a walk-through of building a robot that can be driven in this manner.

The nodegraph from this example can be found [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EZw9oIJKxlpOpjSIfN2ZZmgBktOBPOnqY55PVyKPJLDxrQ?e=gjRYLT here].

The IO Configuration can be found [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EdDMS4fiFFNBk0XiUJGwuLEB8vUZF1rG9RE07kyvFVDZIw?e=3PVTYd here].

== 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.<gallery mode="slideshow">
File:Basic 2-Motor wiring diagram.png|Motors are attached to M1 and M2 of the RoboPad in a simple 2-wheel Tank-Drive Robot.
</gallery>

== IO Configuration ==
In order to tell the RoboPad that there are two motors attached, you will need to configure the [[IO Config Editor|IO Units]] on the device. The RoboPad has special IO Units available for drive motors called "[[IO Config Editor#Built-in H-Bridge Motor|Built-in H-Bridge Motor]]" units. These use the internal [[wikipedia:H-bridge|H-bridges]] to drive the motors forwards and backwards:
[[File:Default IO Units.png|center|thumb|494x494px|With two "Built-in H-Bridge Motor" IO Units added, you can control up to two motors attached to the RoboPad on the "M1" and "M2" pins.]]

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:
[[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" (see the [[Example: Simple Tank-Drive Robot|Tank Drive example]] for more information on this - in this example, we assume knowledge of arming mechanics, and include armed status indicators).

In order to drive the motors M1 and M2, we will employ the use of a [[Joystick Node]] and a [[Joystick Mixer Node]]. By default the Joystick Node outputs two values: The position of the "stick" within the joystick in terms of it's X and Y position, between 0 and 1. We could hook this directly up to the M1 and M2 inputs if we wanted to:
[[File:Bad-joystick-config.PNG|center|thumb|A badly-connected joystick nodegraph that will cause incorrect motor drive.]]
However, this would result in moving the joystick left and right driving one wheel (if M1 is connected to it as in this example, the left wheel) only of the robot, and moving it vertically drives the other (here, the right):
[[File:Bad-joystick-config-diagram.PNG|center|thumb|A very difficult to drive robot.]]
In this case, driving the robot is very difficult. In the example above, moving the stick to the top right results in the robot moving forward, and the top left has it just spinning counter-clockwise in-place. We need some kind of mixing so that moving the stick up makes the robot move forwards, down backwards and left and right makes it turn left and right variably. Fortunately, that's what the [[Joystick Mixer Node]] is for:
[[File:Basic-joystick-drive-nodegraph.png|center|thumb|A properly mixed joystick node.]]
Now the robot should drive something more like this:
[[File:Good-joystick-diagram.png|center|thumb|When a joystick mixer node is used, the robot will drive forward when the joystick is moved upwards, and turn left and right as the joystick is moved left and right.]]
While this is still a relatively simple control scheme, it can still be a little confusing, especially if you decide to make any changes to the output of the Joystick Node before they go into the mixer node. In this case [[Indicator Node|Indicator Nodes]] can be very useful as they can be configured to display a value directly which can help you debug your nodegraph. In the final version of this example configuration, we use two to indicate whether the motors have been armed:

The nodegraph for this example is actually the default configuration of the RoboPad, so resetting the nodegraph and IO Configs via the [[The Management Page|Management Page]] should set it to this. However, you can download the nodegraph for yourself [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EZw9oIJKxlpOpjSIfN2ZZmgBktOBPOnqY55PVyKPJLDxrQ?e=gjRYLT here]. The IO Configuration can be found [https://yelllowcube.sharepoint.com/:u:/s/BlayzeTechLimited/EdDMS4fiFFNBk0XiUJGwuLEB8vUZF1rG9RE07kyvFVDZIw?e=jLDhIO here].

File:Joystick-drive-with-indicators.PNG

2024-08-21T02:40:33Z

Blayze: An example nodegraph that uses a joystick node.

== Summary ==
An example nodegraph that uses a joystick node.