rolandash
Thank you very much!
mindrace J7 connector type and using PMW3901 optical flow on it
rolandash
Hello, I have one more question. Will the mindracer work with TFmini rangerfinder?
Yes. Just find a free UART port for it.
- Edited
OK here are the steps to enable PMW3901 on MindPX/Mindracer, pretty simple actually.
Assume you have cloned PX4 master source code into your local.
Step 1
Locate file "boards/airmind/mindpx-v2/src/board_config.h", use any text editor to find the line:
#define PX4_SPI_BUS_BARO PX4_SPI_BUS_SENSORS
and add the below line right under it:
#define PX4_SPI_BUS_EXTERNAL PX4_SPI_BUS_EXT
then find the line:
#define PX4_SPIDEV_EXT0 PX4_MK_SPI_SEL(PX4_SPI_BUS_EXT, 1)
and add this line right under it:
#define PX4_SPIDEV_EXTERNAL PX4_SPIDEV_EXT0
Step 2
Locate file "boards/airmind/mindpx-v2/default.cmake", find the line:
optical_flow/px4flow
comment out this line by add '#' at the beginning of it:
#optical_flow/px4flow
then find the line before:
#optical_flow
enable this line by remove the '#' at the beginning:
optical_flow
Step 3
Compile and upload the new firmware:
make airmind_mindpx-v2_default upload
Connect pmw3901 and connect the mindracer to QGC.
Enable EKF2_AID_MASK, and SENS_EN_PMW3901 parameter in QGC and reboot.
If everything are executed correctly, You should be able to see optical flow in MAVLink inspector now.
rolandash Hello, I didn't find the two lines about SPI configuration in board_config.h Are you able to double check it for me? Thanks.
- Edited
which px4 version have you downloaded ? 1.10.1?
rolandash I found it. Just used a wrong version firmware.
OK.
Will be even simpler if you are using latest master source. you will only need to start from step 2.
rolandash It is working. Thanks!
- Edited
rolandash Hello,
Unfortunately I got the mindracer broken. The soldering pad on spi_CS was taken off. At first it cannot detect the PMW3901, then I tried to checked if the wires are contacting each other or not. Then I took the soldering pad off. Is there a way I can get this fixed? Otherwise, the mindracer is useless for me just for this small pad.
Thanks
- Edited
Well there is another way but really testing your soldering skill: you can jump wire directly from CPU pin 88 (PD7), however quite few people can make it.
We do not have this kind of service in US for now so I am afraid you have to on your own risk. Would be simpler to just get a replacement.
rolandash Thanks for your reply. Fortunately, I saw the wire, very thin. And solder them together. And glued that part. Hope they can stand for at least 1 month.
I do not have much experience about 3901. I use px4flow before and that was quite sometime ago so I try to recall some details.
To auto take off the drone needs to get sort of position lock first, either from a GPS or optitrack, or from a flow device. So if you can not take off that usually means the position lock is not available yet at that moment. That can be of many different reasons. But most commonly a flow device need to meet some external conditions to lock so if one of them fail it will just not working.
Regarding px4flow one of the common reasons is not enough flow quality. Usually when on the ground the flow can not reach enough quality to lock due to it requires some distance to the ground to get focused images, and when on ground the lens of flow is just too close to the floor. So the solution is to mount longer landing legs to the drone so the flow have proper distance to the floor as it needs.
Not sure it is the same reason on 3901 but I guess could be something similar like this. Check the locking conditions of 3901 and distance sensors and make sure they working properly before issuing the takeoff command.
- Edited
rolandash Hi, I think I know the reason. I can switch to position mode successfully and arm it (after this I use offboard mode), which means the sensor is able to lock position. I checked the local_position.pose.pose, which feedbacks the orientation and local positon. Sometimes The local position in Z direction is drifting and inaccurate. It can give me 1m high even it is on the ground. Since my goal position is at 0.7m, it is reasonable that the quad will not take off. But the distance sensor is giving me good estimation for Z position. I guess that the EKF2 failed to use the distance sensor sometimes.
And a new question, do you know how could I change the frequency of distance sensor? The default frequency in the MavLink Inspector is 10Hz. I tried to directly use the distance sensor feedback to implement my own feedback loop to control the position. But the feedback is too slow.
- Edited
OK, sounds you need a more accurate distance estimator.
To increase the default streaming rate, locate mavlink_main.cpp under src/modules/mavlink, and search for "DISTANCE_SENSOR", the line hit will explain itself pretty clear.
By the way, you probably can give LPE a try. LPE is said to have better accuracy of local positioning for indoor applications than EKF2.
rolandash Thanks for your feedback. I read the TFmini.cpp of px4 firmware, seems that the EKF2 only fues the TFmini output when it is 0.4m above the ground. I tried to lift the quad manually and check the local_position.pose.pose. The Z feedback is accurate and fast then. I will try the offboard mode with initial height above 0.4m to see if I can succeed every time or not. Otherwise I will directly use the faster distance sensor feedback as you suggested.