- * First, we got ROS (http://www.ros.org) to run onboard, which was quite straight forward given the ros documentation and provide a nice middleware for robotics and other applications. Only trick, if compiling onboard, always compile with -j1. The redpitaya does not have enough memory to run several C++ compilers with templated code.
* Got libfftw3 compiled onboard. Took a bit of time, but no issues. Works well for the multidimensional FFT we might do on-board.
* We integrated an IMU (MPU-9150 from Sparkfun) using the imupi code over i2c. This was integrated in ROS. No issue.
* We got an NRF24L01 wireless transmitter working over SPI, after modifying the device tree and recompiling the kernel.
* We used the linux HID layer to trigger redpitaya acquisitions based on mouse movements. Again integrated into ROS.
* We integrated the redpitaya acquisition loop in a ROS node and here is some comments while doing that:- * Using the NOW trigger in the API, we needed to add a delay (1ms is sufficient but maybe not necessary) before waiting for the trigger to be set, and once it is set, wait another delay (1ms) to make sure the data is in the buffer. The trigger tells us that the oscilloscope triggered, but at this stage, there is no flag in the API to ensure that the data has been stored in the linux memory space. Without the two waits, the buffer displayed discontinuities.
* Continous acquisition and publishing of ROS message is possible, but the serialization uses a lot of resources (85% of one core at 100Hz) on the redpitaya. Not a surprise, but better to publish based on particular triggers.
with selective reset is a OR of of the previous constants.Code: Select all
#define RP_RESET_ACQ_CH1 1 #define RP_RESET_ACQ_CH2 2 #define RP_RESET_GEN_CH1 4 #define RP_RESET_GEN_CH2 8 #define RP_RESET_NONE 0 #define RP_RESET_ACQ (RP_RESET_ACQ_CH1|RP_RESET_ACQ_CH2) #define RP_RESET_GEN(RP_RESET_GEN_CH1|RP_RESET_GEN_CH2) #define RP_RESET_ALL (RP_RESET_ACQ|RP_RESET_GEN) int rp_Init(unsigned char selective_reset);
- * Using the NOW trigger in the API, we needed to add a delay (1ms is sufficient but maybe not necessary) before waiting for the trigger to be set, and once it is set, wait another delay (1ms) to make sure the data is in the buffer. The trigger tells us that the oscilloscope triggered, but at this stage, there is no flag in the API to ensure that the data has been stored in the linux memory space. Without the two waits, the buffer displayed discontinuities.
Redpitaya as a robotic driver board
-
- Posts: 2
- Joined: Mon Oct 19, 2015 12:42 pm
Redpitaya as a robotic driver board
I wanted to post a small message to tell about some experiments we tried with the redpitaya. In our use case, the repitaya will be the core of a robotic system, so I don't use the web layer at all and I am only interested in the API. Here are some comments about what we tried so far:
jadalnie klasyczne ekskluzywne meble wypoczynkowe do salonu ekskluzywne meble tapicerowane ekskluzywne meble do sypialni ekskluzywne meble włoskie
Who is online
Users browsing this forum: No registered users and 5 guests