Topics created by m4v3r

@Moderator I was thinking details, like at what speed and altitude etc.?

@m4v3r ,

I think the ESC params installation failed during an upgrade. Not a big deal. Here is a procedure you should follow to get your ESC to a good state. We have been improving the update process, so hopefully this does not happen in the future.

get the latest voxl-esc tools on your voxl2. You can clone directly to voxl2 or to your PC and copy to voxl2 if your voxl2 does not have internet access git clone https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc.git -b dev stop px4 systemctl stop voxl-px4 make sure you can scan / detect ESCs . Note that based on your current state, the script should find at least one ESC running at 57600 baud rate, which would mean the param install failed (57600 is the fall back baud rate). This is ok. cd voxl-esc/voxl-esc-tools ./voxl-esc-scan.py install the params based on your motor / propeller configuration or any custom ESC param that you created. This script should find all the ESCs even if they are running at different baud rates ./voxl-esc-upload-params.py --params-file <path_to_esc_params_file.xml> install latest firmware (this script will auto detect the board and pick the correct firmware). Please note that if the ESCs are detected at different baud rates, that needs to be fixed with the correct params (command above). This script will not automatically find the ESCs running at different baud rates (we will fix this soon). ./voxl-esc-upload-firmware-all.sh

Then you can start px4 again if needed

systemctl start voxl-px4

@m4v3r said in Flight Core w/ BMI088:

Thanks so much for clarifyiing this for me and I take it you wouldn't suggest using it since it's an older part?

My only suggestion is to use the ICM parts since that will always be installed on our boards, and you'll have no software mismatch builds across platforms old and new.
It's the Bosch parts that have fallen out of favor lately in the market and were also very hard to get last year hence the move to start DNI'ing them.
Thanks!

Hey,
just to give a little update here:
I found out how to set the "force mavlink mode" variable in the voxl-vision-hub.conf which was forcing the parameter back in PX4, and simultaneously set it to "Normal" in PX4.
So far I don't see any downsides from using MAV_1_MODE=0 (normal).
I'm only making use of voxl-mavlink-server and voxl-vision-hub for the time being, basically to use VOXL's connectivity to send MAV commands to the PX4.
Do you think using "normal" will have any downsides?
The inconsistency between your documentation and the .conf and PX4 firmware files still exists though, so I'd really like to get some more insight on this.
Thanks and a great weekend to everyone. ❤

@tom It's probably normal afterall since the voxl-vision-hub service's config file contains a parameter "reset PX4 on error".
I set it to "false" and now this behaviour disappeared. 😉

If you're not heart-set on monitoring these externally, we already have a voxl-cpu-monitor process that will monitor the temperature, utilization, and frequency of the cores. You can see an in-terminal display of these values with voxl-inspect-cpu, and the source is a good way to see how to monitor this data within a c program. As for the cutoffs, the system tries to maintain under 100C (so you should never see anything above this reported in software), if it does start to get above this, the PMIC will start removing power and shutting off cores. It's generally pretty hard to actually trigger the PMIC even under heavy loads as long as there's any sort of heat distribution around the voxl. The only time's we've done this in the lab in the last 2 years is with a seeker sitting on a desk, even the propwash in flight is enough to cool it.

@modaltb Hey hey know it's been forever but just right now I finally got it working. 🙂
I adjusted the adress in the corresponding driver's .h file and now it's finally running.
thanks again for going through this with me.
cheers

Hey,
just wanted to give an update it looks like the problem was a hardware fault.
The behavior stayed the same after detaching the LTE and the setup works on a different VOXL Flight, so yeah...^^
cheers

Hey,
I played around with them today a bit and found yes, your values did reduce the frequency with which the failure occurred so I'll continue tweaking there, thanks a lot.
Actually your link was double-helpful since I was looking for those specific parameters that regard the takeoff for quite some time now as well (without success...) ;D

I understand this is actually more closely related to PX4 but I very much appreciate the help anyway. 😉
I sincerely don't even remember anymore why yesterday I thought this must somehow boil down to the fact that it's running on the VOXL-Flight hehe.

Glad to hear it was a QGC issue - interesting to see that.

For the flight core portion of VOXL-Flight: Re-flashing the firmware will bring you back to factory (https://docs.modalai.com/flight-core-firmware/#px4-v111) and after that load parameters from our repo (https://gitlab.com/voxl-public/flight-core-px4/px4-parameters/-/tree/master/).

That should do it 👍

@modaltb said in Soft-Reboot not working:

Hi @m4v3r ,

If you have VOXL connected via ADB and issue a reboot command via QGC, do you lose the ADB connection?

Hi, yes if it's rebooted in ADB it's the same behavior.
This particular VOXL did live through several crashes and stuff though (I am a test-pilot mainly afterall ... ;D) so it might just be busted.

A different one, setup exactly the same, behaves as expected.
Thanks for the insight though.

Hey everyone,
just wanted to let you know that my fix got merged into master so it should work for everyone now... 😉

I'd have loved to change the title of this to something a little more descriptive but it's too late now I guess.
anyway, cheers everyone, happy flying. 😉

Computer Vision, of course. =D
Since working with the VOXL I already learned RTK, VIO, EKF and so on... but this one escaped me, so thanks haha.^^

Welcome aboard Chris! Looking forward to helping out.