Léo-Paul Géneau (5ff15375) at 28 Mar 10:49
add flags
Léo-Paul Géneau (77411007) at 25 Mar 13:08
NEO: destroy partitions that are requested empty
... and 18 more commits
Léo-Paul Géneau (0ed7ff48) at 21 Mar 16:40
Fix code depending on python2 hash
... and 61 more commits
Code is different because in simulator altitude must be AMSL (https://lab.nexedi.com/nexedi/erp5/-/blob/master/bt5/erp5_officejs_drone_simulator/PathTemplateItem/web_page_module/drone_simulator_fixedwingdrone_js.js#L375) and in the capture the flag there is hack to kind of support both AMSL and relative altitudes (https://lab.nexedi.com/nexedi/erp5/-/blob/master/bt5/erp5_officejs_drone_capture_flag/PathTemplateItem/web_page_module/drone_capture_flag_fixedwingdrone_js.js#L375).
I am not sure what should be chosen because fixed-wings simulated with the simulator were using AMSL altitude so the current state is fine but current multicopters simulated with capture the flag are using relative altitude.
I do not think it is a good thing to support both AMSL and relative altitudes but there is also no good way to switch from one to the other as using relative altitude means that the system as knowledge about terrain elevation and handles the fact that the ground is not flat and on the other hand scripts for systems using AMSL altitude are written knowing the specifies of the flight terrain. It is not a good solution in this case to use initial AMSL altitude to convert relative altitude into AMSL as it is not in reality what always happen.
The good solution imho would be to split multicopter and fixed-wings APIs and say that setTargetCoordinates
uses relative altitude in one case and AMSL altitude in the other.
In https://github.com/open62541/open62541/releases/tag/v1.3.7 release notes is written fix(plugin): Fix gcc 12 warning in pki plugin
. I began to update open62541 when moving to debian12 (lpgeneau/slapos@a904509f) because it was breaking js-drone
tests but in the end max_version = 11
was added for open62541
compilation (!1404 (d34bcf92)).
I was ok with max_version = 11
as I think gcc12 only works with more recent versions of open62541
.
Ok, is there any reason to use specifically gcc10.2 rather than to define minimum and maximum version of gcc that should be used ?
I ask because compiling gcc requires a lot of time and disk space (this quickly becomes a troubling compilation on some hardware like SBCs) and therefore already available gcc should be used instead of compiling on new one whenever it is possible (this is one of the rare cases where SlapOS does not compile a dependency by default).
Léo-Paul Géneau (86611d1a) at 21 Mar 14:37
erp5_officejs_drone_simulator: add loop interval parameter
Léo-Paul Géneau (e88db16c) at 21 Mar 14:11
erp5_officejs_drone_simulator: add loop interval parameter
Léo-Paul Géneau (c3ab8096) at 21 Mar 13:32
erp5_officejs_drone_simulator: loop interval
Léo-Paul Géneau (25f8b070) at 20 Mar 09:49
erp5_officejs_drone_simulator: add getMaxCommandFrequency
... and 3 more commits
As I was not checking if the drone was already landing (https://lab.nexedi.com/nexedi/erp5/-/merge_requests/1903/diffs?diff_id=52442&start_sha=01ceb2095e29c21b9fe7e8127237402c1bca1557#dd10d4764676d712eca8b6559e758c47c6cd077c_363_363), a script continuously calling me.land()
would prevent a drone from landing because speed was always zero (!1903 (3c2f4ebf)).
Léo-Paul Géneau (3c2f4ebf) at 19 Mar 15:56
erp5_officejs_drone_simulator: implement proper parachute landing
... and 1 more commit
Well tests are passing but there is a side effect for the scripts I currently use that I need to investigate.
Test are passing.
Léo-Paul Géneau (01ceb209) at 18 Mar 15:48
erp5_officejs_drone_simulator: implement proper parachute landing
Léo-Paul Géneau (a3c0dce6) at 15 Mar 18:18
erp5_officejs_drone_simulator: command contraints
... and 1 more commit
@rporchetto would you have any idea how to add a check in tests for timeout feature ?
_callSetTargetCommand
function.Léo-Paul Géneau (59a85a73) at 15 Mar 14:03
erp5_officejs_drone_simulator: fix timeout