Posts made by 張為超

Hello, I noticed that one of the ESCs on my drone, specifically the one located at the right-down corner, is behaving strangely. After a normal position flight, I observed that this ESC is spinning, but it doesn't seem to be at full speed, and it feels like changing its direction intermittently for me. To further investigate, I attempted to use the command "modalai_esc -i 8 -r 5500 rpm" to verify its behavior. As a result, all the other ESCs behaved normally except for the one I mentioned.

Here's a video link that shows the problem: https://youtu.be/FFY34EuUVvg

I would greatly appreciate it if anyone could offer assistance in resolving this problem. Thank you in advance for your help.

Hello team,

I have a seeker with px4 firmware 1.11 and a M500 with firmware 1.13. We found that our seeker will switch into Altitude mode instead of Position mode when Offboard failsafe activates however our M500 does not (both had their COM_OBL_RC_ACT set to position). Our guess is the px4-fimware cause this problem, so we upgrade the px4 firmware to 1.13 for our seeker. And indeed once the firmware has been updated to 1.13, activating Offboard failsafe will switch seeker into position mode as expected.

However, after we update the seeker to 1.13 (either using the "modalai_fc_v1_default.px4" downloaded from the px4 github releases (we've also tried 1.13.3, 1.13.2, 1.13.0) or using QGC), loading parameters from either files (https://gitlab.com/voxl-public/flight-core-px4/px4-parameters/-/tree/master/platforms/v1.13/Seeker) will result in writing parameter fail for UART_ESC_XXX (and a couple more) because these parameters does not exits for the firmware. We suspect this is the reason for seeker not able to arm after the upgrade.(By not able to arm we mean we can send arm command through QGC and QGC will show "armed" but actually the motor is not responding)

In short:

(1) Why with FCv1 - v1.11.3-0.2.3, activating Offboard failsafe will switch seeker into altitude mode even with COM_OBL_RC_ACT set to position? (While with 1.13 activating Offboard failsafe it will switch to position as expected).

(2) How can we successfully load the parameters from https://gitlab.com/voxl-public/flight-core-px4/px4-parameters/-/tree/master/platforms/v1.13/Seeker after update the firmware to 1.13 using QGC or .px4 files downloaded from https://github.com/PX4/PX4-Autopilot/releases?

(3) Or, could seeker not arming after updated to 1.13 actually caused by some other problem?

thanks in advance for your time and assistance.

Jeff

I think you can use voxl protal first to check if the camera configure is okay, then use "rqt_image_view" in ros to check ros configure.

If you rostopic list on your pc does it show any topic ?

Hello, I would like to get my drone return for repair and I have a question about the rma-form. Since I am not the original buyer, so I'm a little bit confuse about the Original Order Number for Product on the rma-form. Is it Order#2838 on the original box which I received my drone?

Also, besides adding RMA (Drone) Diagnostic and RMA (Drone) Return after Repair/Diagnostic to the cart, Is there anything I should know before I ship my drone? Just want to make sure that everything is fine. Thanks!

Quick update, mavlink suddenly connected yesterday, but after few minutes it disconnected again. Since I didn't change any of setting, so I think it's bad contact causing the disconnection. What do you guys think of this?

@Chad-Sweet Thanks for your quick response.

I check the cable between them and it looks good to me. I also re-plugged some of them and check mavlink status, still shows disconnected.

Hello, I can't connect my seeker to QGC. I have already reconfigured voxl-vision-px4 and voxl-mavlink-server to the factory setting and both of them are enabled and running.

But when I look into it by using status -l voxl-vision-px4, it says:

Jan 01 00:00:09 apq8096 voxl-vision-px4[2589]: WARNING: connected to voxl-mavlink-server but no messages from PX4

And when I check voxl-mavlink-server, it says

Jan 01 00:00:10 apq8096 voxl-mavlink-server[2710]: PX4 DISCONNECTED FROM UART

Here is my mavlink.conf on seeker

I already try my best to fix this and gets no luck...... So hope you guys can help me with it.

Sorry for interrupt your Christmas vacation.

@Patrick-Hinchey looks like your pose didn't fixed according to apriltag this time. Maybe you can try to handhold the drone and inspect voxl-vision-px4 -f or inspect voxl-pose -f to see if the apriltag fix your position or not.

If not maybe you can follow https://docs.modalai.com/voxl-tag-detector/ to setup. If it does change pose, check the value to make sure it's correct according to apirltag

It's been a while since I use apriltag, so I'm not 100% sure.....

But I think you can try to use /mavros/setpoint_raw/local as publisher topic and give it with coordinates frame as FRAME_LOCAL_NED, mask with 1991 and give it a try.

Again I'm not 100% sure so I'm not responsibility any tragedy that happened.

I think since m500 use s500 airframe so the prop guard for s500 should be work, just double check the guard is bigger than prop.

I'm not 100% sure but I think you can check if you have publish /mavros/companion_process/status with component value 196 correctly, it should be publish by px4 avoidance automatically if your setup is good.

Since we were recently testing obstacle avoidance, we decided to add a prop guard for safety reasons. However, the prop guard looks good visually and also under payload limit, but it still cause vibrations to the seeker during flight.

seeker with prop guard:

flight video:
https://drive.google.com/file/d/1wV5DB6gfX7z69zkYtiPf9roQN4AQPfnb/view?usp=share_link

So my question is :

1. Is there any chance to improve the vibration? Is there any chance that QGC calibration might solve this problem?
2. Does ModalAI have plans to launch a set of prop guard for Seeker? Since Seeker is an indoor focused drone, a prop guard would be a nice add-on.

I'm so sorry to ask a big question with less information. But I still looking forward some advice by any chance. Really appreciate.

@Adrian-Hidalgo @Dobry-Kolacz Thanks for your reply, so the drone uses QVIO to control the altitude (I think it uses barometer or something else) which perfectly explains why the altitude sometimes drifts as our floors are a bit lacking in texture. I'll try adding some texture to the floor and give it a try. Thanks.

Hello team:

I found out that in offboard mode, the altitude of the drone looked fine at first. But after a few flights, the altitude started to drop. Even I switched into position mode, I have to set my throttle a little bit higher to let the drone to stay altitude.

So, my question is:

1. What could have caused this to happen? Do M500 and seeker use QVIO to estimate their height?
2. Is there any way to avoid this situation? Or i just need a better feature to stable QVIO?

Any suggestion is welcome, Big thanks!

@Alex-Gardner Sorry for responding late.

Yeah it looks like seeker have it's own landing gear. Since we lose and break M500's landing gear before... so, I wonder if there any spare landing gear that I can buy, just in case.

Thanks!

Hi, I'm planning to buy a seeker and some add ones recently.

In https://www.modalai.com/collections/add-ons I can only find landing gear for M500 and I don't think it fits seeker as well. So... can you show me where to buy landing gear for seeker? Thanks !

@Eric-Katzfey Hey, I just update my voxl-platform from 3.6.0 to 3.8.0 and reinstall some package include uvc-server.
And I find out that the image become nice and clear. So I guess the problem is solved for me. Hope you guys still have time to refund C930e. Really big thanks for helping me to resolve problem. Cheers

@Eric-Katzfey hello,sorry for responding late.

here's output for voxl-streamer -d :

voxl:~$ voxl-streamer -d
Enabling debug messages
Using configuration file /etc/modalai/voxl-streamer.conf
MPA interface chosen
Input pipe name /run/mpa/uvc/
Output stream width 640
Output stream height 480
Output stream bitrate 1000000
Output stream rotation 0
Output frame decimator 2
No image overlay specified
Camera server Connected
Meta data from incoming frame:
	magic_number 0x564F584C 
	timestamp_ns: 67575140926
	frame_id: 720
	width: 640
	height: 480
	size_bytes: 614400
	stride: 1280
	exposure_ns: 100
	gain: 100
	format: 8
Input parameters initialized
Made rtsp_server
Created RTSP server main loop context
Created RTSP server main loop
Created RTSP server main loop source for callback
Got 2 from gst_rtsp_server_attach
Stream available at rtsp://127.0.0.1:8900/live
A new client has connected to the RTSP server
Creating media pipeline for RTSP client
Made empty pipeline
Made app_source
Made parser_queue
Made raw_video_parser
Made scaler_queue
Made scaler
Made converter_queue
Made video_converter
Made rotator_queue
Made video_rotate
Made video_rotate_filter
Made encoder_queue
Made omx_encoder
Made rtp_filter
Made rtp_queue
Made rtp_payload
Made video_info
Made video_caps