Open THEb0nny opened 10 months ago
Note for later correction A problem has been noticed: when starting the program, the motors may begin to spin slowly without a start command. If you set the stop command at the start, the motors are held. Two medium motors were used in the chassis. Reverse was installed for the left engine. The property is set to not hold the motors when braking.
Note for later correction A problem has been noticed: when starting the program, the motors may begin to spin slowly without a start command. If you set the stop command at the start, the motors are held. Two medium motors were used in the chassis. Reverse was installed for the left engine. The property is set to not hold the motors when braking.
This is because the setInverted command gives the pwm command. I probably probably wrote it. Although the direction of rotation is set.
This is because the setInverted command gives the pwm command. I probably probably wrote it. Although the direction of rotation is set.
I solved this by sending a command to stop the motors after setting the reverse (I added the setInverse() method inside).
Previously, I added a static instances variable for the Motor class, to which the current instance is added, as well as a getAllInstances() method to get an array of these instances. I added this change for an extension I was developing. So that for the specified pair of motors in the chassis, it would be possible to work with the motors from this pair separately. This is how I solve the problem that the simulator begins to display motors that I have not yet used, but they were indicated in the extension code. Calls through these instances allow me to access them implicitly so that the simulator does not notice. If we consider cases without this implementation, then when I made a choice of a pair of motors, it appears in the simulator accordingly, this is normal. But then I also need these motors separately. I know what the motors are for using the toString() method of the SynchedMotorPair class. Left and right motors. Next, I set up left and right motor variables for them and in if else if else... I assign instances (largeA, largeB, largeC, largeD, mediumA, mediumB, mediumC, mediumD), which tells the simulator that these objects are motors are used and immediately begin to display everything in the simulator, which is not suitable.
And here is a link to my extension, which required these additional changes https://github.com/THEb0nny/advanced-motor-controllers/blob/master/chassis.ts
There are still problems with the simulator https://photos.app.goo.gl/r8VG9NqhqXqLn3N26
I seem to have solved the problems with synchronous motor control methods. https://photos.app.goo.gl/ZQ95QEi2JKgNrwf18
Set the motor to setInverted(false) in the init() method only if it has not previously been used in a pair of motors.
For what? All because if the Setinverted (true) method for motor marra was installed before, then in the class of the same engine when calling the Init() Setinverted(false) was called and the motor was lost. An example below.
motors.mediumBC.setInverted(true)
motors.mediumB.run(5)
motors.mediumC.run(5)
The algorithm checks whether the engine was used in which of the SynchedMotorpair and if not, then setInverted(false) is called.
Thus, this algorithm allows the setInverted SynchedMotorpair method to set all Motor objects of used motors to reverse, and not just SynchedMotorpair objects.
Video with testing on hardware. https://photos.app.goo.gl/iHoc4rveN5ZY4N9b8 https://photos.app.goo.gl/zbCt7gj6vnQx9Kww6
Checking the reverse installation on the hardware.
You need to check steer() for a design with medium motors, which will have a reverse for the right motor, but not for the left one. Just in case, you will also need to check the design with large motors, one of which will have a reverse.
If possible, please make a separate version for this change after all other changes so that you can go back
How can I make the reverse string that appears in the simulator translated using crowdin?
I thought that this change should be revisited later. I think that it is necessary to leave only some methods for the two medium motors, such as stopping, and remove the methods for starting the motors, because the motors do not behave as they should in reality, such as spinning slower. Most likely, they are overlaid with software code that was developed exclusively for large motors.
As part of this change, two middle motors are added as synchronized control of the two motors. Two middle motors in the chassis are usually used in competitions. The ev3 firmware itself seemed to allow control using its own methods, which it made for large motors with medium motors. In ev3-g you could use large motor blocks for your medium motors installed on the robot. But there is a nuance: one of the middle motors must have a reverse input, because... it's upside down. And the standard blocks in ev3-g did not allow the use of the reverse parameter for two motors in the chassis. These blocks ignore reverse. And the reverse in makecode is software. Makecode does not use the function from ev3 firmware. And good. I want to add support for two medium engines. Motor reverse will be installed for all classes, one motor and two synchronized motors. I also implemented the simulator to display a message that the motor is in reverse. The next step is to make the run, tank, steer methods able to work with one reverse motor in a pair of two synchronized motors.