How to create the Interface Matrix

/in , /by

By: Joseph Cho (Mission, Systems, and Testing)

Verified By: Intiser Kabir (Project Manager)

Approved By: Miguel Garcia (Quality Assurance)

Table of Contents

Introduction

The interface matrix will be used by the MST engineer and the E&C Hardware engineer to allocate the pinouts of the main PCB. The main PCB should be where the central processing is done. The 3DoT Board is the main PCB containing the microcontroller (ATmega32u4). If you have all the components picked out for the robot, the interface process should be easy.

Researching for the Interface Matrix

In order to start interfacing, we need to know what parts are used in the robot and how those parts are connected. A system block diagram will be very helpful to keep you organized.

If I2C addressing will be used, look up the I2C address of those parts (link to Adafruit I2C Address). I2C addresses have to be looked up to make sure that the parts that are being used do not overlap with other parts of the I2C bus. If addresses are overlapped, it is like having two people talking back to you the same time. Avoid having I2C addresses overlapped. We can use an I2C expander to avoid overlapping I2C addresses.  While you are making a list of components, find a datasheet for each one of them. The datasheet will be used to pinout the PCB shields.

Interface Matrix Template

Description:

The 3DoT board has 16 available pins (2×8 pin) on the top of the board and 8 pins on the front of the board. You will start the interfacing by deciding how many pins will be utilized by the 3DoT Board. The interface matrix will be focusing on the leftmost column. Column B shows the pin names on top of the board, and Column C shows pin names on the front of the board.  For the parts’ pin names, use the given pin name in the datasheet or schematic.

Examples

Figure 2: Example of 3DoT Interfacing (included in the Template)

Description:

In this example, 6 pins have been utilized for the sensor shield. I have named and numbered those pins for easier reference in the future. The color codes can be decided on your own, but for this example, I have used yellow, red and blue. I have separated them this way because those pins have different uses. The color yellow is used for the data signals, red is for power, and blue is for ground.

Figure 3: Example of PCB Interfacing

Description:

Now that we have those 6 pins ready for use, connect them to the parts to the correct pins. As mentioned before, some parts may share the I2C pins (SCL and SDA) and this is totally fine unless their I2C addresses overlap. If that is the case, use an I2C expander to re-address the parts’ I2C addresses. The “Shaft Encoder” has two separate pins for the digital output, so they are connected to two separate digital pins on the shield. Note that the row is colored up to the column used. Since shaft encoder does not use pin 1 SCL and pin 2 SDA, they are not colored in.

Schematics of 3DoT board

Figure 4: Pin of 3DoT board (Front of the board)

 

Figure 5: Pins of the 3DoT board (Front of the Board)

Description:

Schematics of the 3DoT board headers were added for reference. Look at the Arxterra website for more information about the 3DoT board.

Tips for future MST engineers:

  1. Make sure all the changes you make are approved by The Customer.
  2. Make sure both you and E&C Engineer know these interfaces and approve it. The E&C Hardware engineer will be using this interface matrix to create a custom PCB for your group.
  3. Communicate with your team members. Make sure that all your members know what parts are being used and how they are connected.
  4. Start with a breakout board for sensors. The custom PCB can be made like a sensor breakout board by the E&C hardware engineer. If the part you are trying to use is a breakout board, find the actual surface mounted microchip used for the sensing.
  5. Don’t mix up analog and digital pins. There are 5 analog pins (A0, A1, A2, A3, and A4) and I have made this mistake for not double checking. Check old blog posts, tutorials, and/or datasheets to make sure the pin being used is correctly connected.

Conclusion

Once the proper research is done for interfacing, the interface matrix is very simple to make. Read the notes in the examples and on the template for some parts skipped in this blog post. Lastly, double check your connections and get the matrix approved.

References

  1. https://docs.google.com/spreadsheets/d/1aarV8cXinkQM5X-mBR9ofC0-dlh1UwxvwzdLA5ykEEc/edit?usp=sharing
  2. https://learn.adafruit.com/i2c-addresses/the-list
  3. https://www.arxterra.com/3dot/
  4. https://docs.google.com/spreadsheets/d/1khUBCWJKz3PyFoB2Xp1CngnZKynNM2OerlcSHGMgjUc/edit?usp=sharing
  5. https://www.arxterra.com/at-st_interface_matrix/

Spring 2018: Project Power Budget Template

/in , , , /by

By: Raymundo Lopez-Santiago (Mission, System, and Test)

Verified by: Eduardo De La Cruz (Project Manager and Manufacturing Engineer)

Approved by: Miguel Garcia (Quality Assurance)

Introduction

This blog post covers the 3DoT project power budget. With the design of the version 6.43a of the 3DoT board, the existing power template from last semester needed to be updated. A major change from the last revision to this version is the parameters of the buck/boost converter. The previous revision had the output of the converter at 5V. This current revision has the converter output 3.3V to be used for peripherals needed for each robot project. This revision utilizes the same TPS61200 converter. The battery that will be used is the RCR123A 650mAh, 3.6V Li-Po. The project power budget template version 6.xx has been updated with the help of Professor Hill and Ryan Nguyen.

Project Power Budget (Updated 04/17/18)

Components of the 3DoT can be found in the schematic for the version 6.43a of the 3DoT board. For the schematic, click the following link: 3DoT v 6.43a Schematic.

 

This version updates the categories defined in the previous version. These categories include the LDO at 3.3V and output from the battery. The LDO incorporates the internal circuitry of the 3DoT board, sensor shield, and header shield. Output from the battery at the rated 3.6V can be used for motors/servos.

 

The complete power budget spreadsheet can be seen by clicking the following link: 3DoT Project Power Budget Template.

 

The user can input valued for peripherals used in the correct section. Any sensors should be added to the sensor shield or header section. Motors should be added in the Vout section. See Fig. 2 for clarification. Values inserted for current draw should ones from measurement but values from datasheets will be a good start.

Fig. 1: Spring 2018 3DoT Project Power Budget

Fig. 2: LDO @3.3V and Vout @ Battery voltage section

Fig. 3: Calculations for current draw and mission duration

Conclusion

The objective of this power template is to allow each project team to record all peripherals used in their project and their current draws. This template helps identify all current draws so the robot can operate efficiently without exceeding the battery values. Once all the values are inputted for each respective peripheral device used, calculations are automatically updated. The calculations are displayed towards the bottom of the document, see Fig. 3. All the information calculated includes total current draw and the maximum mission duration which is defined differently for each project.

References

  1. https://docs.google.com/spreadsheets/d/17oXC8C9Apr0KN9fGo3VRT38ZHFaBRNQnUWpWSYL1bdw/edit#gid=205608523
  2. http://www.ti.com/lit/ds/symlink/tps61200.pdf
  3. http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_Datasheet.pdf
  4. https://drive.google.com/file/d/18xenQLRR–v6t-eWHHrI-9tyA8uVhRLa/view
  5. https://www.arxterra.com/news-and-eventsmembers3dot-robots3dot-goliath/

 

 

 

 

Arxterra 3DoT Training Telerobotic Mode

/in , , /by

Written by Nornubari Kanabolo MST DM and Muhannad Al Mohamed E&C DM

Table of Contents

Arxterra Client-Server “Community” Mode

Training for telerobotic mode included understanding how “Community Mode”works. This can seen by the diagram below

Community mode is communication between several parts of the Arxterra environment. This includes between the ArxRobot mobile app and Arxterra Control panel through a server and between the ArxRobot mobile app and ATmega32U4 microcontroller.

Choosing Community Mode

1. Click on Community Mode in the ArxRobot App. This is

2. Do not change any of these default settings

Creating Name for Project

In order to create a name for the project, type in your robot name as seen below. For example, for the Goliath project, you would put “Goliath” in the “Robot name” area. For “Pilot name or names” you would put your individual birth name such as “Nornu”.

Access the Arxterra Desktop Control Panel

To access the Arxterra Control Panel, go to arxterra.com and click on “Launch Now!” in the control icon.

Now you log in to the control panel using your Arxterra username(assuming you already registered for an account) and password for Arxterra.

Communication with your Project

Once in community mode and logged into the control panel you should be able to see your robot on the map. It is signified as a colored location marker. Click this and it will show the name of the robot and a “beam me up, Scottie!” icon. Click this icon to switch to Pilot mode.

 → 

Now you should be able to see what your phone camera sees. The interface created through the ArxRobot mobile app should be visible now as can be see below. To change the view of the camera through the app go to the settings>>phone configuration>>camera for streaming video.

Custom Commands and Telemetry

The process of creating Custom Commands & Telemetry in Community Mode is exactly similar to the process in creating them in RC Mode. It has the same 7 options the users can choose from (Boolean, Select, Byte, Unsigned Byte, Short, Unsigned Short, Header/Separator). However, Instead of only enabling the commands to show up in RC Mode the user would enable it to show on the Client Server Mode.

User Interface on the Control Panel

The user interface has 7 windows to show data:

  1. Lounge: shows the position of the project on a map
  2. Live Cast: If camera is enabled, it will show live broadcast from the phone that has the ArxRobot App.
  3. Telemetry: This window shows whatever commands were set for telemetry. Gauges and values of data packets would be shown in this window.
  4. Custom Controls: similar to the RC mode, this window shows the custom commands made by the user to interact with 3DoT Board.
  5. Controls: Also similar to the RC Mode, this window shows the D-pad that can be used to move motors of projects.
  6. Orientation: this window would show the position of the robot if the motion were enabled in the ArxRobot App.
  7. Messages: This window would show any emergency messages and notifications enabled by the user through custom commands. For example the user can have an alert message be sent and shown on this window if a Servomotor went to a specific position.

Telemetry

Telemetry is an automated communications process by which measurements and other data are collected at remote or inaccessible points and transmitted to receiving equipment for monitoring data.

The data packets sent from the 3DoT to the ArxRobot App can be displayed in the telemetry window by enabeling either Telemetry State or Telemetry Stream for custom Commands.

Predefined telemetry can also be shown in the window if enable in the Robot Capabilities Configuration.

Training on Arxterra 3DoT App RC Mode

/in , , , /by

Written By: Muhannad Al Mohamed (E&C DM)

Table of Contents

Objective

The Arxterra 3DoT App training had a goal of teaching E&C and MST members how to use their phones to communicate with their projects through Remote Control Mode. The ArxRobot Application has two different modes of communication with the Robot’s Microcontroller. The Remote Control Mode (covered in this training) and the Community mode (Covered in the next training session). The user, through the ArxRobot App, should be able to send commands to the microcontroller either through predefined commands or custom made ones.

Introduction

The communication in the RC mode is done wirelessly through Bluetooth with an easy pairing process at the initialization of the RC mode. Commands are sent to the microcontroller as packets that consist of bytes that have specific identifiers to indicates whether the command is a command or telemetry. The packets contain data bytes that can be processed by the pre-coded microcontroller.

User’s Interface

The user interface in the RC mode is user-friendly. The default setting shows the controls of two motors in a strip type command. The strip can be changed to a D-pad looking control. Custom commands can be set to show on the user’s interface when enabled.

During the training session, members were taught how to use the user interface to control motors by giving specific input, moving motors at the same time, and steering trim to maintain desired speeds.

ArxRobot App’s Settings

The commands used in the app can be changed in the settings of the app. To access the predefined and custom commands users needed to be in Developer Mode.

The Phone Configuration window in the setting enables the user to choose the way to connect to 3DoT board, show phone’s battery percentage on Control Panel, and flip Camera’s position.

The predefined commands are commands and telemetry functions defined by the Robot3DoTBoard and saved in the app as default commands to operate a Mar’s Rover. These commands, if needed, can be used by the user by enabling each command in the Robot Capabilities configuration.

The Custom Command & Telemetry Configuration window allows the user to create new commands to be sent the 3DoT Board and receive Telemetry from it.

      

Custom Commands & Telemetry

Options for commands and telemetry is created by adding an option and giving it a specific address from (0x40) to (0x5F). Each option should be chosen to be either for commands to be sent to the 3DoT or Telemetry to be sent by the 3DoT. Commands can be controlled by the ArxRobot App; however, not all telemetry options are shown on the app. Each option should be enabled to show in either RC mode or Community Mode.

   

There are 7 options the user can choose while creating a custom command:

1- Boolean:

This option enables the user to send a byte in the data packet to the 3DoT board with a value of either (0x00) or (0x01). In the user’s interface, it can be seen as a switch that can be changed. The user can choose a default value of either of the previous options. This option can be used to turn an LED on and off for example.

2- Select:

This option enables the user to have multiple outputs to switch to. It is similar to the Boolean switch; however, it can have as many options the user wants to switch into. It sends a 1 byte of data parameter with the packet that is sent to 3DoT board; however, the values sent can be modified by the user. The select option shows in the user’s interface as radio buttons.

3- Byte:

This option can be used to send a byte in the data packet but with a wide range that can be changed by the user. It has a default range from -127 to 128 where the user can control which value sent by moving a strip in the user’s interface. These values can be changed by the user in the Byte settings to the desired range but it would still be a byte range. The steps between each value can be modified as well. This option can be used to move a servo motor for example.

4- Unsigned Byte:

This option is similar to the Byte command. The only difference would be the default range that starts from 0 up to 255.

5- Short:

This option is also similar to the Byte/Unsigned Byte; however, this option sends two bytes in data packet. Because it sends two bytes, the short command has a wider range than Byte/Unsigned Byte. The default value of this options ranges from -32768 to 32767.

6- Unsigned Byte:

This option is similar to the short option; however, the default range for it goes from 0 to 65535.

7- Header/Separator:

This option does not send any data in packets sent to the 3DoT; however, it is used to make the interface more user-friendly. titles to commands can be given using this option and it can be used to as separator if it was used without writing anything to it.

Training document

Arxterra RC Mode training document can found at this link.

Optimizing RC Mode in Projects

Update: 12/5/2017

Room Showing Telemetry Command

By creating custom commands and telemetry, engineers can create commands that can enable them to control their projects through the maze. For example, the path taken by a robot can be sent back to the phone connected to the MCU using telemetry options to show which room the robot is in on the phone’s display using RC mode. By optimizing the translated code from EE346/EE444 written by Mark Huffman (Goliath Project Manager) and Matt Shellhammer (ModWheels E&C Engineer), the variable “room” value can be sent as telemetry to the ArxRobot app. In the ArxRobot app, a telemetry Select command should be created and called room where it shows the byte value on the phone.

Creating Telemetry command called Room

Selec command Room

Assigned options to show the room type as implemented from the maze

Room type is shown in RC mode interface

Phase Selecting Command

The same process can be implemented to apply choosing the phase each robot is taking. In her blog Mission Definition, Elizabeth Nguyen (Pete-Bot Project Manager) explained how there are four planned phases each project can take:

  • Phase 1: Record
  • Phase 2a: individual playback
  • phase 2b: 4 Robots, 1 maze
  • Phase 2c: Individual playback, predefined

This custom command can be applied by also creating a select command with the four options where the user can switch easily between phases.

Phase selection in RC Mode

Recording Phase

Whenever Phase 1: Record is selected, the robot should start saving its path in the EEPROM. The EEPROM library can be very useful to record data when the system shuts down, which is essential in keeping data. The process of saving the path the robot is taking is explained in Write to EEPROM blog written by Matt Shellhammer (ModWheels E&C Engineer).