I'm connected to my Nao via wireless. Two days ago, I had no problems running programs on my Nao, but today I'm having issues. I can boot up choregraphe and connect, but I can't stiffen the joints. I click the little sun icon a ton but nothing happens. I can get the Nao to say stuff, but not move since the joints won't stiffen. I tried a hard reboot on the Nao and on my laptop but it still doesn't work. Any ideas?
EDIT: When printing the error return from the wake up function, I got this:
[WARN ] ALMotion.LibALMotion :xCheckUnclampedSensorInsideLimits:0 In wakeUp, joint LShoulderPitch beyond the limit. AngleSensor (deg): 132.714 min (deg): -119.5 max (deg): 119.5
[ERROR] ALMotion.LibALMotion :wakeUp:0 WakeUp will not be performed because a wrong calibration has been detected.
For anyone else who has this problem: instead of just turning it on and off, make sure you move it to a new position. I think that the shoulder joint was detecting a weird angle and therefore didn't know what to do. Put a print statement around the wakeUp function to better understand the error.
Related
I'm trying to count the blinks of a LED with the ESP32-CAM AI Thinker board. I need to count a LED that blinks once every 150ms. The code part works fine, but I'm experiencing some fps drops in some points, so I have some frozen frames and then the counting is wrong.
How can I have a smoother capture of the ESP32-CAM so that I don't lose any frames of the LED blinking?
There are two approaches that I can think of:
1. Find the source of the issue
Why are these frames freezing? Is it the camera board itself, or is it something on the ESP32 itself? Perhaps there is some FreeRTOS task running on the ESP32 (e.g. BlueTooth or WiFi) which occasionally requires CPU and causes disp in performance.
Run idf.py menuconfig to check if:
your CPU is running at maximum speed
you have BlueTooth/WifiEnabled
...
2. Extrapolate the missing data
With this approach, you'd first detect the frame drops, and measure the amount of frames dropped. It is only an approximation though:
When you then calculate the LED blink count, take the average measured blinks from the last second (or whichever timeframe that is suitable) and fill in the missing blinks with this this data.
When using snd_pcm_writei() in non-blocking mode everything works perfect for a while but eventually the audio gets choppy. It sounds like the ring buffer pointers are getting out of sync (ie. sometimes I can tell that the audio is playing out of order). How long it takes for the problem to start it's hardware dependent. On a Gentoo box on real hardware it seldom happens, but on a buildroot system running on QEMU it happens after about 5 minutes. On both cases draining the pcm stream fixes the problem. I have verified that I'm writing the samples correctly by also writting them to a file and playing them with aplay.
Currently I'm setting avail_min to the period size (1024 frames) and calling snd_pcm_wait() before writting chunks of the period size. But I tried a number of different variations (different chunk sizes, checking avail myself and use pthread_cond_timedwait() instead of snd_pcm_wait(), etc). But the only thing that works fine is using blocking mode but I can not do that.
You can see the current source code here: https://bitbucket.org/frodzdev/mediabox/src/5a6471316c7ae481b329e7e0d4af1bb68a32e71d/src/audio.c?at=staging&fileviewer=file-view-default (it needs a little cleanup since I'm trying all kinds of things). The code that does the actual IO starts at line 375.
Edit:
I think I got a solution but I don't understand why it seems to work. It seems that it does not matter if I'm using non-blocking mode, the problem is when I wait to make sure there's room on the buffer (either through snd_pcm_wait(), pthread_cond_timedwait(), or usleep()).
The version that seems to work is here: https://bitbucket.org/frodzdev/mediabox/src/c3eb290087d9bbe0d5f37653a33a1ba88ef0628b/src/audio.c?fileviewer=file-view-default. I switched to blocking mode while still waiting before calling snd_pcm_writei() and it didn't made a difference. Then I added the call to snd_pcm_avail() before calling snd_pcm_status() on avbox_audiostream_gettime(). This function is called constantly by another thread to get the stream clock and it only uses snd_pcm_status() to get the timestamps. Now it seems to work (at least it is a lot less probable to happen) but I don't understand exactly why. I understand that snd_pcm_avail() will synchronize the pointers with the kernel but I don't really understand when it needs to be called and the difference between snd_pcm_state() et al and snd_pcm_status(). Does snd_pcm_status() also synchronize anything? It seems not because sometimes snd_pcm_status_get_state() will return RUNNING when snd_pcm_avail() returns -EPIPE. The ALSA documentation is really vague. Perhaps understanding these things will help me understand my problem?
Now, when I said that it seems to be working I mean that I cannot reproduce it on real hardware. It still happens on QEMU though way less often. But considering that on the next commit I switched to blocking mode without waiting (which I've used in the past and never had a problem with on real hardware) and it still happens in QEMU and also the fact that this is a common issue with QEMU I'm starting to think that I may have fixed the issue on my end and now it's just a QEMU problem. Is there any way to determine if the problem is a bug on my end that is easier to trigger on the emulator or if it's just an emulator problem?
Edit: I realize that I should fill the buffer before waiting but at this point my concern is not to prevent underruns but to make sure that my code can handle them when they happen. Besides the buffer is filling up after a few iterations. I confirmed this by outputing avail, buffer_size, etc before writing each packet and the numbers I get don't make perfect sense, they show an error of 1 or 2 periods about every 8th period. Also (and this is the main problem) I'm not detecting any underruns, the audio get choppy but all writes succeed. In fact, if the problem start happening and I trigger an underrun by overloading the CPU it will correct itself when the pcm is reset.
In line 505: You're using time as argument to malloc.
In line 568: Weren't you playing audio? In this case you should do wait only after you wrote the frames. Let's think ...
Audio device generates an interrupt when it terminates to process a period.
| period A | period B |
^ ^
irq irq
Before you start the pcm, audio device doesn't generate any interrupt. Notice here that you're waiting and you haven't started the pcm yet. You only starts it when you call snd_pcm_writei().
When you wait for audio data you'll be awake only when the current period has been fully processed -- in your first wait the first period wasn't even written -- so in a comfortable situation you should write the whole buffer, wait for the first interrupt, and then write the just processed period, and on and on.
Initially, buffer is empty:
| | |
write():
|############|############|
wait():
..............
When we wake up:
| |############|
write():
|############|############|
I found the problem is you're writing audio just before it be played, then sometimes it may arrive delayed in the buffer.
So I was programming on my board with a ATSAM4S8Bu using an Atmel-ICE debugger happily when suddenly I was assaulted by this error message any time I tried to debug or deploy to my board:
Failed to launch program
Error: unexpected chip identifier 0x00000000
This error also sometimes gets shouted at me:
Could not activate interface, but found DAP with ID 0x2ba01477.
How rude of it! I tried reasoning with it but it is not having any of it.
but seriously, it was fine one moment and the next this error has stopped me from further development so what does it mean and how do I fix this?
EDIT:
This error only seems to occur on my machine. It works on my colleagues, I tried reinstalling atmel-usb and atmel studio 6.2 but no luck :(
EDIT:
Some screen shots of the screen im shown in Tools->Device Programming and then trying to read the devices signature:
EDIT:
I also seem to get this error sometimes instead:
I've had this problem too and I have found a couple of solutions that I would like to share.
My PCB was using an ATSAM4E processor (that had never been programmed) with a Cortex debug header. I got the error message when I tried either method (SWD or JTAG).
Note: I was able to read the Device ID for a very short window after powering the PCB on or after pressing the reset button (Credit to Yaro and Yarooo). Often I would have to try multiple times to try and hit that short window. This confirmed to me that my circuit of the Cortex Debug header was correct.
jrb114 quotes in his post that there is an errata on the SAM3S datasheet that requires:
an external crystal or ceramic resonator on XIN/XOUT, or use the Main oscillator in bypass mode (applying a clock on XIN).
...
So what I did to make these boards work was provide a 1 MHz clock to XIN using a signal generator. Apply power to the PCB, then connect using the ATMEL-Ice. This connects fine. After that I set the GPNVM Bit 1 so we boot from flash, not SAMBA, programmed the device and it works fine.
My PCBs had an external crystal so I was a bit confused why my boards didn't work. So I put an oscilloscope on the XIN line and found that the crystal was not generating a waveform.
It turns out that on most of my boards, there was a short between one of the capacitors (for the crystal) to ground. No wonder my clock wasn't going.
On the other boards, the inductor that goes between VDD_OUT and VDD_PLL was not soldered correctly to the PCB, causing it to be open circuit.
Overall, it appears that this error is a result of not having a clock signal on XIN, whether it be incorrect wiring or not using an external crystal/resonator.
Running dronekit-python with ArduCopter as SITL. When specifying a velocity (only) in the set_position_local_ned_encode, the drone moves for a few seconds and stops.
This happens both with the example code (guided_set_speed_yaw.py) and a very small test program that ONLY does the set_position after the appropriate init. All other parts of all examples seem to work fine.
All running on Fedora. I don't see this listed as a bug, or any issues related to this. Any ideas or pointers are appreciated.
ArduCopter 3.3-rc9 added a 3 second velocity timeout. This is to prevent a lost connection from causing a flyaway. To continue flying in the same direction, just send the same packet repeatedly.
For future readers, the exact definition by Ardupilot:
Starting in Copter 3.3, velocity commands should be resent every second (the vehicle will stop after a few seconds if no command is received). Prior to Copter 3.3 the command was persistent, and would only be interrupted when the next movement command was received.
And by Dronekit:
From Copter 3.3 the vehicle will stop moving if a new message is not received in approximately 3 seconds. Prior to Copter 3.3 the message only needs to be sent once, and the velocity remains active until the next movement command is received. The example code works for both cases!
I have been using ST F4-Discovery board for some time, as many of other friends. We all have the same problem. We are using Keil IDE (used different versions from 4.3 up to 4.7). Whenever we time anything using breakpoints and stopwatch, it works perfectly when in simulation mode. However, when we are debugging on-board and run the same code, the stopwatch never reports correct timing. It is actually random. Does anyone know what the problem is?
Thanks
Stopwatch is based on the internal register SEC. There seems to be a bug that if the register window is not showing then the stopwatch values are not updated. When debug is running select View|Register window and make sure you can see the SEC register value updating. The stopwatch in the status bar should now be updating too.
To solve the problem of the stopwatch, go to: Tarjet options - debug - setting - trace - core clock and adjust the frequency to 72MHz or core of your processor.
I found the answer much later in time. It has to do with the internal debug circuitry. By default, the timer peripherals do not stop when we hit a breakpoint in debug mode but continue counting. This is why we keep getting random measurment intervals between timer interrupt instances using the stop watch. In order to get accurate timing, we need the debug circuity to force the timer peripheral to stop counting once we reach a breakpoint and resume later once we step over it. This can be done by writing this code:
SET_BIT(DBGMCU->APB1FZ, DBGMCU_APB1_FZ_DBG_TIM3_STOP);
Which instructs timer 3 on APB1 bus to stop counting at breakpoints.