Implements Tello.Messaging by emulating Tello drone behavior. A connection to the Tello's WIFI is required. Implements Tello.Messaging via UDP access to a live Tello drone. The FlightController in Tello.Controller is coded to the Tello.Messaging interfaces and is implementation independent. These interfaces are implemented by two projects: Tello.Udp, which communicates with Tello, and 2, which roughly emulates Tello behavior. Provides injectable messenger services for Tello. Using it is a matter of wiring up the events and then calling command methods.
#TELLO DRONE CONTROLLER HOW TO#
See the static Program class constructors in or to see how to instantiate FlightController. If someone wants to donate an EDU model, I'd be happy to finish the mission pad commands myself. If someone has an EDU and wants to uncomment the EDU commands in the Commands enum and implement them, I'd be happy to accept a solid pull request. Since I can't test the Tello with the mission pad I don't know how to simulate it's behavior it in the emulator. I've read in the forums that an EDU version is required to use the mission pad and some of the new commands.
We can't have a UI sitting around waiting for a 20 second command to complete, right? So command messages are queued up as they are received, program control is returned to the main thread, and a queue consumer running in a separate thread pulls an item off the queue when it detects that Tello is ready for the next message. Since the Tello operates synchronously, the flight controller had to provide an asynchronous interface to the Tello messaging system. Ideally the drone would ACK the command, execute the maneuver, and ACK completion. This makes timing out unreceived commands a bit more complex. For example, if you send a command like UP (10), it might take a few seconds to complete the maneuver and ACK, but if you send something like FORWARD (500, 10) it's going to take a lot longer to complete the maneuver and you won't get an ACK until it's complete. There doesn't appear to be an internal command queue, so Tello doesn't ACK a command until it has been executed. I thought it would ACK each command as it was received, but this isn't the case. Tello doesn't respond to commands as I expected after first skim of the SDK 1.0 documentation. Flight Controller's Async Command Queue - Why is it coded like this? My goals for this project are to refine my dependency injection skills, experiment with value objects, lock-free concurrency, machine learning and video processing, play with a thing that I can fly from my desk, and begin to iterate on the larger problem of programmable drone behavior. Maybe that will solve the issue once and for all. I have yet to try attaching the Tello to my local network. Rebooting the Tello and reconnecting to its network usually resolves the issue. When this happens, additional commands may be executed by the Tello, but won't always ACK. However, the Tello sometimes responds to the SDK initialization command with gobbledygook instead of the expected 'ok'. With the latest firmware updates and SDK 2.0, the drone communication is relatively reliable. I started by playing with a fork of the TelloLib (aTello) project but abandoned it when Ryze upgraded their text based SDK. This project in action: Ryze Robotics Tello Reference The project includes a flight controller, Tello emulator, UDP messenger, script builder, and two console samples. I'm settled in and should be able to start work again next weekend. Closed my consulting company after 18 years and started a new job.
#TELLO DRONE CONTROLLER UPDATE#
Update : I got side tracked by life events.
0 kommentar(er)
