@Siddhanth https://docs.modalai.com/voxl-px4-dev-build-guide/

@smilon said in Custom px4-firmware build on StarlingV2:

I ran into an issue while installing the newly built voxl-px4 which states it depends on libfc-sensor(>=1.0.5) and I only have (1.0.4) on my system. @Eric-Katzfey I saw you authored some commits on libfc-sensor-api, do you have any clue how I can update?

1 Reply Last reply about 3 hours ago Reply

@smilon I would recommend using ros2 wrapper around mavsdk instead of mavros, that is what we have done in the past as mavros and ros1 are both depricated and not supported anymore. Anyways, goodluck with the project!

@Eric-Katzfey thanks, I completed all steps successfully and also built the px4 image for voxl2

Thanks a lot for your help
Enrico

@frafrat

Hi. The sensor is integrated into the VOXL SDK and raw data can be viewed through ADB or SSH with the voxl-inspect-rangefinders command line tool. All PX4 Autonomy Dev kids have this sensor. That data is sent from qrb5165-rangefinder-server to PX4 via voxl-mavlink-server. To enable in PX4 set the PX4 EKF2_RNG_CTRL param to 1. You will likely need to fiddle with PX4's other rangefinder params to achieve the behavior you want.

Best,
James

@enrico-bandera-0 Awesome! I am glad you figured it out.

@Eric-Katzfey
Hi,
The first change of flight mode to "Altitude" was because of the loss of control of pilot (see it from the "Manual Control Output") on the drone.
This wasn't happened first time, I experienced the same before this flight too.

The steps you provided aren't suitable, I can't do the flights like "Manual" and then verify everything everytime, this is a random behavior, even if I try in the manual mode and get a good flight, I can still experience the bad flight afterwards.

When I get the bad VIO data, I get the message of "invalid setpoints" in the log and over the QGC too and the drone goes into the "altitude" mode.

But, the problem I shared here is the loss of control over the drone, drone kept going upwards and even pulling the throttle to "0" isn't bring the drone to ground.

You can clearly see, even in the altitude flight mode (2nd time), the drone still kept going upwards at "0" throttle.

Please get us a fix for this.

@Stefan-Amundarain what do the flight logs tell you?

@Eric-Katzfey Thank you for such a quick response! Saved me a few hours down the wrong rabbit hole.

HI @Jeffrey-Mao
Another consideration for baro is active airflow. We typically provide a "cap" on our baros in our drones or flight-decks to ensure it is not exposed to sunlight (as Eric stated) but also active airflow which can show up like air pressure noise.
Our 3D models repository has a 3D file of this cap, in this case for FlightCore to give you an example:
https://storage.googleapis.com/modalai_public/modal_drawings/Flight_Core_Barometer_Cap.STEP
Hope this helps.

@Jetson-Nano , OK it seems we have two parallel threads going. please see my reply to the other thread https://forum.modalai.com/topic/3688/vision-sensors-not-detected-in-voxl2 and test it step by step as I suggested (reducing fps of imx214 camera first, then disabling sensors one by one)

Alex

@Alex-Kushleyev I tested it and it works nice (I didn't test the 255 but I expect that should work). I already figured that the frequencies are now multiples of 10Hz with some minimum value (I don't know which one but at least below -p 10 I don't hear the frequency drop anymore). So it ranges up to 2550Hz. And I think you also adjusted the duration to be multiples of 10ms to match with the format of the ESC parameters?

Regarding the usage change, I understand if you don't want to create a breaking change. But I think it would be good when the print_usage matches with the actual use. It took me some trial and error to get it working. Maybe also an idea to use -f for the frequency because -p refers to period which is not correct anymore and it is now already changing the functionality of the tone generation (you could even let -p in it to keep it backwards compatible but that maybe makes it unnecessarily complicated). And also good to allow the ESC mapping to go up to 15.

For us it is sufficient to use the startup tone. But I played around a little bit with the tone generation and if you use it using the qshell commands you need to wait the duration of the tone to send a new tone (as the qshell command immediately returns and it doesn't accept a command while the sound is still playing) which makes it difficult to get the timing right in playing a tune. I don't know what the end goal should be of this but if it is playing custom tunes using the commands this is something to keep in mind I think. I had some fun trying to play the Imperial March on the ESCs which kind of works but not as smooth as the startup sound can play.