This blog post is about our current EV3 robot we're planning to use in the 2023/2024 FLL competition. Some features: 2 large motors for steering. 2 medium motors for attachments. 2 colour sensors for picking up the white and black lines, also used for line squaring. 1 gyro sensor. To enable attachments to be changed as quickly as possible we're using gravity to keep the gears connected, i.e. you don't need to fasten anything to the robot. Every attachment has 2x 12 tooth double bevel gear (part 32270) which comes in contact with the 2x 20 tooth double bevel gears (part 32269) on the robot. The medium motors are horizontally aligned on the robots, but we use 12 tooth double bevel gears to convert that to vertical alignments. These in turn are connected to 20 tooth double bevel gears, and the attachments in turn connect to these 20 tooth double bevel gears with their 12 tooth double bevel gears. The complete robot is modelled in Bricklink Studio 2 . You can download the rob
It happened to me - I've bricked my TP-Link MR3420 router by changing some settings in /etc/config/firewall, with the result that I couldn't get a connection to the router from either a wired or a wireless connection. And the failsafe option also doesn't work on OpenWRT Backfire 10.03.01, so the only remaining option was the use the router's serial port.
Enters the Raspberry Pi (http://www.raspberrypi.org). The Raspberry Pi has a serial port available on the GPIO pins, and what is nice is that it is operating on the same voltage levels as the TP-Link MR3420's serial port (0V and +3.3V). This means we don't need any RS232 voltage level converters (RS232 goes from -12V to +12V).
The only way to get access to the TP-Link MR3420's serial port is to open the router, and solder some wires to the SJ1 connector (see http://wiki.openwrt.org/toh/tp-link/tl-mr3420#serial). You need to solder at least 3 wires: Tx, Rx and Gnd, which is pins 1-3 on SJ1. You'll also need a 10kOhm resistor between the Tx pin and +3.3V, but I've used the +3.3V pin on the Raspberry Pi's GPIO connector (it means less soldering, but you can also use the +3.3V pin on SJ1 pin 4).
Then all that remains is to connect the Pi's Gnd to MR3420's Gnd, the Pi's Tx to MR3420's Rx, and the Pi's Rx to MR3420 Tx. The pinouts for the Raspberry Pi GPIO connecter can be found here: http://elinux.org/RPi_Low-level_peripherals
In the end the circuit I've used looks as follows:
Real world implementation - note I have no screen/keyboard connected to the Raspberry Pi, was using a session over the network:
On the Raspberry Pi the serial port is normally used for another terminal. We first need to kill this terminal so we can access the port via minicom. The serial port's name is ttyAMA0, so we first find the process ID for this process, then kill it:
The parameters to minicom:
-b: baud rate of 115200 kbps
-o means no initialisation strings to be sent to the modem
-D /dev/ttyAMA0: device to be used
If you don't have minicom you can install it with "apt-get install minicom".
Then power up the router, and you should get a normal terminal from the router. With this terminal I could reset all settings on the router, transforming it from a brick back to a router. Thank you Raspberry Pi!
Enters the Raspberry Pi (http://www.raspberrypi.org). The Raspberry Pi has a serial port available on the GPIO pins, and what is nice is that it is operating on the same voltage levels as the TP-Link MR3420's serial port (0V and +3.3V). This means we don't need any RS232 voltage level converters (RS232 goes from -12V to +12V).
The only way to get access to the TP-Link MR3420's serial port is to open the router, and solder some wires to the SJ1 connector (see http://wiki.openwrt.org/toh/tp-link/tl-mr3420#serial). You need to solder at least 3 wires: Tx, Rx and Gnd, which is pins 1-3 on SJ1. You'll also need a 10kOhm resistor between the Tx pin and +3.3V, but I've used the +3.3V pin on the Raspberry Pi's GPIO connector (it means less soldering, but you can also use the +3.3V pin on SJ1 pin 4).
Then all that remains is to connect the Pi's Gnd to MR3420's Gnd, the Pi's Tx to MR3420's Rx, and the Pi's Rx to MR3420 Tx. The pinouts for the Raspberry Pi GPIO connecter can be found here: http://elinux.org/RPi_Low-level_peripherals
In the end the circuit I've used looks as follows:
Real world implementation - note I have no screen/keyboard connected to the Raspberry Pi, was using a session over the network:
On the Raspberry Pi the serial port is normally used for another terminal. We first need to kill this terminal so we can access the port via minicom. The serial port's name is ttyAMA0, so we first find the process ID for this process, then kill it:
pi@raspberrypi:~$ sudo -i
root@raspberrypi:~# ps -ef | grep ttyAMA0
root 818 1 0 19:34 ttyAMA0 00:00:00 /sbin/getty -L ttyAMA0 115200 vt100
root 920 913 0 19:36 pts/0 00:00:00 grep ttyAMA0
root@raspberrypi:~# kill 818
root@raspberrypi:~# minicom -b 115200 -o -D /dev/ttyAMA0
The parameters to minicom:
-b: baud rate of 115200 kbps
-o means no initialisation strings to be sent to the modem
-D /dev/ttyAMA0: device to be used
If you don't have minicom you can install it with "apt-get install minicom".
Then power up the router, and you should get a normal terminal from the router. With this terminal I could reset all settings on the router, transforming it from a brick back to a router. Thank you Raspberry Pi!
Comments
https://raspberrypi.stackexchange.com/questions/85264/debricking-wnr2000v3-with-raspberry-pi-and-a-serial-connection#85269
I'm using minicom to connect to it, any ideas why it acts the way it does in my question?
(Not the same router, but it is still a UART, no?)
https://forum.openwrt.org/t/debricking-wnr2000v3-with-raspberry-pi-and-a-serial-connection/64243
root 818 1 0 19:34 ttyAMA0 00:00:00 /sbin/getty -L ttyAMA0 115200 vt100
The line above says it found a process running /sbin/getty which is using ttyAMA0. It's running with PID 818, which means you'll have to kill that process first before you can use minicom. Most likely your PID won't match 818, but use the PID you get back and kill it with the "kill " command.
If you have two processes using the same port it might explain why you're getting weird results back.