@rmackay9
We made the demonstration of MQTT successful
I used Copter-3.4.
We did two demonstrations.
First, I connected Drone to the Internet with WiFi, got log (latitude, longitude, etc.), and operated (ARM, DisArm, take off, land etc.) Drone with MQTT from a remote place.
Second, connect Drone to the Internet with SORACOM (LTE / 3G), perform simple operation (ARM, DisArm) with MQTT from a remote place, loaded Drone in the car and got position information.
We shot a demonstration video, we will show you it when editing is over.
@rmackay9 We used the SORACOM USB dongle.
https://soracom.jp/services/air/
And we used a linux flight controller with the Navio2,
we didn't use a companion computer on the drone.
@rmackay9
The Solacom band of both upload and download is 2 Mbps at the fastest speed class(s1.fast).
The communication rate is 0.2 yen / MB.
By 2 Mbps bandwidth, I think slow/laggy video is possible.
In this development, we communicate with Drone using the MQTT protocol
With the MQTT protocol, we basically only send text data.
Additional development is necessary for us to send and receive videos over the Internet, but it is possible in the future, because we succeeded in connecting Drone to the Internet.
@tajisoft @norika-takumi @p-goudet
It's the agenda of today's meeting.
(1) Development of Raspberry Pi + Navio 2 configuration
· Refactoring: Pierre
· Adding a debug log: Pierre
· Arrives the buzzer sound informing of the state of ArduPilot
(2) Development of Pixhawk + Companion configuration
· on hold
(3) KDDI's demonstration experiment at SIM
· Schedule of demonstration experiment
· Scheduled to be confirmed on Saturday, April 15
· Additional development of Web UI
· http://scottlobdell.me/2017/03/successful-rc-blimp-autopilot-flight-test/
· Introduction of framework
· Server side: Express
· Front side: React or Angular etc.
(4) Video streaming of ArduSub
@rmackay9 We wanted to check if the strange motor sound remains on the latest commit. So we rebased the dev branch on the master branch of the ardupilot origin project. The result is that the strange still remains and the disarm command seems to not be transmit correctelly (need long time to stop engine). The testing setup is a navio2 board with esc "LHI simonk 12A” mounted on a rubocop drone. The previous version 3.4 is still fine and the MQTT function seems to go smoothly.
Do you have any idea about where this problem might come from? (and if it might easily be solve?)
Thanks to @tajisoft, there is now an option for the waf builder “—enables-mqtt” to compile the mqtt libraries.
The next step is to decide when the MQTT feature should be activated and setup.
One simple solution would be to use options for the arducopter binary such as “—mqtt_url” and parse it with an option parser. However I don’t really understand where and how ardupilot read/parse options? I looked up the AP_PARAM library and setup.cpp files but I could not understood how to add new options. Does anybody have idea about how to solve it?
I made a new flight mode on Rover. It is a mode that goes to the designated direction. Instructing the Rover to advance in the direction of the azimuth angle of 22 degrees, even if there is no Rover in the direction of the azimuth angle of 22 degrees, turn the handle automatically and run in that direction.
@rmackay9 Thank you, I have tried to clean a little the commit on the main developpement branch and I am preparing a branch to merge on the aptj-dev/master branch.
Currentely, I am using astyle to fix the source format. In some files where we add new features, some source code that we didn’t implement or modify is automatically reformated with astyle. It might become an issue as those unrelated source would be part of the branch changes. Could tell me if there is better to use astyle other than :
$astyle --options=Tools/CodeStyle/astylerc ArduCopter/ArduCopter.cpp:bow: