Datasheet, Design on Altium Drive

There is a 24V -5V converter followed by a 5-3.3V converter. For the24-5V converter we use the TPS54332DDAR:https://www.ti.com/lit/ds/slvs875c/slvs875c.pdf?ts=1603276064222&ref_url=https%253A%252F%252Fwww.google.com%252F As for the chosen values, based on the calculations shown in the datasheet:

• C1 ⇒ 10 uF. 3x ESR is ripple voltage. X5R or X7R recommended
• Min L1= 8,2 uH —> 10uH is chosen
• C2+C3 = 100uF. Low ESR. High ripple current (above 3A)
• C4 = 0.1uF. High quality, ceramic, X7R or X5R grade dielectric (important for temperature stability)
• C6 = 50pF
• C7 = 2,7pF
• C5 = 12,5nF
• R1 = 150k
• R2 = 10,4k
• R3 = 270k
• R4 = 1M
• R5 = 10.2k
• R6 = 1,96k
• D1 = PMEG40T50EP

For the 5-3.3V converter we use the LD1117S33TR: https://nl.mouser.com/datasheet/2/389/cd00000544-1795431.pdf

We use the Xsens MTi-3 (uit de MTi 1-series) as IMU. https://drive.google.com/drive/u/0/folders/1vl0myIjebR3KWS5ZsLzqaVhCYPFw6MeU We have this one since gen1 and we want to contact Xsens again about the possibilities of getting new ones. The Xsens Inertial Measurement Unit (IMU) is responsible for measuring acceleration, rotational velocity, and current heading. The IMU provides data at 100Hz. This frequency would not give enough data to properly estimate the robot state, were it not that much of the filtering and processing is already done by the IMU. The IMU has its own frame of reference, initialized at boot time. This frame can deviate from the computer's frame, which takes the width and height of the field as x-, and y-axis. The computer sends camera data to the robot for calculating this deviation. The data provided by the IMU allows the robot to accurately execute commands from the computer. Instead of completely relying on the relatively slow feedback of the cameras, the robot can use the IMU data to precisely control its movements. The data of the camera can then be used to calibrate the drift in the IMU that builds up over time.

We currently use the STM32F767ZI. https://docs.rs-online.com/8a25/0900766b814da0a4.pdf In the STMCube and the schematics you can see which pins have which functions. With the chip shortage it is wise to check whether new ones are in stock so you will be able to make new prototypes when you want to. (I ordered extra at the end of the year so you shouldn’t have to worry about it for now ) The STM32F767ZI microcontroller is the brain of both the robot and the basestation. It runs at 150MHz, has 2MB Flash memory, 512KB RAM, and 14 timers. It supports UART, USART, SPI, QUADSPI, I2C, Full Speed USB, and more. The microcontroller has 144 pins. Via these pins, the microcontroller on the robot connects through all other peripherals on the robot. The pins visualized here are for the robot. The basestation has different names and functions assigned to its pins. The microcontroller is programmed using embedded C in combination with the HAL library. The VSCode editor is used in combination with the PlatformIO plugin.

The wireless transceiver we use is the EBYTE E28-2G4M12S SX1280 2.4G LoRa Bluetooth Module 2.4GHz Wireless rf Transceiver SPI Long Range BLE rf Transmitter 2.4g Receiver. This is the only component on the topboard we buy from aliexpress/amazon, so take longer delivery time into account. This one can also be reused really easily so if you need to, you can desolder them from older broken robots and reuse them. The SX1280 is used to wirelessly communicate between robots and the basestation. The basestation has two SX1280's, one for transmitting to the robot at 2.385GHz, and one for receiving from the robot at 2.395GHz. The robot has one SX1280 for both transmitting and receiving. At 2.4GHz, it can transmit up to 1.3Mbps in FLRC mode. It can send and receive packets of variable length up to 127 bytes.

The ID unit is a 4Way Surface Mount DIP Switch SPST. It MPN is IKD0403101 from APEM. The colors on the cap on top of the robot decide which ID it should be. Using this switch you can also let the robot itself know which ID it has. It is possible for 2 robots to have the same ID and they will get the same commands which can be really funny but also dangerous so please take this into account. The switches are numbered from 1 to 4, with 1 representing the least significant bit of the binary ID and 4 being the most significant. Example: If the switches are as follows: ON - OFF - ON - OFF, the ID should be 1*2^0 + 0*2^1 + 1*2^2 + 0*2^3 = 1 + 0 + 4 + 0 = 5.

Next to the ID switches is a set of 4 switches used for debugging and team setting purposes. As of the writing of this information, FT3 and FT2 do not have any function

• FT0 is used to trigger the test script. This script will get the robot to rotate around its own axis and give a few kicks. From the perspective of the switch, ON means NOT running the script and the other way around. This is probably due to the switches being soldered on in the opposite direction than the PCB was designed for.
• FT1 is used to indicate the team of the robot (which influences what frequency it will use)
  • ON means Yellow
  • OFF means Blue

The buzzer we use is the KPEG153 of Kingstate. https://docs.rs-online.com/f609/0900766b8068ec46.pdf . Ours is driven by the PMF250XNE. One resistor is put parallel as the buzzer has capacity and needs to discharge or it won’t make a sound. The value of this resistor is important for the sounds/loudness of the buzzer and from trial and error 1k deemed to be the best.

When the robot is booting in a normal mode without any errors, there are 3 different beep sequences right after each other:

1. A single “aliveness” beep
2. Team beep. This is based on the amount of syllables in the colour
   1. Single beep: BLUE
   2. Double beep: YE-LLOW
3. 4 ID beeps in the order of most to least significant bit

[TODO: Add testing mode] [TODO: Add non-development branch detection]

The reset button is just a simple button bought at the STORES. And as the name indicates, it is for resetting.

The computer requires about 100ms to decide the next action for each robot. Within this time, a ball can move up to 65 centimeters per the official RoboCup rules. The computer is too slow to send a kick command fast enough for the robot to kick balls moving at high speeds. To allow the robot to kick a ball instantly, a ball sensor has been added. The ball sensor is a Neonode zForce AIR touch bar. It is placed at the front, aiming at where the robot would be able to kick the ball. The ball sensor scans at a rate of 200Hz. Between two scans, a ball can move at most 3.25 centimeters. The kicker has a width of 4.5 centimeters, thus the ball will always be in range. The computer can instruct the robot to anticipate the ball, and shoot it as soons as it is detected. The ballsensor allows for faster plays, which are harder to anticipate and defend against. The ball sensors have 2 different wires, one with red tape and one without/white tape. The red tape ones should be attached to TopBoard 3.4 and 4.0, the others to 3.3. If you attach the wrong ones, the ball sensors will break and that stuff is expensive and custom made so just don’t.

The wheel encoders we use are the ENX QUAD 24. The maxon QUAD encoder uses two standard Hall sensors to generate incremental quadrature output signals. They possess two channels (A, B) with single ended signals. The resolution is 1 impulse per turn. With quadrature encoding, 4 states per turn are available for detection of speed, direction, and position.

Updated 29-08-2023, using the Top Board 4.2 schematic and BOM