i'm affraid i did not translate correctly the part at line 92:
the speed will be controlled such as Optical Flow "values"? do not exceed 50% of the "given parameter"?
copter = helicopter, use drone.
blanch is not the correct term, use to tin which is widely used.
Flat cable is used but I beleive ribbon cable is more common (not sure)
Unclear sections (did not understand in russian neither, coming from an unadviced reader it might be usefull to clarify those points)
- l.61 "the red and black wires are to be tinned on both ends using tweezers" (did you mean soldering iron?)
- l.82 "disconnect the power and move yellow jumper to the other tweezer" (did you mean pins)
- l.145 "thus, it will be clear which motor is controlled" (unsure if by going through the procedure we activate the motors individually or by setting the throttle to 10% we simply see the direction of spin as it's slow)
not linked to the proof reading:
do you power the rgb strip directly from the raspberry pi with pin 40 (gpio 21) ?because it can be dangerous as the led strip is drawing x mA or even x A, and the RPI is not designed to withstand such currents (I beleive not more than 500mA), be carefull :o
- Copter in English is a synonyme of helicopter, use drone or quadrocopter.
- I would modify ther term "additionnal frame" as it might be understood as spare frame. I would describe them as "top frame" "bottom frame" "main frame" etc.
* builder: Skip builds for docs-only pull requests
* force rebuild
* travis: Fix bad syntax
* travis: Be more strict about checking for changes
* travis: Make build skipping more noticeable
There are cases when iterative solvePnP method converges on a "wrong" camera position due to projectPoints not treating negative Z values properly.
Other methods don't seem to be affected by that, but their results differ from the iterative method slightly. By combining these two methods we
"nudge" the iterative method towards the correct camera position and get satisfactory results most of the time.
Sometimes, though, even with the "nudge" the iterative method diverges catastrophically, and this is not caught by the solver. We work around that
by assuming our camera position cannot be too far from the markers.
* selfcheck: Perform version and preflight checks
* selfcheck: Fail commander check if no data received
* selfcheck: Print firmware version
* selfcheck: Create publishers and subscribers globally
* selfcheck.py: add note about firmware in gitbook
* selfcheck: Move firmware version checks to FCU checks
* selfcheck: Show commander warnings
* selfcheck: Remove prompt line from received mavlink message
* clever: Add pymavlink as a ROS dependency
* aruco_map: Improve parser
* aruco_map: Use marker id for map visualization
* aruco_pose: Add parser pass test
* aruco_map: Code style
* aruco_pose: Add more test cases
* aruco_map: Better message handling
* aruco_map: Be more informative about bad lines
* aruco_map: Add failure mode tests
* aruco_map: Be less strict about map contents
* aruco_pose: Restructure tests
* aruco_map: Don't use marker id in visualization
* aruco_map: Check for marker uniqueness
* aruco_pose: Use board data to reject duplicate markers
* aruco_pose/test: Spelling fixes
