Redpitaya as a robotic driver board

Tell us how your experiment is running with Red Pitaya
Post Reply
Posts: 2
Joined: Mon Oct 19, 2015 12:42 pm

Redpitaya as a robotic driver board

Post by cedricpradalier » Wed Dec 02, 2015 10:04 pm

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:
  • * First, we got ROS ( 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.
    * We created a different ROS node to configure the generate side, and we found out that the rp_Init() function modifies the global behaviour of the card by setting all parameters of the generator and acquisition layer to their default value. This means that if we run the acquisition node and then the generation node, the second change the decimation value of the first (as well as other parameters). In the other order, the acquisition node stop the generation node when it starts. The solution, is to keep forcing the parameters in each node's loop. Ideally, modifying the API so that setting the default value is an option, or can be configured independently for the generation and acquisition side might make more sense. In this case, I would go as far as doing it per channel. An OR of C enum might be the easiest way:

    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
    int rp_Init(unsigned char selective_reset);
    with selective reset is a OR of of the previous constants.

Post Reply
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 1 guest